JavaScript Developers...Stop HATING Frameworks!!!
My last six months as a JavaScript developer have included a period of self-assessment. Primarily, I’ve reviewed how I write application code: not the libraries and frameworks that help me write it.
I’ve also researched how other developers write code and, collectively, have learned great things from them. But when discussing libraries and frameworks, I’ve seen too many instances of developers rejecting them for the wrong reasons.
A disclaimer
I’m talking from a React point-of-view here because that’s what I’ve been using lately. Don’t take it to mean that I think everyone should use React…it’s just my POV for this post.
How this all began
It all started after a lengthy period of using React on a daily basis. Consequently, I see three positive things that React brings to the JavaScript developer conversation:
- manipulating app views with a state object: changing your app’s view/state with a standard “key:value” object (not the DOM) is cool…and more efficient.
- a focus on functional programming: React promotes the idea that a function should do one thing well, do that thing in its own world, and do it without screwing up the world around it.
- thoughtful component model: I’m stealing that phrase from Jacob Thornton’s great React article but he’s right. React does a great job of encapsulating chunks of UI inside a single reusable component.
All these things are great because they encourage computer science best practices within JavaScript development. As JS progresses from making neat rollovers to a full-on application language, it’s right to bring in these practices.
There will be naysayers
After its release, some developers labeled React as “JAJFLWYWCI” (Just-Another-JavaScript-Framework-Library-Whatever-You-Wanna-Call-It). For whatever the reason, they said we shouldn’t use it…a frequent reaction to frameworks and libraries among JS developers.
The comments for not using it aligned with at least one of these three opinions:
- “Frameworks and libraries lead to slow performing web apps.”
- “It has a steep learning curve.”
- “Using frameworks and libraries is unprofessional programming.”
Some comments I engaged with (mostly online) and some I didn’t. But they didn’t bother me to the point I felt compelled to blog about it.
I had real-world web developer stuff to deal with so I moved on.
What Kevin said
Then, maybe on a subconscious impulse, I re-read Kevin Luecke’s “I’m done with the web” article. An article that bummed me out when I first read it in 2013.
Kevin wasn’t “done with the web” literally, but he was “done” with embracing the web developer community to the extent that he had. One reason for this was his frustration with why these developers hastily rejected certain JavaScript UI frameworks.
Even though things like Cappuccino and Ember solved problems, web devs shunned them because of their seemingly large, low-performant file sizes and steep learning curves. Little time, if any, was spent seeing if they solved problems: the knee-jerk reaction was to reject them based on those things.
Kevin used other examples of web developers focusing on small-ish problems and he felt this was slowing web app progression. He felt that community was spending too much time worrying about the wrong stuff.
He had enough of this “stagnation” as he phrased it so he, himself, moved on. From the web dev community, that is, and more towards native app development.
What bummed me out about this article was how I’m a part of this community that rashly rejects stuff. Also, he made some comments about “people that don’t know how to program” and I wondered if I was part of that group as well.
What Kevin's article was really about
First, I don’t know the context of Kevin Luecke’s comments regarding people that don’t know how to program. So I’m not going to take them out of context and let them bum me out.
I’m a self-taught, web developer: I learned web stuff at a time when those that knew even a little HTML were incredibly employable. I’ve continued to do web stuff for a long time since then, giving me experience that keeps me incredibly employable.
Since I’m not a classically-trained computer science developer, I’ll always have to deal any feelings of insignificance that come up around this. OK…I’ll live with that.
Second, worrying about my feelings kept me from realizing the main point of that article. That web developers focus on the wrong things when rejecting certain JS tooling, and this is holding them back.
The complaints about performance
To be fair, I can’t really say that the complaints about JS lib and framework performance are “wrong”. Making apps as fast as possible is important as our dependency on mobile rises, and less JavaScript makes them faster.
But if an app requires lots of interactive features, as many do, then a library or framework may be needed to quickly build out those features. Thankfully, the JS community has developed lots of non-hacky best practices to increase performance for this use case.
Most of these practices are built around webpack. With its ability to build out slim JS files for production and code-splitting functionality, webpack has become a necessary tool for JavaScript app development.
Andrew Welch wrote a ridiculously thorough article on setting up webpack. Just like JS libraries and frameworks, webpack has a bit of a learning curve so it’s worth a read.
Also, Addy Osmani wrote a pretty definitive article on JS performance…give it a read as well. It discusses webpack and code-splitting stuff, along with other things like performance budgets, critical paths and testing/auditing tools.
Other performance stuff
Images are usually blamed for causing the most performance issues and Luecke mentions them in his article. But Osmani effectively argues that JS may be the bigger performance headache because images only have to download while JS files have to download, then parse and execute code.
Whatever your opinion here, optimize your images as well as your JavaScript. This means doing things like:
- using Photoshop “export/Save for Web” on your images.
- adding an image minification step to your build process using something like imagemin-cli.
- if you can, using a CDN to serve out images…as well as JS, CSS and font files.
- ~maybe~ looking at Bokeh to further optimize your images.
And performance depends on more than this: aggressive browser caching gives other performance wins. Plus, file minification is still a good idea, and your app will be slow if it’s hosted with a low-end shared USD $5/month plan.
Many things can slow an app down: don’t put the blame for this all on JavaScript.
The complaints about learning curves
In his post, Kevin Luecke is blunt about the defeatist attitude web devs take towards ramping up on new things. After quoting a developer who implied that it would take too long for their team to learn Ember, Luecke responded:
"This reaction to Ember just baffles me. Your day job is to build a piece of web software and you can't take a few days to learn the ins and outs? Presumably you're in a large team because this project is important and will take some time to complete. Nevertheless, I've seen this reaction many times in the web culture.
I can relate to having this defeatist attitude. Always having to ramp up on a new JavaScript technology has affected me negatively and I’ve written about it.
But this is how JavaScript is right now and this rapid change shows no signs of slowing down. Newly-released JS libs and frameworks are part of this constant change…we all have to keep up.
If you’re used to changing your UI with DOM manipulation, React might have a bit of learning curve. React makes you change UI by updating a state object instead of using something like document.querySelector().
But regardless of learning curves, libraries and frameworks solve someone’s problem somewhere in the world. So a developer that’s familiar with at least the popular ones is a valuable asset.
Developers like this have “problem solving-power”: the ability to look at a problem and say “this framework is our solution.” Day job bosses and freelance clients love this.
You have to invest in yourself and make time to learn new JavaScript stuff, frameworks and libraries included. You may think there’s nothing to lose by not learning them, but there’s certainly nothing to gain either.
The complaints about "unprofessional programming" (whatever that means)
However, lots of developers believe the other ones using frameworks and libraries have no value and are unprofessional. That libs/frameworks should be completely avoided and we should just use vanilla JavaScript, and they’re passionate in their belief.
I carried this belief once and to be honest, I became a better JavaScript developer as a result. My knowledge of JS fundamentals increased: writing powerful & concise functions, using return correctly, understanding prototypal inheritance, etc.
So yes, focusing my energy towards learning pure, unadulterated vanilla JS helped me. Still, I believe that the idea that using JavaScript frameworks and libraries is unprofessional is total bullshit.
Spend enough hours writing raw vanilla JS and you’ll look for ways to write less of it with code abstraction. I can produce lots of high-quality code quickly when the right library or framework lets me.
And what if you’re part of a team of developers? Using a lib or framework helps here because it provides your team a shared language, making collaboration and communication easier.
With React I can tell someone, “solve your problem by using this pre-built component that so-and-so built.” Much easier than “cut-and-paste this code block that so-and-so wrote but you’ll have to ask so-and-so what to do next.”
Think about about what "unprofessional programming" means
I’ve said this many MANY times before and I’ll say it again:
Using JavaScript libraries and frameworks isn't unprofessional. Using them without understanding the core language fundamentals behind them is.
Yeah, I use React everyday now, but it’s because of its above-mentioned thoughtful component model. It lets me create huge chunks of UI that are easily reusable and easily editable.
That’s all it does for me: from there, writing pure, vanilla JavaScript is my responsibility. I have to understand the use cases for using let or const, returning Promises and looping over JSON Objects.
React doesn’t help me with any of this. It gives me a nice container to place that code inside of, but that’s it.
I’m using React to deliver production-quality code on time. I don’t see why this is unprofessional.
Web developers can learn from native developers
While commenting about the complaints about learning curves, Kevin Luecke compared web developers to native developers:
This mentality is pretty rare in the world of native development though. Almost every decent developer I know has no problem spending a weekend learning some new and cool tool, but sadly, this spirit seems to be absent from the web culture.
I would apply that mentality to the web dev complaints about performance and “unprofessional programming.” I never hear Java developers make the same complaints about Spring…same thing with PHP developers and Laravel.
And right now, imagine what would have happened if Ruby developers collectively rejected Rails for any of these reasons.
Understand the business process leading the app
Before accepting or rejecting a JavaScript library/framework, have a clear understanding of the project’s goals and business requirements. Understand what the app must do before rejecting the tools that can help you build it.
Ember, which I’ve obviously used, has a big file size and gets updated too frequently for my comfort. But if I’m building an app that users will open up and then use for a long time (like they would with Excel), Ember’s a great option here.
This is not a chicken or the egg riddle. The business process leads the app: it never EVER follows it.
Speaking for myself, this is an area where I’ve made mistakes in the past. Had I focused more on what the business needed to accomplish and less on the “cool” way to write code, I’d be a VP somewhere.
You need to build a product and then ship it out the door: a library or framework may be a means to that end. So again, understand what your app must do because a framework or lib may help your app “do” it better.
The current JS build tooling is complex, but helpful
While almost all the comments on Andrew Welch’s webpack post are positive, the very first one was this:
Why do we keep making the build and deploy setups more complex than the apps we're deploying?
I don’t know if the build process is “more complex” then the apps, but know that the process itself is more complex than it was before. And Welch’s response to the comment was proper: it terms of the complexity, “it depends on what you’re building.”
But this is the current state of JavaScript development. We’re now using JS to build complex web and native apps, which can be created easier with libs and frameworks.
So yes, the build process is harder and takes more work than before. But again, this is the world we live in.
Conclusion
When discussing JavaScript frameworks and libraries, I believe that only real reason to reject them is their potential performance problems. And we have a ton ways to solve these problems.
Let’s use these solves in our work so we can focus on the important thing: building apps fast and efficiently. And if a framework and library helps you do this (and you took the time to research if it does), so be it.