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.
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!
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.
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.
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.
We discussed this to death on the mailing list, and this was definitely a consideration!
People searching for it online will very likely be searching for "elm union type" where they'll quickly find examples and docs. Furthermore, you can prefix the term "union type" with stuff like "closed/open" and "tagged/untagged" to start making finer grained distinctions as need higher degrees of precision. In Elm it is always tagged and closed, so in discussions within the community, adding those prefixes is redundant. Finally, if you start with the term "union type" it becomes easier to think about what an "anonymous union type" might look like (like OCaml's polymorphic variants or open variants) ;)
More broadly, if people do run into the term "union type" in other languages they will be building intuition in exactly the way I'd like: it's a way to use different types in the same place. Things happen to have this extra tag thing in Elm, but it's not so different than anything people do in JS or Clojure or Racket or TypeScript or C or whatever else. I think bringing that connection out is a major benefit of this naming choice. The goal is to feel really welcoming and friendly, and my personal preference is to build on people's existing intuition as much as possible. If someone comes from JS and does not see all the subtleties of this discussion immediately on day one, they are actually having a better experience because they can learn the info as it becomes relevant to their daily usage. Hopefully a much nicer learning curve!
I realize I am making a somewhat controversial choice, but the idea is that statically typed FP people are building artificial barriers by being sticklers about this, rather than just prefixing for precision. You may not agree with all this, but we thought it through pretty extensively, and that is the reasoning!
I started looking into Rust again while picking the term "union type" because of their choice to use the term "enum". I ran into the Result type in some code I was reading and it just made so much more sense to me as a new person learning the language. Basically, it made it self-evident to me that "a library for error handling should be named with error handling in mind." You will also see a Result type in some Haskell libraries so it's not unprecedented there.
I also got tired of explaining "the good result goes in Right, because it's 'Right'" like I'm endlessly telling a bad dad-joke.
The debugger has been available online for a while ( http://debug.elm-lang.org/ ). It explains how it works and has some more interesting examples than stamps :)
Type inference works on all Elm programs, but it's best practice to add type annotations.
In the WebGL examples, I felt it made things a bit clearer since folks are probably not familiar with how WebGL works. Once you get comfortable reading types, it helps you see how things fit together, and they definitely helped me learn John's API when I was new to it :)
But if you don't need/want type annotations, you can totally take them all away and they'll be inferred! How did having them effect your experience of looking at the examples?
The most novel stuff was about how to handle asynchrony and concurrency without unexpected/unwanted glitches, though I think formulating things in a way that is simple, accessible, and efficient was important too. My thesis ( http://www.testblogpleaseignore.com/wp-content/uploads/2012/... ) goes through all of the previous literature that I could find at the time. It frames my view on Elm fits into prior work and how I understood things at that time, but that section got cut from the PLDI version unfortunately.
Whoa, I'm surprised to hear that I "didn't know anything about FRP when I made Elm". A huge part of developing Elm was doing literature review and making new contributions to FRP ( http://people.seas.harvard.edu/~chong/abstracts/CzaplickiC13... ) and "making things up as I went along" was certainly not how we ended up with a nice system. I don't know why you didn't talk to me at BayHac before making statements like this.
Conal and I definitely disagree about what is important to emphasize. FRP is a term that is used in many different ways, in the same way that FP is a term that is used in many ways. I see this as a testament to the power of the idea, and it seems like claiming that this and that are not really FRP is limiting the impact of the original work. We definitely need more precise terms though!