I updated the official guide (https://guide.elm-lang.org/) to try to do a better job at that. It covers "routing" and JS interop much more clearly I think. So I recommend starting there and then asking around in the community if you run into anything!
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.
I think it is worthwhile stopping by the Elm slack channel to ask this. You have framed the question in a weird way. The answer is kind of "these things are not really related in any direct way" but I feel like you are asking a different question. Point is, ask on the slack channel and folks will help clarify :)
Definitely not ignoring. I talk about the relation between Elm and that sort of stuff in https://youtu.be/Agu6jipKfYw Lots of things look similar in this area that are not.
I also offer an analysis of "higher order" observables in https://youtu.be/DfLvDFxcAIA, and the big difference is the underlying thread architecture you get using these two.
I hope I'll be able to make these sorts of things clearer in time!
They key difference is that when you create an event emitter in JS, you now have a resource to manage. Where does that go in your app? In each component? How does the component know how to turn these off if it is no longer in use? In the root? How does the root know who needs what?
So basically, the difference is in resource management. The web socket example makes this clearer. You never have to ask "who owns the connection?" to use the connection.
> The web socket example makes this clearer. You never have to ask "who owns the connection?" to use the connection.
To be fair you can do this in javascript as well using a messaging pattern similar to elm. Many libraries like postal.js (synchronous) and msngr.js (asynchronous) support a messaging pattern where you can access resources without caring who owns them.
I'm sure we could keep going, but the point I'm making is that Elm is very close to Haskell, and if you like Elm you will definitely like Haskell. I don't know if the same can be said about going from Haskell to Standard ML because I haven't... yet.
I think so! I'd like to get Elm running way faster than JS in browsers (which is possible thanks to some design choices) and that'd involve getting all this together. That opens things up on lots of different platforms, including servers. I also expect the next release to make things nicer on node.js as a first step in this direction. Point is, I think we'll start seeing folks doing server stuff, and it's a goal of mine to generate machine code for lots of reasons! It's a big project so I'm not setting a timeline at this point though.
Also, thanks for taking a look at Elm! I think of it as a member of "the ML-family" of languages and I draw from a lot of lessons from working with these tools and seeing what issues have come up for other folks, both within the typed functional world and not.
Actually, while it's still not direct machine code, if you can target Javascript as a backend I bet you can target Lua, which has very similar but less weird semantics; that means you get to run it on LuaJIT. That gives you a tiny, very very fast VM and garbage collector.
You need a garbage collector either way, so doing one implies you have pretty much succeeded at the other. So it's like two stepping stones that are right next to each other and quite a long jump away :P I think we'll get there though!
The same can be done for HTTP or WebSockets if you have needs that are not met by the existing APIs. Furthermore, the next major release is focused on drastically improving these APIs.
So there's a safety valve right now and there's a plan of how to make things excellent. I would not block on this, but I am also relatively biased :)
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.
At one point we were trying to name every part of a union type in Elm. Calling things "tags" instead of "constructors" seemed quite nice, but ultimately, it seemed like we couldn't get the perfect name.
