by Jacek Schae
A Real-World Comparison of Front-End Frameworks with Benchmarks (2018 update)
This article is a refresh of A Real-World Comparison of Front-End Frameworks with Benchmarks from December 2017.
In this comparison, we will show how different implementations of almost identical RealWorld example apps stack up against each other.
The RealWorld example app gives us:
- Real World App — Something more than a “todo”. Usually “todos” don’t convey enough knowledge and perspective to actually build real applications.
- Standardized — A project that conforms to certain rules. Provides a back-end API, static markup, styles, and spec.
- Written or reviewed by an expert — A consistent, real world project that, ideally, an expert in that technology would have built or reviewed.
Criticism from the last version (Dec 2017)
✅️ Angular was not in production. The demo app listed on the RealWorld repo was using a development version, but thanks to Jonathan Faircloth it is now in production version!
✅ Vue was not listed in the Real World repo, and thus was not included. As you can imagine, in the front-end world, this caused a lot of heat. How come you didn’t add Vue? What the heck is wrong with you? This time around Vue.js is in! Thank you Emmanuel Vilsbol.
Which libraries/frameworks are we comparing?
As in the December 2017 article, we included all implementations listed in the RealWorld repo. It doesn’t matter if it has a big following or not. The only qualification is that it appears on the RealWorld repo page.
What metrics do we look at?
- Performance: How long does this App take to show content and become usable?
- Lines of Code: How many lines of code did the author need to create the RealWorld app based on spec? To be fair some apps have a bit more bells and whistles, but it should not have a significant impact. The only folder we quantify is
src/in each app.
Metric #1: Performance
The sooner you paint, the better the experience for the person who is using the App. Lighthouse also measures First interactive, but this was almost identical for most apps, and it’s in beta.
You probably won’t see a lot of difference when it comes to performance.
Metric #2: Size
Transfer size is from the Chrome network tab. GZIPed response headers plus the response body, as delivered by the server.
The smaller the file, the faster the download (and there’s less to parse).
This depends on the size of your framework as well as on any extra dependencies you added, and how well your build tool can make a small bundle.
You can see that Svelte, Dojo 2, and AppRun do a pretty good job. I can’t say enough about Elm— especially when you look at the next chart. I’d like to see how Hyperapp compares…maybe next time, Jorge Bucaran?
Metric #3: Lines of Code
Using cloc we count the lines of code in each repo’s src folder. Blank and comment lines are not part of this calculation.Why is this meaningful?
If debugging is the process of removing software bugs, then programming must be the process of putting them in — Edsger Dijkstra
The fewer lines of code you have, then the probability of finding an error is smaller. You also have a smaller code base to maintain.
Update: Thanks to Jonathan Faircloth for providing production version of Angular.
And if you found this article interesting, you should follow me on Twitter and Medium.