[HN Gopher] Ask HN: What Happened to Elm?
___________________________________________________________________
Ask HN: What Happened to Elm?
I remember years ago I spent sometime to learn it as I was curious
how a purely functional front-end language feels like, and
genuinely thought it had a good chance of being massively adapted
in the near future, especially with what seemed like a vibrant
community. However, I got distracted by a data science career and
toolchain. Am in the process of starting my first SaaS as a solo
founder and was looking at what languages to use and was surprised
to see that Elm...seems dead? As an example I did a search on
hackernews and it hardly got mentioned in the last year (both
comments and posts!) Am wondering if anyone can provide some more
light on what happened to the language? Is it a safe bet? And what
is a suitable good replacement for it?
Author : ak_111
Score : 58 points
Date : 2023-02-10 21:31 UTC (1 hours ago)
| quickthrower2 wrote:
| My opinion: I wouldn't use Elm as a solo founder, as you want to
| put your energy into shipping and Elm, while very good will
| probably slow you down when you hit the thing it cannot do, and
| then you need to fork it and change the core code.
|
| React on the other hand, has a vastly larger ecosystem already
| and is designed to work well with 3rd party code.
|
| Middle ground is using an Elm-like architecture within another
| framework. The keyword here is "TEA architecture" where TEA means
| The Elm Architecture, or also MVU (Model View Update)
|
| Elm is excellent and has done a lot of good for the front end
| world through knock on effects. It is good fun to use. I have a
| few projects based on it open source. So I am not against Elm I
| just think it will be annoying if the goal os to ship fast.
| schemescape wrote:
| I'd never heard of Elm until I ran across Iced [1] ("Iced is a
| cross-platform GUI library focused on simplicity and type-safety.
| Inspired by Elm.").
|
| Has anyone who liked Elm tried Iced? Any thoughts?
|
| I've been checking out various GUI libraries for Rust, but I
| don't have time to investigate them in depth--so I thought maybe
| someone might have already done the investigation for me :)
|
| [1] https://docs.rs/iced/latest/iced/
| mrozbarry wrote:
| I've developed a few Elm apps, and tried Iced. I liked Iced,
| but I'm not a proficient rust developer, which really limited
| what I could do with it.
| gregors wrote:
| They made HUGE mistakes not listening to feedback from their
| userbase. It's still a cool piece of tech, but they wouldn't
| budge on a lot of things that were dealbreakers to a lot of
| people. That's their right to do so of course. In a very
| competitive area of frontend, people chose to spend their effort
| and time elsewhere.
| satvikpendem wrote:
| TypeScript won. I was watching this video by Evan Czaplicki the
| creator [0], and what struck me was that back then, Evan was
| absolutely right. He was right that in the high level, we needed
| a typed JS, but he was wrong in the lower level details, at least
| in terms of market share. TypeScript won precisely because it
| doesn't start off as intimidating for JS users, while others like
| Reason and Elm died off, but ironically TS is way more complex
| than either of the others in its type system.
|
| Another factor for this is that Syntax Matters(tm). When Gleam
| (language on the Erland runtime, cousin of Elixir) started out,
| it had a Haskell-like syntax, but this was found to be a barrier
| for adoption, so when the creator changed it to be more C and
| Rust-like, the adoption rate picked up significantly [1]. In the
| same vein, perhaps Elm was just too esoteric for those coming
| from JS. I strongly believe the reason Rust became so popular is
| that it's an ML in C clothing, rather than being a pure ML like
| OCaml. With curly braces and all, it's more accessible and then
| people start learning about the more functional features like
| maps, folds, and so on.
|
| Elm also had quite a rocky history with the BDFL not allowing
| other people to use the features the compiler maintainers could
| use, such as escape hatches, which are documented in other parts
| of HN. This article [2] is a particularly good overview of why
| some people left.
|
| [0] https://www.youtube.com/watch?v=oYk8CKH7OhE
|
| [1] https://news.ycombinator.com/item?id=22902462#22903210
|
| [2] https://news.ycombinator.com/item?id=22821447
| jokethrowaway wrote:
| Typescript didn't win anything and its type system doesn't
| deliver nowhere close to elm s value.
|
| Elm was simply to risky given how quickly the maintainers
| fenced off native access.
| satvikpendem wrote:
| It won user market-share which is what OP's post is about. TS
| is not "dead" like Elm is, quite the opposite.
| jupp0r wrote:
| They were never competing with each other and serve
| completely different use cases.
| Hermitian909 wrote:
| > Reason and Elm died off
|
| I'm still quite sad that Reason died. The syntax was much more
| comfortable and familiar than OCaml's while still delivering a
| ton of power. Have an optimizing compiler run on your JS was
| actually quite helpful. As a bonus you could have your backend
| running either Node or OCaml depending on your needs (ecosystem
| vs perf).
|
| Was really unfortunate when the drama around Reason the
| language vs the Bucklescript compiler blew up and resulted in
| ReScript (a language that appealed to approximately no one in
| the existing user base).
| bmitc wrote:
| It's rather unbelievable to me that people find ML syntax
| unfamiliar and off-putting. It makes no sense, and I have
| always found it disappointing that both Rust and Gleam moved
| away from it.
|
| People seem love Python syntax. ML syntax is just more regular,
| consistent, and typed. How is that worse?
| beefman wrote:
| AppRun is a JS/TypeScript library inspired by Elm:
| https://apprun.js.org/
|
| Does very well on comparisons of performance and code size:
| https://medium.com/dailyjs/a-realworld-comparison-of-front-e...
| jokethrowaway wrote:
| It truly was the best frontend language
|
| Unfortunately or fortunately, beauty and utility emerge out of
| decentralised chaos not out of dictatorship, no matter how
| enlightened
| chris_armstrong wrote:
| When you look at Elm with similar projects, like Melange or
| Rescript, they're all "dead" in the sense that they aren't the
| moving targets that most people expect of the Javascript
| ecosystem.
|
| That said, they are still under active development with their own
| small communities achieving what they set out to do, and no more.
| No expansive rewrites or fancy new features.
|
| Compare with Typescript, which always is "improving" because it's
| trying to provide type inference around a loose Javascript model,
| so there's always more complexity to be added.
| PragmaticPulp wrote:
| > That said, they are still under active development
|
| I don't know who would consider Elm to be under active
| development, given that the last release was in 2019 and most
| of the repo hasn't been touched for 2 years or more:
| https://github.com/elm/compiler
| jmclnx wrote:
| For some reason I thought they changed the license, thus people
| leaving it.
| fyzix wrote:
| Maintainers were too tenacious imo. Inflexible to a frightening
| degree. I liked the architecture and used it extensively with f#
| + fable + elmish but these days...I'm using sveltekit +
| typescript for everything frontend, for it's unmatched velocity.
| akamaka wrote:
| Elm was fun and I learned a lot from it, but a purely functional
| language doesn't fit cleanly on top of a real-world web browser
| environment, which is rife with states and side effects.
|
| It was possible to build some elegant projects with Elm if you
| accepted the limitations, but the messy reality of web apps
| doesn't fit within its pure model of the world.
| GiorgioG wrote:
| Elm is and always has been (AFAIK) a one-man project. It's not
| suitable for anything that you depend your livelihood on. Look at
| Svelte, Vue, React, Angular.
| epolanski wrote:
| I really don't like such comments that like any nuance.
|
| I know multiple companies that use Elm and many people depend
| on them for their livelihood.
|
| I would not recommend it due because it has never been a really
| open source project and only the core maintainers were allowed
| to write libraries that interfaced with JS apis without the
| need of ports.
|
| Still, it baffles me how many people would chime in and feel
| compelled to comment regardless of the fact that hundreds of
| projects out there make money with Elm.
| BeetleB wrote:
| When your parent said "one-man project", he is referring to
| Elm, not the project using Elm.
|
| Elm was/is highly dependent on one person.
| eddsh1994 wrote:
| And if the sole developer of Elm forgot to pay for their
| domain that hosts packages for Elm all those projects would
| be broken forever.
| matsemann wrote:
| There were (are?) multiple core contributors. A person at my
| previous company even got to spend one day a week or something
| contributing.
|
| But even with multiple people, I did get the impression it's
| not exactly a committee when it comes to what changes get
| merged.
| roebk wrote:
| Elm is perfectly stable and usable. It's a shame there's not a
| little more communication / a wider core team working on the the
| parts of Elm that could reduce the friction for the average web
| development task.
|
| There's Gren https://gren-lang.org/ which is a fork of Elm. Gren
| has nodeJS and web storage a support, along with a package
| manager which can install from github (iirc). I'm eagerly
| watching the development of this project, hopefully it can
| provider value and grow into a strong alternative.
|
| I loved working with Elm. It forced me to grow as a developer and
| appreciate all the benefits advantages that comes with a pure
| functional programming language. I truly hope Evan can start to
| win back the lost mindshare.
| softinio wrote:
| I think the alternatives to consider would be:
|
| - https://www.purescript.org/
|
| - https://reasonml.github.io/en/
|
| Or like others have suggested typescript and the usual libs and
| frameworks
| innocentoldguy wrote:
| I loved working with Elm. For me, it was the best of the frontend
| frameworks due to its functional, Haskell-like nature (Edited to
| add this comment: totally my subjective opinion, of course). I've
| found Phoenix's LiveView to be the best alternative for me so
| far.
| matsemann wrote:
| After working 3 years using elm exclusively for the frontend,
| it felt dirty going back to react when changing jobs.
|
| The previous huge project had basically zero bugs. The code was
| nice to work with, could trust things were working after a
| refactor without even clicking around in all interfaces. Could
| trust the typing and forced handling of all state to notify if
| you broke something. Of course, no escape hatches meant you had
| to program things the one correct way, no shortcuts possible.
|
| While the react codebase I work in now is so brittle in
| comparison, and scary to make changes in.
| innocentoldguy wrote:
| This was my experience as well. Elm is/was damn solid.
| vosper wrote:
| They essentially stopped development at 0.19 saying that it was
| good enough, development went quiet, and then the lead developer
| went off to work on other things.
| alphanumeric0 wrote:
| I just applied for an Elm job a month ago. It's not dead, it's
| just super niche.
| rstarast wrote:
| There's an active fork of Elm in https://gren-lang.org/.
| josephcsible wrote:
| In version 0.19, the core team hardcoded a whitelist into the
| compiler of which projects are allowed to use native code (which
| happened to basically be the core team's pet projects). This
| basically crippled the language beyond usability for everyone
| else. https://news.ycombinator.com/item?id=22821447
| https://news.ycombinator.com/item?id=17842400
| https://news.ycombinator.com/item?id=16510267
|
| As for a replacement, I'd look towards Haskell. At a language
| level, it looks really similar to Elm, and it's been having a lot
| of work done towards being more practical on the Web lately,
| e.g., GHC 9.6 getting a WASM backend merged.
| satvikpendem wrote:
| FYI use double newlines between paragraphs/links, otherwise it
| shows up as one line.
|
| I completely agree with you, the way the Elm team handled it
| was not conducive to collaborate usage of their language, it
| was more like only they wanted to use it fully.
| matsemann wrote:
| This is FUD. For any normal web app you don't need that
| functionality, just use the built in "ports" concept to
| interface with JS stuff.
|
| And it being open source means nothing stops you from forking
| it and adding your own native modules. Reason no one has done
| it is it's no need, and doing thinga that way would break the
| promises the compiler makes about no runtime bugs.
|
| As for a replacement (if one feel that's needed), gren-lang is
| a kinda fork (but no promises of being backwards compatible) by
| a core member.
| PragmaticPulp wrote:
| > This is FUD. For any normal web app you don't need that
| functionality, just use the built in "ports" concept to
| interface with JS stuff.
|
| The change was handled extremely poorly. I only knew one team
| using Elm in production at the time. They went from being
| huge proponents of Elm to recommending against it after the
| 0.18/0.19 changes and drama upended a lot of their work.
| [deleted]
| EdSchouten wrote:
| Also the fact that their package manager is strongly coupled
| against https://package.elm-lang.org/. There is no way to
| override it. This means that if that package site ever goes
| down, you will be left with an unbuildable project. Seems
| pretty risky to me.
| jedberg wrote:
| Looks like the last update was in 2005:
|
| http://www.instinct.org/elm/#download
|
| Oh, you weren't talking about the email client. :)
___________________________________________________________________
(page generated 2023-02-10 23:00 UTC)