JavaScript Frameworks, Performance Comparison 2020
By: Ryan Carniato
Tags: React, Vuejs, Web Development, JavaScript, Software Development

Group 4 — Standard Performance

This is the biggest group and consists of some of the most popular libraries. Also many of the corporate-backed ones from the likes of Facebook, Google, eBay, and Alibaba. These are the libraries that either has less of a focus on performance or highlight performance in one area but suffer in others.

Group 4 Performance

There is a lot of red and orange here but keep in mind these libraries on average only around 2x slower than the painfully handcrafted imperative Vanilla JavaScript example we are using here. How different is 400ms from 200ms?

In raw performance, React is the leader of this pack. Although it never ceases to amaze given how different the architecture, how close React, Marko, Angular, and Ember are here overall. Still, it’s React, and that’s the React Hooks implementation, that is the leader here. For all those pointing extra function creations and holding on to classes, the performance argument is not on your side. React Hooks are the most performant way to use React.

Most libraries here either have naive list sorting which leads to really poor swap row performance or they have expensive creation costs. Ember is an extreme case of this as it has much better update performance than the rest of this group but creation among some of the worst.

The slowest libraries(Knockout, Ractive, and Alpine) are all fine-grained reactive libraries with similar architecture. The Knockout and Ractive(also by Rich Harris the author of Svelte) are from the early 2010s before VDOM library dominance. I also doubt Alpine was expecting to ever render 10k rows with its sprinkle of JavaScript approach. We won’t see another pure fine-grained reactive library until much later in the comparison.

Next, we will compare startup metrics a category largely based on the libraries’ bundle size.

Group 4 Startup

The order changes a good amount here. Where Alpine has the worst performance we can see it has the smallest bundle size and quickest startup time of the bunch. Marko(from eBay) is right behind it, followed by Rax(from Alibaba). All 3 of these libraries are built for server-side rendering primarily with lighter client interaction. It’s largely why they are in Group 4 for performance but lead startup here.

The latter half of the table are some of the largest bundles we have in the benchmark ending with Ember that is more than 2x times the size of any other implementation. I don’t know why it takes more than half a megabyte to render this table. But it really hurts startup performance.

The last category we will look at is memory consumption.

Group 4 Memory

Memory tends to reflect the patterns we’ve already seen as it has a big impact on performance and larger libraries tend to use more of it. Alpine, Marko, and React lead the way. The ageing fine-grained reactive libraries use the most leading up to Ember. Ember is just gigantic. It already is using more memory than Vanilla will use throughout the whole suite after rendering just 6 buttons to the page.

Group 4 Results

In general, this group represents over 300k stars on GitHub and probably the largest portion of NPM downloads, but it’s Marko and Alpine that place the highest on average ranking in this crowd. React is 3rd after them holding its own especially in performance.

This is the group where we have frameworks of titanic proportions and where our old reactive libraries have gone to die. Let’s move on to something a little more optimistic.