For those that are out of the loop on the programming language/app framework of Elm, or were never in the loop to begin with, allow me to present some context for why this is interesting:
Elm's always been under the sole control of one person, Evan Czaplicki, and remains so to this day (he's the author of the Roadmap in question). He marches to his own drum when it comes to a lot of aspects of running an open source software community. Especially the aspects where he is resistant to outside interference in his vision for the language. To be clear, this is something I personally kind of like about Elm, but I understand why it draws ire from the HN community and others.
The company employing Evan to work on Elm full time was No Red Ink, which went through layoffs recently and Evan was one of them. The community had some questions about where this left the state of Elm dev, culminating in this thread: https://discourse.elm-lang.org/t/clients-expressing-doubt-ab.... Evan responded, giving the all clear, and put up this Roadmap as a way to put into writing that the project was stable, not abandoned, and give an idea where it's headed next.
> Evan responded, giving the all clear, and put up this Roadmap as a way to put into writing that the project was stable, not abandoned, and give an idea where it's headed next.
Strange, because this document isn't a roadmap at all. In fact it says absolutely nothing, just that Elm isn't going to change for the foreseeable future. And in the Elm community, "isn't going to change" means no updates or bugfixes, period. RIP Elm.
Yeah, it's pretty light on the exact details of what's coming. Although it does justify why that's the case in the last paragraph.
In any case I'm happy making my side projects in Elm as it is and not changing is to me a bonus. Let me put it this way: I have an "empty side project" template I use when I start a new project every month or so, and invariably something about it is out of date every time I do so, and it's one of the biggest barriers to starting new things. Also invariably, updating the dependencies I have baked in turns out to be harder than I expect and eat up a bunch of willpower and time. But it's never Elm that is the culprit! It's always the CSS framework, the bundler, the minifier, the something else. I wish to god that other technologies worked like Elm did to be honest, at a glacial pace. It's not like they ever give me any startlingly new benefit; I have to go through hour+ annoyance just to get back to zero! I liked Tailwind 1.X or whatever, why did they have to update to 2.0 and I have to go through all this trouble... Elm stands athwart that tide and says no, I'll only release an update every four years, and it will introduce only extremely carefully considered, elegant changes. Refreshing.
I mean, looking at the change notes for e.g. Tailwind 2.0 which is the latest one to cause me pain, hardly anything in it was a response to changes in the CSS handling of the browsers. It's all shuffling of namespaces, additions of little conveniences, etc. The sort of thing that makes sense in isolation, but overwhelms one when every part of your stack needs to do it several times per year. Sure, Elm could do the same thing, rearranging the chairs on deck, and make some people marginally happier. I'm really happy it doesn't though because of the externalities that would cause.
The idea that this document counts as a "elm roadmap" explains all you need to know about the future of elm.
On any elm discussion board, you'll find people clamoring for updates, trying to tease out what the language's founder is up to... and this is the result of that, a document that can be summarized as "I'm experimenting with some stuff, stay tuned." Is it any wonder that this leads to anxiety among would-be adopters?
Elm's pluses are:
* elegant language, and fairly fast
* it's got an active community on discord
* it's got a huge stable of packages (https://korban.net/elm/catalog/)
I know Elm is very controversial around these parts, but it's still one of the greatest languages/framework I've experienced (other was to prove programs using Coq).
In my experience, Elm provides the best midpoint between the power of more advanced level Functional Programming Languages and ease of Javascript. I recently trained my friend in India to be able to use it in two weeks (he has only Python/Java experience and comes from testing automation background).
A lot of people complain about the community and the BDFL, but to me it still beats using Javascript (or Typescript) for a personal project. I don't have to worry about runtime bugs in the UI logic (all of them were in the js code in my ports).
The other FP to-js language I've tried is ReasonML (now ReScript), which is also nice, but it aims to become a language which compiles to correct js code (i.e. in your head, you're still writing js code, but with a very good compiler preventing you from writing bad code). This approach has its own pros and cons.
I am currently considering a very interesting approach for my next project. Elm for the UI code, and ReScript for ports (and I understand Elm would be a different flavored language and ReScript, different). Maybe its a crazy idea, maybe it won't work out, but still, I'll get to learn.
For those interested in hearing about Elm creator Evan Czaplicki's experiences with developing open source software and the complexities of internet social dynamics, there is an exceptional talk 'The Hard Parts of Open Source Software'.
Elm's always been under the sole control of one person, Evan Czaplicki, and remains so to this day (he's the author of the Roadmap in question). He marches to his own drum when it comes to a lot of aspects of running an open source software community. Especially the aspects where he is resistant to outside interference in his vision for the language. To be clear, this is something I personally kind of like about Elm, but I understand why it draws ire from the HN community and others.
The company employing Evan to work on Elm full time was No Red Ink, which went through layoffs recently and Evan was one of them. The community had some questions about where this left the state of Elm dev, culminating in this thread: https://discourse.elm-lang.org/t/clients-expressing-doubt-ab.... Evan responded, giving the all clear, and put up this Roadmap as a way to put into writing that the project was stable, not abandoned, and give an idea where it's headed next.