Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blazing Fast HTML: Elm vs. React vs. Angular vs. Ember

elm-lang.org

Post reply on HN
Print view View original

31–40 of 55 posts

Re: Blazing Fast HTML: Elm vs. React vs. Angular vs. Ember

#31

Post by jeremiep »

the_duke wrote: post #20

For the love of * (pick your preferred deity, I'm going with Flying Spaghetti Monster), stop benchmarking on ridiculously simple TodoMVC apps. 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).

I'd rather see articles about how to manage complexity at scale rather than about performance in apps so simple you'd be better off in raw javascript anyways.

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.

Re: Blazing Fast HTML: Elm vs. React vs. Angular vs. Ember

#32

Post by Roboprog »

jeremiep wrote: post #22
asciihacker wrote: post #4

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…

Or just use Javascript as-is, with perhaps Node.js or Nashorn on the back end.

But I actually like Javascript.

Re: Blazing Fast HTML: Elm vs. React vs. Angular vs. Ember

#33

Post by Roboprog »

Roboprog wrote: post #32
jeremiep wrote: post #22

Earlier quoted context omitted.

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…

Or just use Javascript as-is, with perhaps Node.js or Nashorn on the back end. But I actually like Javascript.

And not so much care for the transpiler hoop jumping routine.

Re: Blazing Fast HTML: Elm vs. React vs. Angular vs. Ember

#35

Post by wheatBread »

lcarlson wrote: post #34

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.

It "scales well" because of shouldComponentUpdate. That lets you avoid building huge chunks of virtual DOM as your app becomes very large.

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.

Re: Blazing Fast HTML: Elm vs. React vs. Angular vs. Ember

#36

Post by asciihacker »

jeremiep wrote: post #22
asciihacker wrote: post #4

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…

> Why not just use Clojure?

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 :)

Re: Blazing Fast HTML: Elm vs. React vs. Angular vs. Ember

#37

Post by grumblestumble »

atoko wrote: post #24
wnevets wrote: post #21

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.

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 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)

Re: Blazing Fast HTML: Elm vs. React vs. Angular vs. Ember

#38

Post by fahrradflucht »

the_duke wrote: post #12

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

Re: Blazing Fast HTML: Elm vs. React vs. Angular vs. Ember

#39

Post by grayrest »

donjh wrote: post #2

Wow - I'm a big fan of React, so I'm a little disappointed to see that it was the slowest of all.

React has never been about speed (if you look at the official dev posts, speed is never listed as a top priority) but rather about not being slow (sCU check and whatnot). It's the slowest vdom implementation I know of, but it's fast enough and the network effects from being the biggest make it good enough. If you're interested in faster vdoms then check out inferno (fast), snabbdom (simple), mithril (compact), or domvm (flexible).

Re: Blazing Fast HTML: Elm vs. React vs. Angular vs. Ember

#40

Post by nkristoffersen »

Roboprog wrote: post #26

The hard, but very useful, test would be getting a largish random sample of noobs and seeing which framework lets you write code the fastest. Unfortunately, that's an expensive test.

This is why I love angular 1.x so much. I was able to make a product in no time with no experience. Everything was so straight-forward for my mind.
Post reply on HN