My go-to resource for this data over the last couple years has been the js-framework-benchmark by Stefan Krause. It’s good, but also kind of complicated. It’s easier to look at a subset of the results, and that’s what we’ll be doing in this article. I encourage you to check out the tool Stefan has built and dig into more of the data on your own, particularly if your favorite framework is missing from the graphics below. It may be available on Stefan’s site (he tests 40+ frameworks).
Also, a quick warning:
These results are preliminary - use with caution (they may e.g. be from different browser versions
With that caution duly noted….
Let’s See the Numbers
The first batch of results will be looking at how long each framework takes to do various operations on a large table - creating rows, removing them, etc. Another important point, these are keyed results. Here’s the explanation from Stefan’s site:
Keyed implementations create an association between the domain data and a dom element by assigning a 'key'. If data changes the dom element with that key will be updated. In consequence inserting or deleting an element in the data array causes a corresponding change to the dom.
In the image below, the larger the number, the slower the framework performed on the task. Looking at the bottom value “slowdown geometric mean” is an indicator of overall performance and this is how they are ranked, left to right. On the far left is “vanillajs” - meaning no framework - that acts as a reference point.
As you can see, I’ve included most of the popular frameworks as well as couple of less-well-known, but interesting frameworks. Preact (which is pretty popular) and Inferno have APIs very similar to React, which is why I included them. They may be good options if you are on a team that uses React, but are building an app where performance is a high priority. Also note that keyed results will typically be slower - the framework is being asked to do more work.
Of the most popular frameworks, Vue looks pretty darn good. Angular and React are both notably slower, but post very similar numbers to one another. The Inferno library is the stand out of the group, however. As an aside, the author of Inferno, Dominic Gannaway, was recently hired by Facebook to work on the React team.
Now let’s check out the non-keyed results:
There are a few things to note. First of all, we see that there are fewer frameworks listed because non-keyed results are not available for every framework. We also notice that the results have been shaken up a bit.
Vue is the slowest of this group and Angular is now the fastest of the popular frameworks. The fastest of all is Svelte, which is an interesting framework that takes a different approach - you should definitely check it out.
Before we move on, I would be remiss if I didn’t mention the framework that topped all others - Surplus, by Adam Haile 🎉. It wins in both keyed and non-keyed tests. There are a number of others that also performed quite well including petit-dom and dio. I didn’t include them above because I wanted more room for the most popular libraries/frameworks. If you go to the results table, you’ll see it gets overwhelming quickly and some trimming needed to be done to make things manageable for our purposes.
The results above looked at how fast the frameworks were once a page was fully loaded and they performed operations on a large table. The next set of numbers looks at things from a different angle - download, parse and compile time.
Again, these results are grouped by keyed and non-keyed. Let’s start with with the keyed results:
These measurements don’t have a single handy value by which they are ranked, but generally, green is good, red is bad. Again, Inferno is looking good, as are Svelte and Preact. Of the most popular frameworks, Vue performs the best and Ember is looking a bit flushed at the back of the pack
Now let’s see the non-keyed results:
As I alluded to earlier, I have been following Stefan’s benchmarking for quite a while now and I immediately connected his work with Addy’s article. When we are prioritizing performance, most of the time we’re talking about mobile devices. These mobile devices are often less capable than many assume. And by many, I mean me - and probably a bunch of other people too.
For example, a framework like React has a huge ecosystem that can accelerate your project by providing many third-party libraries and abundant training resources, among other benefits. But is it the best choice for a project that is targeting users on 2G networks? Maybe not.
Deciding which framework is going to work the best ultimately comes down to project requirements and the team building it. Hopefully the results highlighted here have provided some food for thought.
Until next time, happy coding…