JS web frameworks benchmark – Round 6

Some people asked for an updated – and there were some interesting updates and contributions, so it’s a good time for a new round of the js web framework benchmark.

What’s changed

About the benchmark

If this is the first time you look at the benchmarks or you’ve somehow managed to forget about them you can read here what the benchmarks measure.

Here’s an article about how we use webdriver to extract the duration from the timeline for the measurement, though in the mean time we’ve switched to a typescript implementation of the test driver. What’s important is that we measure the duration as reported in the chrome timeline and measure from the event start until repainting in the browser finished (i.e. this is much longer than the time the pure javascript code needs).

This link allows you to play with the benchmark in your browser. All benchmarks report some approximate duration on the console. But please note that this is just for fun. The results table’s measurement is as described above.

There are two categories for the measurements, “keyed” and “non-keyed”. Details can be read here, put shortly non-keyed implementations can be faster, because they are allowed to freely choose the fastest way to update the DOM. This may cause problems e.g. with css transitions.

Please note that as with all benchmarks the data should be interpreted carefully. Measurement has some inaccuracy, such that each run varies a bit. We’re reporting the average of 20 runs per benchmark and framework here.

Results


(Click here for a filterable and sortable version or  here a for static version if your browser doesn’t support es6 yet.)

Conclusions

  • Some of the “smaller” implementations are incredibly fast like surplus, domvm, ivi and dio and almost beat vanillajs. Still small doesn’t necessarily mean faster than the big ones as Datum, rx-domh, slim and stem show.
  • Non-Keyed implementations seem easier to optimise than keyed. In my personal opinion non-keyed updates are a nice addition but I’d only choose a framework if it also supports keyed updates. Please note that the table is not complete regarding the question which modes a framework supports.
  • Svelte has an interesting concept , which one could call a perfect ahead of time compile-approach.  There’s no runtime javascript that needs to be added to your app. It has currently an issue with swap rows in the keyed mode but I bet they will improve in that benchmark.
  • Glimmer improves on embers results, but is still slower than react, angular or vue.js.
  • Angular 4.1.2 is a bit faster than 2.4.9 though 4.0 was actually slower.
  • Marionette and, although not as bad, Knockout, perform worse than angular.js and may even justify a migration.
  • Of the react clones preact lives up to its promise of being a faster react implementation. React-lite fails to deliver that promise.  Inferno is extremely fast – at least when a few extra knobs are pushed.
  • The startup time row highlight the benefits of smaller frameworks. The cost of adding frameworks can be clearly seen for react. mobx or redux increase startup cost about 30% in comparison to react.
  • Vue.js is the fastest of the big three modern frameworks although not by a large margin. It starts faster than both angular and react and shows little weakness.

19 Comments

Add a Comment

Your email address will not be published. Required fields are marked *

*