Blazing Fast HTML: Elm vs. React vs. Angular vs. Ember
elm-lang.org
elm-lang.org
Honestly, your decision to use any of the frameworks in the article should not be based on a benchmark. The frameworks here differ so much in how they work, the mental thought process you use in them, etc.
What is the technical debt of Elm? Training for developers to learn something other than JS, etc. This is a much bigger factor in a framework decision than a benchmark. Especially when all of them are fast and only a few cases would you even notice a difference between them.
Please, don't use this to decide which front-end framework to use. Nor switch from one you are using, "just because it's faster!". Save yourself and your co-workers the headache.
Here is more info about one company's experience with Elm when it comes to technical debt, training developers to learn something other than JS, etc:
Benchmarks are not the best way to advertise languages but regardless Elm has do well on so many fronts to make it competitive otherwise it will die to the popular frameworks/languages (usually the lowest common denominator).
> Please, don't use this to decide which front-end framework to use. Nor switch from one you are using, "just because it's faster!". Save yourself and your co-workers the headache.
I would hope and fairly optimistic that people make decisions on a variety of compelling reasons (particularly tech people). Some of those reasons often can be performance. What you mean is don't make this the sole reason and even this "tip" isn't really helpful advice.
I didn't mean to sound like it isn't a good idea to have a good portion of your reasoning based on popularity. I have done it myself :) . But if your trying to make your framework popular you have to do some advertising (hopefully somewhat honest). I don't blame the Elm devs for publishing some benchmarks particularly when it is some impressive work they have done.
- Optimizing Elm only touches view code, unlike everyone else.
- Optimizing Elm cannot introduce sneaky bugs, unlike everyone else.
- These results should generalize to apps of any size.
Also interesting is how Elm's immutability allows it to use requestAnimationFrame by default, which plain vanilla JS libs can't use by default.
The speed is really just a bonus, as the real things to be excited about are the features you get from a typed functional language (HM type inference, union types, auto currying, etc.) that compiles to efficient JS with a focus on web development.
<1500 lines of straightforward JS makes it all possible. It is indeed very similar to Matt Esch's original [1]. The Elm port reads nicely in one file.
(Coming from someone who appreciates Elm)
The architecture docs are ok. --> If you already understand the concept and are willing to read some other tutorials.
The effects docs are... no comment.
Compare the guide to others like from Rust.
A lot of people I've pointed to Elm gave up quickly because there s no good introduction guide. It's not even properly linked as a first, visible entry in on the docs page.
They are not at all representative of the complexity costs that emerge from real apps, which often mitigate differences between frameworks considerably.
(Apart from the fact that creators benchmarking their own framework know how to optimize it best).
Show me a framework which handles optimistic updates, knows how to query multiple data sources and merge their values, doesn't make it harder to reason about as I add more components and then I'll be very interested.
These are only a few of the hard problems to solve when building an app and I feel most frameworks completely ignore them and instead take the easy route of how quickly can I write yet another TodoMVC.
Productivity at the beginning of a project doesn't matter nearly as much as productivity at the end of a project.
http://lhorie.github.io/todomvc-perf-comparison/todomvc-benc...
2. Article seems to compare most popular frameworks, so no surprise Mithril didn't make it since more popular frameworks like Vue are also not on the list
The trick is that the same exact optimization is available in Elm and Angular 2 (with different names) so the same argument applies there as well.
The "Do these results generalize?" section makes an argument as to why the numbers you see on a simple TodoMVC app should generalize to apps of any size. When everyone has the equivalent of shouldComponentUpdate, the question becomes: when you finally DO need an update, how fast is it? That can be measured in small apps.
That said, he does make a case that elm is competitive with other frameworks, which is all anyone should take from a language benchmark, in my opinion.
You've got datomic on the server and datascript on the client, transit on the wire, reader conditionals to share code and much more. Plus everything can be modified as its running.
When it comes to web frameworks I don't really care about performance as much as I care about managing complexity. Which is why I'm looking at om.next over all the other frameworks.
And managing complexity is not something you can benchmark in toy projects - every single framework is virtually the same at such a small scale.
But I actually like Javascript.
I guess as a professional Python developer, it would take some time to get used to all the parentheses. I've used Emacs for 20+ years, but outside of elisp I've never been comfortable with s-exprs.
I had never heard of om.next. I think this is what you mean: https://github.com/omcljs/om ?? correct?
> And managing complexity is not something you can benchmark in toy projects - every single framework is virtually the same at such a small scale.
Well, looking at how much garbage was needed to implement todomvc in Backbone kept me from considering it any further :)
And in this you were wise! Or at the very least fortunate.
I think the languages aren't really comparable from a maturity and support pov. Clojure is mainly done by hobbyists and enthusiasts. There is a large gap in terms of tooling that can't be closed in a few years.
It has been a very bizarre experience having dynamic typing on the back end and static on the front end, though. Everything feels slightly topsy turvy.
Sure, performance is good, but I think mostly bottlenecks are user code and the way the JS/CSS bundle is loaded and delivered. If there's a major performance issue in the framework, just submit a bug report. It'll be fixed.
I'm more interested in how productive I can be and how much fun I can have coding with said framework or language—something both Elm and React do well.
Unfortunately, that's an expensive test.
Angular 2 on the other hand. One of my coworkers (to paraphrase) felt like it was GWT all over again (and I agree).
It's about rendering time, when everything is already loaded.
None of them is known to be really fast and the benchmark tells, they all range in the same order of magnitude. So why not include Inferno, Mithril or Preact? Only a few of them are mainstream, so why mess with stuff that is neither popular nor known to be fast.
On top of all of that, you get the benefit of using a framework instead of patched together libraries. Basic tools like intercepting all http traffic at the request/response level is incredibly helpful with larger apps.
The only differentiating factor really left is JSX, and while that may be a personal preference, angular style templating is a lot more comfortable for developers used to server-side templating (JSP, Razor, et al)