I've been thinking of giving Elm a go, and this walk-through is very helpful in breaking the initial barrier. Exciting to see these ideas finally giving us answers on how to do user interfaces on the web right.
ReactJS has also converged into the ideas proposed by Elm: the Model is explicitly defined (props and state); view is always a function of the Model; and the Model is mutated only through Signals (one-way bound callbacks in plain React, Actions when using Flux).
I have a question for anyone who've worked with both Elm and React. It seems to me that these ideas (component model, well-defined mutation point for state, composability, one-way binding etc.) are what matters more than the language itself. Granted that the language can influence how code is written (immutability, pure functions, ..), but does Elm (or ClojureScript for that matter), drastically improve creation of typical user interfaces just by virtue of the language?
ReactJS has also converged into the ideas proposed by Elm: the Model is explicitly defined (props and state); view is always a function of the Model; and the Model is mutated only through Signals (one-way bound callbacks in plain React, Actions when using Flux).
I have a question for anyone who've worked with both Elm and React. It seems to me that these ideas (component model, well-defined mutation point for state, composability, one-way binding etc.) are what matters more than the language itself. Granted that the language can influence how code is written (immutability, pure functions, ..), but does Elm (or ClojureScript for that matter), drastically improve creation of typical user interfaces just by virtue of the language?