by Jacek Schae
A RealWorld Comparison of Front-End Frameworks with Benchmarks (2019 update)
Also available in:
Turkish — thanks to @erdenizZz,
Portugues — thanks to @felipefialho
For the third time, we are comparing Front-End frameworks by using the Real World example apps. RealWorld example app gives us:
Something more than a “todo”. Usually “todos” don’t convey enough knowledge and perspective to actually build real applications.
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.
Which libraries/frameworks are we comparing?
As of the writing, there are 18 implementations of Conduit at the RealWorld example app 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?
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
We’ll check the Performance score from Lighthouse Audit that ships with Chrome. Lighthouse returns a Performance score between 0 and 100. 0 is the lowest possible score.
Performance is a combined score from the following metrics
- First Contentful Paint
- First Meaningful Paint
- Speed Index
- First CPU Idle
- Time to Interactive
- Estimated Input Latency
For more details check Lighthouse Scoring Guide.
The sooner you paint and the sooner someone can do something, the better the experience for the person who is using the App.
Note: PureScript was skipped due to a lack of Demo application.
Most of the apps score above 90. You won’t probably feel 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.
This depends on the size of your framework as well as on any extra dependencies you added, and how well your build tool can eliminate the unused code from your bundle.
The smaller the file, the faster the download, and less to parse.
There is a lot of sensational things happening in this area. Svelte — The magical disappearing UI framework — really holds true to its punch line. Stencil is the new kid in this benchmark and also performs pretty well. Both are relatively new and are pushing the limits of what is possible in terms of size.
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
Lines of Code TL;DR
This shows how succinct given library/framework/language is. How many lines of code do you need to implement almost the same app (some of them have a bit more belts and whistles) accordingly to the specification.
Note Imba: Imba was skipped due to cloc not being able to process
Note Elm: Elm developers write the code a bit more vertically, thus the high count of LoC — at least this is what I have been told.
Note Angular+ngrx: LoC calculation done with
/libs folder only including
.html files. If you believe this is wrong, please let me know what is the correct number and how did you calculate it.
Note Hyperapp: LoC was not correct when the article was published, thanks to Mateusz Kwasniewski for pointing out the correct way to calculate LoC.
ClojureScript with re-frame gives you the most bang? for the LoC. Clojure is known for being unusually expressive. If you care about you LoC you should check out ClojureScript, AppRun, and Svelte.
Keep in mind that this is not exactly an apples-to-apples comparison. Some implementations use code splitting and some don’t. Some of them are hosted at GitHub, some at Now and some at Netlify. Do you still want to know which one is the best? The best one is the one that fits your needs.
Q: Do you like types?
A: Look into Elm, PureScript, and TypeScript — Angular, AppRun, Dojo.
Q: Do you want to have a very small footprint?
A: Check out Svelte, Stencil, and AppRun.
Q: Do you want to have the smallest code base to maintain?
A: Check out ClojureScript with re-frame, AppRun and Svelte.
Q: Want to learn something new?
A: Pick the one you don’t know!
#1 Why were framework X, Y, and Z not included in this comparison?
Because the implementation is not completed at RealWorld repo. Consider contributing! Implement the solution in your favorite library/framework of choice and we will include it next time!
#2 Why do you call it the real world?
Because it’s a bit more than a To-Do app. By RealWorld we don’t mean that we’ll compare salaries, maintenance, productivity, learning curves, etc. There are other surveys that answer some of these questions. What we mean by RealWorld is an application that connects to a server, authenticates, and allows users to CRUD — just as a real-world app would do.
#3 Why didn’t you include my favorite framework?
Please see #1 above, but just in case, here it comes again: because the implementation is not completed at RealWorld repo. I don’t do all of the implementations — it’s a community effort. Consider contributing if you want to see your framework in the comparison.
#4 Which version of the library/framework did you include?
The one that is available at the time of wiring (Mar 2019). The information comes from RealWorld repo. I’m sure you can find this out from the GitHub repo.
#5 Why did you forget to include a framework that is more popular than the one in the comparison?
Again, see above. The implementation is not complete at RealWorld repo; it’s that simple.
Thanks to Rich Harris and Richard Feldman for taking a look before publishing.
When this article has been published the TL;DR LoC had following description:
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.
If you like this article you should follow me on Twitter. I only write/tweet about programming and technology.