Let me start with this — this is by all means not a comparison of what should be your next choice for Front-End. It’s a small, relatively unsophisticated, comparison of three things: Performance, Size, and Lines of Code of pretty similar application.
With that in mind here is how it works:
We are comparing RealWorld App — something more than a “to do” app. Usually “to-dos” don’t convey enough knowledge and perspective to actually build real applications.
It is somehow standardized — A project that conforms to certain rules — there is a spec. Provides a back-end API, static markup, and styles.
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 24 implementations of Conduit at the RealWorld repo. It doesn’t matter if it has a big following or not. The only qualification is — 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. Doesn’t matter if it was auto generated or not — you still need to maintain it.
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. 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.
Lighthouse Audit doesn’t sleep. You can see this year that apps that are not maintained/updated are falling off the 90 cliff. If your app scores >90 it will probably not make a tons of difference. That said AppRun, Elm, and Svelte are really impressive.
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 a framework as well as on any extra dependencies added. Also how well a build build tool can eliminate the unused code from a bundle.
The smaller the file, the faster the download, and less to parse.
PureScript was skipped due to a lack of Demo application.
Angular +ngrx +nx please don’t blame me for Angular + ngrx + nx — check Chrome Dev Tools Network Tab, and if I counted wrong — let me know.
Rust + Yew + WebAssembly includes also .wasm file(s)
Amazing work by Svelte and Stencil community, getting it under 20KB, is really an achievement.
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
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.
Svelte was added after the article was initially published — thanks to Svelte master.
riotjs-effector-universal-hot was skipped due to cloc not being able to process
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.
Only Imba and ClojureScript with re-frame can implement the app under 1000LoC. Clojure is known for being unusually expressive. Imba is here for the first time (last year cloc, didn’t know the .imba file format) and it looks like it’s here to stay. If you care about you LoC you know what to go for.
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? I leave it up to you.
#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?
#5 Why did you forget to include a framework that is more popular than the one in the comparison?
Again, see #1 and #3. The implementation is not complete at RealWorld repo; it’s that simple.
If you like this article you should follow me on Twitter. I only write/tweet about programming and technology.
🎉 Learn ClojureScript and re-farme — video tutorial 🎉