by Jacek Schae

A RealWorld Comparison of Front-End Frameworks with Benchmarks (2019 update)

3EHjaj6QO1StPPogrXsM4LhMeuFkFIzIj8Md

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:

RealWorld 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.

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.

mxmA13gZ63sf7YgfD2ZKaotbT5SDY9mXt9CD
Frontends at Real World repo (Mar 2019)

What metrics do we look at?

Performance

How long does this App take to show content and become usable?

Size

How big is the App? We will only compare the size of the compiled JavaScript file(s). The CSS is common to all variants and is downloaded from a CDN (Content Delivery Network). The HTML is common to all variants, too. All technologies compile or transpile to JavaScript, thus we only size this file(s).

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.

Audit Settings

itrdsyHI0H0Jb0KJ5UJerNjzWqD9y53yBzzo
Lighthouse Audit Settings for all tested apps

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.

Performance TL;DR

The sooner you paint and the sooner someone can do something, the better the experience for the person who is using the App.

atCnTzcBrZlj9WK-GtZdKHSilk8O8LoBN7UD
Performance (points 0–100) — higher is better.

Note: PureScript was skipped due to a lack of Demo application.

Conclusion

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.

Size TL;DR

The smaller the file, the faster the download, and less to parse.

DRmH8Fz15DLxXguz9d8NR0eVanX0U9xW9jom
Transfer size in KB — fewer is better

Conclusion

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.

Y7vQUAUrMzGi8l3K2VZujbrZYqAIPfKwYXZj
# lines of code — fewer is better

Note Imba: Imba was skipped due to cloc not being able to process .imba files.

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 .ts and .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.

Conclusion

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.

Summary

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!

FAQ

#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.

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.

Updates:

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.