Oh no...benchmarks.<p>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.<p>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.<p>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.
Every single comment here is focused on just one aspect of this article: speed. Far more interesting points the article covers are around _how_ Elm optimizes and _how_ developers optimize Elm code. From the conclusion:<p>- Optimizing Elm only touches view code, unlike everyone else.<p>- Optimizing Elm cannot introduce sneaky bugs, unlike everyone else.<p>- These results should generalize to apps of any size.<p>Also interesting is how Elm's immutability allows it to use requestAnimationFrame by default, which plain vanilla JS libs can't use by default.
"Speed in Milliseconds" should be changed to "Time in Milliseconds". More speed is a good thing, but more time is not. Using "speed" instead of "time" in the chart title makes it sound like bigger bars are better, but that's just the opposite. Plus, speed isn't even a measure of time (like milliseconds); it's a unit of distance (or some equivalent) divided by time.
I recently heard Evan give an overview of the language and everyone in the room came away excited.<p>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.
<a href="https://github.com/elm-lang/virtual-dom/blob/master/src/Native/VirtualDom.js" rel="nofollow">https://github.com/elm-lang/virtual-dom/blob/master/src/Nati...</a><p><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.<p>[1] <a href="https://github.com/Matt-Esch/virtual-dom" rel="nofollow">https://github.com/Matt-Esch/virtual-dom</a>
They should really spend more time on making the docs less attrocius for Elm. That's more important than benchmarks.<p>(Coming from someone who appreciates Elm)
For the love of * (pick your preferred deity, I'm going with Flying Spaghetti Monster), stop benchmarking on ridiculously simple TodoMVC apps.<p>They are not at all representative of the complexity costs that emerge from real apps, which often mitigate differences between frameworks considerably.<p>(Apart from the fact that creators benchmarking their own framework know how to optimize it best).
As someone who has started to explore (and enjoy) elm, I have to say that speed is not one of the major selling points for me. Rather, seeing that it has at least competitive speed is just dodging a potential deal breaker. It could smother me in kittens and do my taxes, but if a framework only renders three frames per second, I definitely won't use it. Elm being in the same ballpark (slightly better? slightly worse? doesn't matter) means that I can see if the other features of the language entice me to try it out. They did, I did, and I really like it (even though apps that use random a lot end up being structured in a way that is strange to my brain).
Mithril's omission is telling, as it it often faster than even Elm by 50% or so.<p><a href="http://lhorie.github.io/todomvc-perf-comparison/todomvc-benchmark/" rel="nofollow">http://lhorie.github.io/todomvc-perf-comparison/todomvc-benc...</a>
As a React user, I'd be really curious to see what these benchmarks look like when you're dealing with larger, more complex projects. I was under the impression that React scales well when dealing with lots of nested components and diffing the updates for each.
I believe the saying is "Lies, damn lies and benchmarks".<p>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.
Speed is one thing, but the fact that you must replicate your business model client <i>AND</i> server-side with Elm is a huge minus. I would take ScalaJS over any 4 of those frameworks any day.
Those benchmarks should be done by someone independent from one of the tested frameworks though. Hard to trust the methodology, especially with Elm emerging as the "winner".
The hard, but very useful, test would be getting a largish random sample of noobs and seeing which framework lets you <i>write code</i> the fastest.<p>Unfortunately, that's an expensive test.
Whats the difference between a few seconds of loading time for a site that only needs to load its bundle once? Sure its nice for it be faster but the main benefit I thought is you don't need to reload pages as you navigate.
react fanboys are gonna be a little upset that you showed that angular is faster in your benchmarks. They spent months flooding internet saying react was faster and you're contradicting that.