Frameworks, not Blameworks
“It seems to me that developer ergonomics should be less important than our users’ needs.”—Paul Lewis
(Related: Scott Jehl’s More Weight Doesn’t Mean More Wait)
As much snark as I talk on twitter about frameworks, it isn’t difficult to see their allure.
At NebraskaJS we’ve had many great speakers talk about the utility of React, Angular, Ember, and many others. As a meetup organizer, it isn’t my job to filter these talks to topics that I personally agree with or would advocate for. It’s my job to attempt to learn and help others learn from the many different perspectives that exist in our community.
Prior Art #
Miniscule Apps #
The counter-argument presented against these blog posts is that TodoMVC isn’t a great test case.
“TodoMVC is a miniscule app and is in no way representative of the apps most developers work on day to day.”—Tom Dale
However, a more complex application isn’t going to do anything to improve your initial render time. If you’re developing an application that is for a corporate employee intranet with captive users, your performance needs might be different. However if your code lives on the public internet, it is subject to consumer choice. You need to meet certain critical performance benchmarks of the impatient user or they will abandon your site. At time of writing, wpostats.com documents 18 different high profile cases about the relationship between performance and user engagement. Users don’t care about a developer ergonomics sob story—they want the site to load fast or they’ll go somewhere else.
It Depends #
Less is More #
“The bottom line is that I don’t think “reduce the amount of code” is a reasonable lesson for the average developer to follow.”—Tom Dale
Oversimplifying to “less is more” does a disservice to the debate as well.
“There is no such thing as a performance budget… less is more” Wrong. Use CSS/JS? Our business is trading bytes for features, responsibly.— Zach Leatherman (@zachleat) June 12, 2015
The trick is to pick the right framework (or lack thereof) that best meets the needs of our users. This includes making performance a priority, but on the users’ terms: on their device, their network connection, their web browser configured to their needs.
So much product development time is spent undoing complexity that should have been left out in the first place.— Jason Fried (@jasonfried) November 16, 2015
Competition and Choice #
Again, I wouldn’t and couldn’t credibly say that you should forgo frameworks altogether. That’s the wrong discussion to have. If you decide to spend valuable kilobytes on a framework, fortunately there are plenty of frameworks to choose from. Just like DOM libraries used to compete on selector engine performance, the onus is on framework authors to compete against each other on initial render performance.
“The average Smartphone visitor to your business website will beat a hasty retreat if it doesn’t load inside 3 seconds.”—Strangeloop Networks study
Your framework choice sets the performance baseline that your application code will pile on top of. Visitors are impatient and choosing the wrong framework can set the performance baseline too high even for “miniscule” applications.
Vote with your
npm install and choose one that is focused on (mobile) performance. Frameworks exist that don’t prohibitively hamper the perceived performance of your site. Frameworks exist that have a fast initial (preferably server side) render. The data is clear. Choose wisely. Your users will stick around long enough to thank you for it.
A previous version of this article stated that Polymer was 3.5x the file size of React. The reverse is true. Thanks notbrent.