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?
When there was no React.js, I had in mind something like that and implemented a very simple concept like this with ghcjs. Functional languages tend to let you write this kind of code.
It felt very organized and just worked, then I looked at Elm and said: "that's exactly what I thought I'd do with ghcjs". Then with react.js: "finally somebody implemented the concept in plain javascript".
Which is after all a kind of stricter mvc model for the single-page web applications.
The fact is that with an haskell-like language, the kind of mvc concept is much more structured, you do less design mistakes because the language itself constraints the effects.
So what react.js did is adding these constraints on top of plain js in an elegant way.
In other words: I think the addition of elm is the language itself, for those acquainted with haskell and where type checking matters a lot, compared to plain js.
On the same path, there are other libs similar to react.js that are even faster because they have stricter requirements on how data is mutated.
Thanks a lot for the response. Your comment about constraints improving design makes a lot of sense.
As to libs similar to React, I assume you're talking about Mercury and Mithrill. But I'm quite happy with React's performance and escape latches (shouldComponentUpdate). I'll however switch in a heartbeat if a better design comes along.
The problem is that unlike when I was mutating DOM with spaghetti JS or wrangling with Angular, I am yet to say "why is this thing so darn difficult" with React for almost all use cases I've thrown at it (yet to figure out animations). And the last React.js Conf has taken care of most things that I could imagine improving in web development with Relay and CSS in JS.
I think the core ideas can be used in many settings, that is true. One can use a pattern like this in C if they want. I think there are a couple questions to consider when asking "how does language really help?"
1. How much is the language going to help you independently arrive at nice architecture? It took millions of people 20 years to arrive at this pattern in JS, and it literally happens in every Elm program out there automatically. The pattern described in "The Elm Architecture" really does come from looking at people's Elm code and seeing the naturally arising patterns. So new people don't need to read this post and learn these concepts, commercial users don't need to have strict discipline, the architecture just comes out this way.
2. How much is the language going to fight you or help you when you already know what you want to do? In particular, ADTs are a key part of why this is so nice in Elm, and when you are working in JS or TypeScript, writing "the same code" leads to code that can be quite awful. Even when you know why you want it, it often does not seem worthwhile to fake ADTs. Immutability is another key aspect that's hard to get in many languages. I'll write more about this in some future post, but I think lack of side-effects is another key aspect of keeping the architecture nice.
3. How much is a language going to help a team of 20 keep this up in a large code base? Will the intern or the new hire be able to do it right? Once you start to get cracks, do they continue to grow? If you lack a module system or a type system, are you going to start running into other scaling problems? In this setting, having tools that guide you to the right answer is extremely valuable.
Thank you wheatBread for taking the time to respond.
I appreciate the practical lens with which you've described how the language can influence code. Many language geeks far too often remain too abstract about how a craftsman programmer's life can be improved by the language's design.
ADTs stood out as something I'd love to have in my day-to-do programming toolbet during my short tryst with Haskell. But I was unable to articulate the concrete improvements it can bring into my code, and so it has unfortunately remained a hunch. I eagerly look forward to your post about ADT in the context of Elm and UI programming.
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?