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.
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
- 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.
There will be naysayers
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.
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
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.
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.
- 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.
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.
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
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.
The complaints about "unprofessional programming" (whatever that means)
return correctly, understanding prototypal inheritance, etc.
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:
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.
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
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.”
So yes, the build process is harder and takes more work than before. But again, this is the world we live in.
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.