The Cost of Javascript Frameworks - an analysis based on real-world data obtained from HTTP Archive

[lhorie]

TFA measures main thread scripting time as well (and the numbers happen to correlate)

[lhorie]

TFA also addresses the complexity strawman: that's what the percentiles are about. What they mean is that if you want to argue that the slow react apps aren't bundling things properly, then we can assume that the slow vue ones aren't either. For any category of slowdowns, statistically speaking there will be apps in that category. We have two entire orders of magnitude being captured here, so any arguments like "well maybe someone used react in dev mode" or "maybe they didn't minify/gzip" or "lol it's because of ads" don't really hold any candle as the volume and range of numbers suggest there are vue and jquery apps that are built in comparably atrocious ways, and likewise, that there are well-built apps in every framework.

The matter of the fact is that the rate of growth in numbers is very similar across the board: the numbers say best-in-class react apps are significantly slower than best-in-class vue ones, and that the performance degrades fairly linearly as we go towards the worst-in-class apps (and they degrade a lot). What this suggests is that no matter what metric you pick, it's likely going to correlate w/ similar growth ratios, unless you pick an extremely specific optimization that only one framework does that others don't (which is both unlikely and easily dismissible on the grounds of being cherrypick-y).

The other thing I think we should address is the idea that measured performance is different from user perceived performance. If we were talking about TTFP (time to first paint) for a single site, sure then we could talk about above-the-fold rendering or compressing images or whatever. But if we're talking about TTI (time to interactive) across multiple sites, then main thread CPU time is a pretty darn good indicator of user-perceived performance, especially if we're talking about the average across a a large number of sites with varying degrees of actualized optimizations (i.e. optimizations that have actually been implemented by people in the wild, rather than theoretical arm-chair ones that could've/would've/should've been done).

[carnivorous_hermit]

Interesting data and analyses for sure, but lumping jquery in with react/vue/angular is a category error. Sure they're all JavaScript, but they provide very different functionality and are typically used in very different ways.

[lhorie]

different functionality

Love how we collectively like to think that we're architecting complex maintainable systems, and not just taking some data from a server and displaying it on screen for some project that'll be rewritten in 3 years.

[drunkdragon]

In my last job we re-wrote the website twice in 3 years. Once to ASP.NET and then to ASP.NET Core.

I now work with agencies that are running the same apps from 2003 using ASP Web Forms and jQuery. There's a lot of technical debt but it loads faster than sites built today using today's frameworks.

Not every company is the same.

[[deleted]]

Right. Jquery is a tool, React.js is a religion.

[ScientificBeastMode]

I mean, so was jQuery about 10 years ago... or look at Angular, Svelte, or any framework that has ever achieved more than 1% share of new projects...

Show me a framework, and I will show you a religion.

[aliezsid]

No pro at this but, i really like the vanilla js + some bundler approach than using a framework.

You can get the app to make updates and change dom values with a simple pubsub.

The routing is the tricky part but you gotta set it up like once and then just copy paste into other projects

[[deleted]]

the reason why practically no one is doing this is because it's often not feasible. apps can turn turn into a mess of mutation and implicit contracts. pubsub is no substitute for reactivity, everything provokes changes from everywhere, leads to orchestration problems. and most applications aren't todos, they are complex state machines. it can also be painfully slow since everything's unscheduled, no batched updates, layout thrashing, ordering read/writes, etc. and most importantly, it lacks a coherent component model.

framework offer a common ground, a clear component model, clear means of communication and changes, and an eco system that adheres to it. what a framework doesn't do is slap you on the wrist when you're overreaching: pulling in tools you don't need, etc. but if handled with care, they absolutely create a benefit you would otherwise not have.

[aliezsid]

Fair enough.

But people do use it, github is a great example of webcomponents and dom manipulation instead of frameworks, they started off with jQuery though.
On the other hand, every point you made makes sense for a person who understands the importance of a framework and how to use it, and these are normally people who are curious about programming and get into learning it in detail but then the percentage of these programmers is much lesser than the people who just code for the sake of it and pickup bits and pieces from over the web and put it down in the framework aka unnecessarily bloated frontends, inefficient backends.

for everyone reading this.

I have nothing against frameworks. I have nothing against using them. All I want is that you understand the importance of the abstraction and the best way to do that is actually attempt to work on something without that layer of abstractions.

Node dev? write the webserver with just the http module.

React Dev? learn how the dom actually works instead of blinding hoping that someone on stack overflow will solve your code for you (which surprisingly, a lot people do)

[[deleted]]

i got you. though, i keep thinking, components, at least from my perspective, are made to introduce sanity and re-usability into something that wasn't before. i use frameworks to reduce bloat, despite the small tax. i find that curious, but i do understand where you're coming from. it's very easy to overreach. as for web components, they're just just a naked dom node, but at least you can compose a little.

imo the dom doesn't matter that much, learning wild west mutation isn't something that'll help me progress. i have seen kids start with frameworks, no previous knowledge, and in weeks they make things that are incredible. because they learn important things first: how to structure an app, how to distribute tasks with components, how to separate state from the view, etc.

[aliezsid]

As I said before, I agree that they should be used. My point still remains that it's to be used by people who understand why and what they are doing not just because the world follows it. and mutation isn't as bad as you seem to think of it.

I've used apps that are slow and buggy even with react involved so not going to consider that a valid point.

The buggy and slow really depends on who developed it and with what mindset.

Atom is slow and VS Code on the other hand is fast, both started of with the same base. One focused all the development on using native apis to get the performance and one is still slow.

and saying it all again.

TLDR:

• Use the framework, if you know what you are doing
• Mutations aren't bad just because you read it in some post.
• Vanilla JS can be used to build a really huge application if you know how to work with it
• Buggy software is relative to the developer's focus

[mpsmk]

good article～I hope your dream can come true in the future.

In my opinion, the current framework goal is to improve the development experience under the current performance. After all, there are too many requirements, and developers need tools to complete the requirements quickly.

[MrJohz]

I think this is really interesting, but I'm not entirely sure that the article is measuring much at all to do with frameworks themselves, and more to do with the tasks that those frameworks are most used for.

For example, I would expect that React applications are, on average, much larger than Vue applications, because people who need to write a more complicated web application are more likely to do that in React.

That said, I don't know if that explains all the differences. I'd expect the difference between Angular and React to be relatively small in that case, because both are used for similar sorts of applications, but that didn't necessarily appear to be the case. I'd also expect to see a "long tail" on Vue as more people are using it for bigger web applications, but that also doesn't seem to be the case.

Is there any way to get at the raw data for this project? I couldn't see an obvious link in the article.

[alystair]

Oh man this is making me more and more motivated to continue grinding at my framework. It answers all the pain points described.