4 ms·

I remember looking closely at Elm in 2016. I was a year or two into being the first and only web-focused software engineer at a hardware startup. Working solo,

I remember looking closely at Elm in 2016. I was a year or two into being the first and only web-focused software engineer at a hardware startup. Working solo, moving fast, refactoring aggressively as we iterated and sought our product’s UI, I was craving more help from my language than JavaScript and React alone could offer. Elm was appealing for all of the reasons described in this post. Functional programming, static typing, batteries included so there would be fewer dependencies to juggle. Improve predictability of my code, cut down on bugs, make it harder to screw up, easier to refactor. People using it seemed to love it! But TypeScript’s promise was too good. The JS I already knew but stronger! Keep my existing React code base but refactor it to be safer! No need to learn entirely new syntax; instead, adapt my ways of working to let the compiler be a better collaborator! Easy to break out of it when I absolutely had to! Elm offered many of the same things but require more faith. You invest in different syntax and the Elm way of doing things and you get more safety, better syntax. But the risk of being stuck on a path that’s hard to get off, the cost of ramping up, the challenge of onboarding anyone in the future — that was not in my budget. Even if it was, even if it offered much of TypeScript’s value but did those things better… Was it going to be so much better than it justified the risk? I didn’t see how it could be. I went TypeScript immediately after the 2.0 release so I could use @types packages from definitely-typed. I spent a week refactoring the entire project and never looked back. It was one of the best investments in technology that I ever made. I remember a ton of advocacy for Elm on forums and blogs until then. I’m far from an Elm insider so this is pure speculation but if I had to guess, I’d bet wasn’t the only person who doing napkin math about the right frontend language/tooling investment right around that time. I wonder to what degree the rise of TypeScript clipped Elm’s wings and whether a different timeline, maybe Elm getting started just a year or two earlier, would have allowed the project to hit some critical mass to change the future.

michaelcampbell 3y ago
> maybe Elm getting started just a year or two earlier, would have allowed the project to hit some critical mass to change the future. It's an intriguing thought exercise, but even with a head start it would have had serious issues like it has today; the pace of the language is _SO SLOW_ that in today's world it just has a hard time due to that. I'm not asserting that it SHOULDN'T be slow, that the reasons for doing it that way are bad, or anything like that; it just is what it is, and that's a downside for many people.
DarkNova6 3y ago
Once again, backwards compatibility is the main name of the game. Indeed, if Elm had emerged earlier that could have changed everything, but I'd wager that it is poor leadership and close-mindedness which really killed it off for good (Elm users will deny this, but as the world has moved on, Elm remains stagnant). There is no shortage of complains about the devs uncanny protection of the core language and their opinionated approach to allowing interoperatbility with the JS ecosystem. Which is a shame because pragmatism always works out against dogma. Imho, TS is just a crutch that helped JS to collapse from its own weight but still leaves many issues of FE development out in the open. In an alternative timeline, Elm would have been a path towards more harmoneous fullstack development which is more accepted by people coming from the BE side of things.

michaelcampbell 3y ago

> maybe Elm getting started just a year or two earlier, would have allowed the project to hit some critical mass to change the future. It's an intriguing thought exercise, but even with a head start it would have had serious issues like it has today; the pace of the language is _SO SLOW_ that in today's world it just has a hard time due to that. I'm not asserting that it SHOULDN'T be slow, that the reasons for doing it that way are bad, or anything like that; it just is what it is, and that's a downside for many people.

DarkNova6 3y ago

Once again, backwards compatibility is the main name of the game. Indeed, if Elm had emerged earlier that could have changed everything, but I'd wager that it is poor leadership and close-mindedness which really killed it off for good (Elm users will deny this, but as the world has moved on, Elm remains stagnant). There is no shortage of complains about the devs uncanny protection of the core language and their opinionated approach to allowing interoperatbility with the JS ecosystem. Which is a shame because pragmatism always works out against dogma. Imho, TS is just a crutch that helped JS to collapse from its own weight but still leaves many issues of FE development out in the open. In an alternative timeline, Elm would have been a path towards more harmoneous fullstack development which is more accepted by people coming from the BE side of things.