Blazing Fast HTML: Elm vs. React vs. Angular vs. Ember • Hacker News Board

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

#51

Post by jmite » Wed, Aug 31, 2016, 2:25 AM UTC

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…

I like my types, without runtime overhead of type checks

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

#52

Post by jmite » Wed, Aug 31, 2016, 2:25 AM UTC

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.

I think server side Elm will come eventually. It's just taking time.

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

#53

Post by throwanem » Wed, Aug 31, 2016, 10:04 AM UTC

asciihacker wrote: post #36

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…

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

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

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

#54

Post by the_duke » Wed, Aug 31, 2016, 10:46 AM UTC

fahrradflucht wrote: post #38

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

The core language docs are ok. --> If you know Haskell!

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.

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

#55

Post by Roboprog » Wed, Aug 31, 2016, 3:16 PM UTC

nkristoffersen wrote: post #40

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.

Likewise, beside custom "directives" (tag libraries) being a bit complex at first. Otherwise, you just start with a page mockup, then progressively refine it by loading some scripting and view models for the data entry or variable substitution.

Angular 2 on the other hand. One of my coworkers (to paraphrase) felt like it was GWT all over again (and I agree).