41–50 of 55 posts
No vue.js?
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.
- 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.
Earlier quoted context omitted.
That's not why we use React
Please elucidate? Angular 1.5 has one-way binding, lifecycle hooks, component tree architectures. UI-router is well on the way to become framework agnostic. Redux or redux-style state management is possible with ng1.5, and a pleasure with ng2. 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 le…
Speed is one thing, but the fact that you must replicate your business model client AND server-side with Elm is a huge minus. I would take ScalaJS over any 4 of those frameworks any day.
Speed is one thing, but the fact that you must replicate your business model client AND server-side with Elm is a huge minus. I would take ScalaJS over any 4 of those frameworks any day.
Why not just use Clojure? 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…
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.
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: - 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 interesti…
Speed is one thing, but the fact that you must replicate your business model client AND server-side with Elm is a huge minus. I would take ScalaJS over any 4 of those frameworks any day.
Elm on the frontend and Haskell on the backend is a sensible choice, though at that point you may be better off with PureScript on the frontend.
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.
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: - 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 interesti…
They should really spend more time on making the docs less attrocius for Elm. That's more important than benchmarks. (Coming from someone who appreciates Elm)
Whats the problem with the docs? I mean docs can always be improved but I think the Guide is okay and the package docs are fine...
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".