Zach’s ugly mug (his face) Zach Leatherman

Frameworks, not Blameworks

November 17, 2015

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.

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, 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.

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.

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.

< Newer
Using Custom Fonts Responsibly, an Akamai Animated Short
Older >
A Brief History of that Time You Used Web Fonts—SmashingConf Barcelona

Zach Leatherman IndieWeb Avatar for a builder for the web and the creator/maintainer of IndieWeb Avatar for https://www.11ty.devEleventy (11ty), an award-winning open source site generator. At one point he became entirely too fixated on web fonts. He has given 81 talks in nine different countries at events like Beyond Tellerrand, Smashing Conference, Jamstack Conf, CSSConf, and The White House. Formerly part of CloudCannon, Netlify, Filament Group, NEJS CONF, and NebraskaJS. Learn more about Zach »

Shamelessly plug your related post

These are webmentions via the IndieWeb and

Sharing on social media?

This is what will show up when you share this post on Social Media:

How did you do this? I automated my Open Graph images. (Peer behind the curtain at the test page)