Frameworks, not Blameworks

Earlier this week, Paul Lewis wrote a great post gathering data on the performance of popular JavaScript frameworks on mobile devices. It was a great conversation starter, evidenced by the many blog post responses it garnered from Tom Dale, Dave Rupert, and Soledad Penadés.

“It seems to me that developer ergonomics should be less important than our users’ needs.”—Paul Lewis

One of the great things about Paul’s post is that his data clearly debunks a relationship between framework file size and JavaScript execution time. Notably, React and Polymer had similar results despite React having ~3.5x the file size.

(Related: Scott Jehl’s More Weight Doesn’t Mean More Wait)

It should also be noted that Paul’s data is a partial view of the big picture—it focuses only on JavaScript execution time and doesn’t include transfer time. Including transfer time may contribute to a stronger relationship between framework file size and overall performance cost. This is an important piece of the puzzle given that 2G makes up 62% of mobile connections.

As much snark as I talk on twitter about frameworks, it isn’t difficult to see their allure.

check out my new javascript framework that works for space travel and your commute to work—don’t worry about speed pic.twitter.com/IC6zDuZa9q

— Zach Leatherman (@zachleat) November 17, 2015

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

That being said, my Filament Group colleagues John Bender, Todd Parker, and Scott Jehl tackled this very same topic almost a year ago with the Performance Impact of Popular JavaScript MVC Frameworks. I’d recommend you read the whole thing—it’s very good. The data they gathered shows the big picture because it measures initial render on a variety of network connections.

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

In my mind, the discussion here is not a cage match between frameworks and vanilla JavaScript. We can’t realistically make a blanket statement that you should or should not use frameworks. Attempting to frame it as such would take us down a yellow brick road trying to help our humble strawman find his brain.

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.