Når jeg nå leser noen av mine poster, innser jeg at jeg burde nok ikke fått lov til det jeg heller.

Bare sier at Norsk Webforum anno 2005 var peak norsk web community

Opplevd koseligere! Som ikke ekskluderer det jeg anser som den en av de viktigste halvpartene av @kortslutning.fun

I samme anledning kan vi også annonsere at den andre gjesten blir Vilde Jølstad Paschen fra Visuelle Historier i NRK.

Dermed har vi en komplett lagoppstilling med Elise (@frkfrontend.no), Vilde, Mikael og Stian.

Vi gleder oss!

Noen ville kanskje kalt det barnslig. Jeg kaller det disiplinert!

Liker initiativet! Kanskje i år kan @mollerse.bsky.social og jeg endelig vinne Vixen awards

Veldig autokratisk stil, rett og slett. Men var ikke det som skjedde da, heldigvis. Mer kanskje spoiler på om vi skal utforske muligheten til andre faggrupper.

But again, it highly depends on "what". Ex. for some sub-part of a solution that has some value of deterministic reproducible UI, you might be able to use it with success within your team. But IMO, there are several alternatives that is more future proof without the stagnant BDFL governance

TL;DR: In my mind Elm "died" for use in web applications in 2018 after Elm 0.19 was introduced. In 2020 I would have a hard time recommending people using it for business critical solutions. And in 2025 I would only recommend it for people wanting to explore ML based languages or have fun with PLT.

Evan did a meetup some years ago, saying something about the future of Elm. There might be updates since then (I haven't kept track), but essentially he and his wife was working on an online sandbox-y solution for running Elm applications (kind of like Glitch (RIP)?).

I think these limitations showed the ambitions of Elm: It was more as a learning tool for good abstractions and pure functional implementations. Which I think it does beautifully. And is something that is valuable. So in that sense I'd say just like academic languages as Oz, Elm is not still dead.

... you CAN do it, but in my experience it is impractical and hard to scale to typical application level code bases. The lack of semantics for properly handling side effects (monads, signals, ffi, whatever) means you can't easily do things like date parsing without portals to JS.

Effectively I think Elm died as a general purpose application language in the language changes of 2018. They removed Signals (Behaviours) to make the language simpler, but effectively removed a lot of it's power. Not just escape hatches, but abstractions needed for a growing system.

I think it highly depends on "what" and for "who". In Norway, due to historic reasons and technical lobbyism from a group of Elm evangelists around 2016, it actually lived fairly long and caused me to be involved in a code base with Elm in 2020 - 2022. And I have some (subjective) thoughts on this 🧵