Live data from Hacker News

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

elm-lang.org

21–30 of 55 posts

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

#22

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 something you can benchmark in toy projects - every single framework is virtually the same at such a small scale.

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

#23

Oh no...benchmarks. 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 th…

I very rarely see technology choice decisions based on performance. It probably should happen more often then it does. If anything most choices are based on popularity.

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.

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

#25
post #23

Oh no...benchmarks. 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 th…

I very rarely see technology choice decisions based on performance. It probably should happen more often then it does. If anything most choices are based on popularity. 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…

There is one benefit of choosing based on popularity - it becomes easier to hire for, and more likely to find engineers enthusiastic about the work. In addition, it increases the number of eyes on it, which can surface difficult bugs/edge cases to get addressed.

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

#27
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).

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

#28
post #25
post #23

Earlier quoted context omitted.

I very rarely see technology choice decisions based on performance. It probably should happen more often then it does. If anything most choices are based on popularity. 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…

There is one benefit of choosing based on popularity - it becomes easier to hire for, and more likely to find engineers enthusiastic about the work. In addition, it increases the number of eyes on it, which can surface difficult bugs/edge cases to get addressed.

> There is one benefit of choosing based on popularity - it becomes easier to hire for, and more likely to find engineers enthusiastic about the work. In addition, it increases the number of eyes on it, which can surface difficult bugs/edge cases to get addressed.

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.

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

#29
I recently heard Evan give an overview of the language and everyone in the room came away excited.

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.

Post reply on HN