Learning Elm by porting a medium-sized web frontend from React (2019) | Hacker News Reader

Learning Elm by porting a medium-sized web frontend from React (2019)

benhoyt.com

103 pointsTomte90 comments

The year in this link is very important. In the following year, the Elm team decided to not pay attention to the maxim "perfect is the enemy of good" and crippled their FFI story, making it impossible to actually use the language in production[1].

I would recommend to steer clear of a language that makes these sorts of decisions -- that certain features are off-limits to the regular developer because they can't be trusted to use them correctly -- because if you find yourself in a situation where you need that to solve your problem, you're trapped. I included Go in the set of languages I would recommend steering clear of for years, due to their decision to allow their own `map` type be a generic[2] type but no user-defined types could be[3], leading to ridiculously over-verbose codebases, but they have finally corrected course there.

If you're looking for something kinda like Elm but not likely to break your own work in the future, I'd recommend checking out ReasonML[4] instead.

[1]: https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/ [2]: https://go.dev/blog/maps [3]: https://go.dev/doc/faq#beginning_generics [4]: https://reasonml.github.io/

It's incredible that on just about every piece I've ever read about Elm since they made that decision, this has been the first, second, and third comment. Wanting to try Elm for myself, I disregarded this advice, and.... immediately ran into the exact same problem! I've never seen such a promising project so conclusively killed by pure developer pigheadedness. And, amazingly, they've never backed down at all. They don't seem to mind that they maimed themselves.

A purity pledge is very typical of cults. It's both a filter and an enforcement mechanism.

This may not apply to Elm. But I imagine it can feel easier and more rewarding to manage a community that's more like a cult than a typical free-for-all open source project.

I think it’s probably harder and less rewarding to manage a community where you’re constantly taking flak for a technical decision people don’t like (and which those people generally don’t engage with the pros and cons of said decision!)

Out of curiosity, what did you try to do that you hit that issue right away? I've been writing Elm apps as side projects for years, and never even come close to the kernel thing being a problem. My apps are mostly graphically undemanding games and helper tools. What are the types of applications where this becomes an issue right away?

Most likely they didn't understand Ports and immediately wanted to reach for kernel stuff.

It's odd and rude to declare someone incompetent from so little information. Especially when the same problem is widely reported by other developers.

In my case, it was a regex supplied by the user. Elm 0.18 had no support for constructing a regex at run-time. So I made a package that wraps native RegExp. When 0.19 was released, I couldn't upgrade because of those 5 lines. The regex package eventually got regex.fromstring(). So I could've upgraded. But at the time I was bumping against limits accessing Intl and I really hated the prospect of begging some maintainer for access to a browser api.

Elm was the most fun I ever had developing a browser app. Then they decided I shouldn't be allowed to develop a ShootMyFoot module, and it stopped being fun overnight.

Yeah, I really feel this a good way to divide developers into two types. There are those like me, to whom the philosophy of discourage foot guns systematically sounds kind of brilliant. To put it in flattering terms, it's pay a short term cost for the long term and hard-to-perceive but very real benefits (making certain categories of errors completely extinct). To put the other side in flattering terms: they're not letting the perfect be the enemy of the good, and never compromising on their vision because the tech is holding them back. I think the latter is definitely dominant in the discipline. I'm glad that at least Elm carries the torch for the former though.

The Elm people themselves worked with the impure browser api all the time. They just don't want me to do it. So it's not even a foolish consistency but just base gatekeeping. Turns me right off.

If you want to divide into two camps how 0.19 was received I'd say it's people who were maintaining a substantial Elm project on the one side and people who weren't on the other. Maybe if you're carrying a torch don't drop it on the ecosystem.

As a Elm non-user, naive question: would it be possible to use the JS interop (ports) for this, at cost of some clunkiness?

Yes the answer is always ports when this topic comes up. Unfortunately one can only pass some basic types through ports. Passing a RegExp or an Intl.DateTimeFormat is not possible. It needs a wrapper on the Elm side, and the Elm people decided I can't be trusted to write this wrapper for me.

Back then if I wanted to search a list of strings for entries that match a regex supplied at run-time, I'd have to pass the whole list through a port, filter it outside, then pass it back in. Rather than just using the filter function. Ports are asynchronous messaging which means I have to restructure the whole code and wait for a state change when the filtered list is returned.

Let me cite the Elm docs on ports[1]: "Definitely do not try to make a port for every JS function you need."

So! Where does that leave me? Unsupported, that's where. Because I need a JS function. In 0.18 unsupported was fine. They broke it for 0.19 and the project died. Maybe it was dying of other causes anyway, but that one action sure drove people away.

[1] https://guide.elm-lang.org/interop/ports

Yes, ports or custom elements are the recommended options, https://github.com/elm-community/js-integration-examples

There are a bunch of other options/workarounds/hacks depending on the need. E.g. using getters or creating proxy objects https://github.com/anmolitor/intl-proxy, or event listeners, or postprocessing of the generated JS code, but those shouldn't be the first idea to reach for.

> So I made a package that wraps native RegExp. When 0.19 was released, I couldn't upgrade because of those 5 lines. The regex package eventually got regex.fromstring(). So I could've upgraded.

The last commit to the regex package was in May 2018, and Elm 0.19 was released later in August. https://github.com/elm/regex/commits/1.0.0/

So it seems like by the time of the official release you could have replaced your five lines with `Regex.fromString`.

But the missing Intl API is definitely a huge pain, and I understand that you were switching away if you needed it extensively. Or expected to want other sync APIs wrapped.

A common way to solve something like this is with proxy objects like in https://github.com/anmolitor/intl-proxy but it does not give access to every feature in a nice way.

I went the route of least resistance and built the Elm compiler without the Kernel code check. But in the past few years I hardly needed that anymore.

Thanks for the correction regarding the Regex timeline. Git commits are generally more reliable than my memory.

Reason is a lovely, OCaml-esque language in the same functional vein, but I would say Gren feels like a great spiritual successor to Elm.

https://gren-lang.org/

Gren is a fork, not a spiritual successor. And not only did it not fix that problem, it made it worse: https://news.ycombinator.com/item?id=36275171

Perhaps because it's not the big problem a few people make it out to be..

Yeah, I just read this further down in this topic. Really bummed about it, Elm always seemed so promising, and I thought a healthy fork was what was needed.

I just don’t understand the reasoning for this choice.

along those lines, Zokka is a fork of elm that appears to be mostly dedicated towards bug fixes that Evan (the creator of elm) refuses to acknowledge or merge.

https://github.com/Zokka-Dev/zokka-compiler

edit: there's also Roc, https://www.roc-lang.org/, a language started by Richard Feldman who I believe was a former elm core team member. I think Roc aims to accomplish different things than elm, but definitely feels like a spiritual successor

The commitment to bidirectional compatibility means that Zokka can't fix the problem that GGP was talking about.

> making it impossible to actually use the language in production

Just FUD. I've been on a big team writing a webapp used by hundreds of thousands each day. While it's not necessarily my own first choice, it was great and the least error prone piece of software I've written in my career.

It is impossible if you're being responsible. You don't choose a technology that could potentially block you from solving problems in the future unless it brings a huge value to you.

Elm's value proposition is mostly being a functional language with an opinionated MVU library baked in, so you can reproduce that value with a better functional language and selecting a similar MVU library in that other language, which means it should never actually cross the value bar above the risk it brings if you need a browser feature it doesn't support and actively prevents you from accessing.

Now you're moving the goalpost. You said it was impossible to use in production. Which is clearly wrong.

I am just clarifying why I consider it impossible.

Production is not some place you're supposed to cowboy code, but instead have a reasonable expectation that you will be able to continue supporting it for as many years as it operates, and it's impossible for anyone to responsibly use technology with known limitations that have bitten other real engineering teams that they can find zero workarounds for.

If you don't consider that an impossibility for a production environment, then I certainly wouldn't want to work with you on a team with production responsibilities.

Zero workarounds seems overly dramatic, here are a few: https://news.ycombinator.com/item?id=39567011

If you want to rely on them for every possible future requirement or rather want to pick another tool is another question :D

Anyways, just building the compiler without that check was also not that hard.

I've also had the pleasure of maintaining an Elm codebase. It was filled to the brim with state update bugs. You could never trust what you saw in your browser. Nobody in the team understood how the codebase worked. I spent days implementing some extremely simple changes, which barely worked (to the same standard as the rest of the codebase). Never again.

I don't blame a Rust-codebase for being bad just because I don't know Rust.

So, your positive anecdote was somehow valuable for the discussion, but my negative anecdote had absolutely no value? That's how anecdotes work?

My positive anecdote proved that Elm is usable in production, which was the FUD I was refuting. Yours were irrelevant in that context.

I've seen the word FUD 4 times on this page already. The "elm defense force" sounds a lot like cryptobros defending their rug pull. It's such an odd piece of language to adopt over people not liking some javascript compiler for perfectly valid reasons.

Funny that you have this impression.

To me it looks more like the elm-haters are out in force and the Elm users don't participate anymore on this site.

Many hateful comments here below a historic post prompted me to create a new account after a detox phase of >10 years.

So far I try to correct a false statement in the (as of writing this) top comment [1] or add a more neutral view [2]. And maybe I will add more of my personal opinion in the future - or participate in other interesting topics depending on my mood.

[1]: https://news.ycombinator.com/item?id=39555542 [2]: https://news.ycombinator.com/item?id=39556395

ReasonML crippled themselves, too, by splitting the already tiny community between Reason and ReScript

Here's a good (neutral!) write-up: https://ersin-akinci.medium.com/confused-about-rescript-resc...

> I would recommend steering clear of [Go] for years, due to their decision to allow their own `map` type be a generic[2] type but no user-defined types could be[3]

I think this is very, very different. First because Go didn’t have a cultish purist aversion to generics, banning people, going after them even outside of community spaces. But on a technical side, maps (and slices and channels) were not gated to be used by std, they were publically available to anyone. Not having generalized a feature is not the same as banning it. There was not even Go syntax to express it. Same as arrays in C, no?

That said, I’m not challenging the recommendation to stay away or not - generics was (and still is, may I add!) quite a pain point with the language. I’m personally quite invested for other reasons (concurrency, networking, std lib), but people come to different conclusions naturally.

If you’re a front-end developer, you should checkout ReScript[1], supposedly a JS-oriented successor of ReasonML and developed by the ReasonML team.

[1] https://rescript-lang.org/

If you want to try TEA, but not Elm I reccomend Scala.js with Tyrian[1]. Scala.js is a wonderful, mature project and Tyrian gives you the elm architecture in a very pragmatic way.

[1]: https://tyrian.indigoengine.io/

Are you actually using this in a non-trivial application?

The recurring complain I hear about scala are the bad compile times. I haven't used the language much, so not sure if this only applies to libraries that heavily use compile time metaprogramming.

But I really love that with modern tooling we can get a sub-second editor->browser feedback loop even for a three year old medium-large project on modern hardware. This was primarily one of the reasons I avoided Kotlin+Gradle JS target because among other issues the feedback loop was 2-3x slower.

I have a medium sized project with it and the initial compile can be slow, however every recompile usually has the page updated as I switch from my editor to it. Not as fast as TS, but worth it for the much better programming language. Tyrian also makes it trivial to set up hot-reload with preserved state.

Ok, this is interesting. I'll try this out in a small project.

I have to agree that this is FUD. So, it’s impossible to use the language in production because FFI is async (ports)? lol, come on guys.

“making it impossible to actually use the language in production”

Absolutely false.

Please refer to my comment here: https://news.ycombinator.com/item?id=39551017

If time is important to you, please correct your statement.

> The year in this link is very important. In the following year, the Elm team decided to [...]

The blog post was released a year after the official release of Elm 0.19 where the access to native code was further restricted in the official compiler.

It was not something that happened without ample prior notice, see for instance a post [1] by the Elm language creator in March 2018 in which he explains his reasoning for the upcoming change. Or another in March 2017 where he announced that intended change [2]. Even in 2015 he actively discouraged people to rely on these undocumented features and other hacks [3].

I also was not happy with that choice and felt the pain of something being taken away that was possible before, but that didn't stop me from using Elm at work nor from using it for fun.

So far I haven't found an alternative that I liked better, so I will stick to it.

[1]: https://discourse.elm-lang.org/t/native-code-in-0-19/826 [2]: https://groups.google.com/g/elm-dev/c/bAHD_8PbgKE/m/X-z67wTd... [3]: https://groups.google.com/g/elm-dev/c/1JW6wknkDIo/m/H9ZnS71B...

Sorry, but what is FFI???

Foreign function interface

I’ve been working with Go for 10 years and I have no idea what you mean by maps being generic before generics came along, nor did maps ever cause me to have over-verbose code bases. The links didn’t seem to help.

Trying to summarise what they were likely saying: Not having generics makes code verbose because you end up copying and pasting your library code to make it handle different types. The complaint about maps being generic was that the Go team clearly saw a need for generics (as they implemented them for maps and some other types) but decided that others wouldn't need them. So they had one rule for them and another rule for everyone else, which people don't like.

How were maps generic before generics, I am not sure I understand. Didn’t you still have to declare them as map[type1]type2?

So when something is generic, it means it is a type parameterized by other types. So the type map[string]int is indeed generic, but no language users could create their own type btree[X]Y, for example.

Essentially, the go developers saw a need for generics and then decided that only they get to create them, where most modern language developers either make them available for everyone to implement or don't add them at all.

I tried Elm in ~2018 and it was delightful. Ended up checking it out bc it was mentioned as 'prior art' in Redux's website. Didn't end up adopting bc everyone around me thought I was crazy to use something so niche.

It's the kind of thing that even if you don't end up using, you come out with lessons that make you a better programmer. Some that I remember:

- The compiler was fast, it made me aware that you could have an iterative workflow like most dynamic languages but driven by types

- The language/framework constructs (views, updates, etc) made it clear what kind of functionality had to live where so it makes me aware to define roles/arch in React apps that are 'just components'

- Error messages are just awesome, it was the clearest I had seen at that point and made me realize other languages just haven't paid enough attention to make them more usable

Agree on all points. It's delightful to compile your app and... it just works. No nulls.

I still use it for personal projects where 8 can but Elm is showing its age. Newer JavaScript APIs are not well supported and ports, while I understand why they exist, can be painful to use.

But I'd still recommend it. Way more fun than any other fronted framework library I've used and the functional nature was a fun challenge for me.

I still use Elm for personal projects as well. It’s nice to come back to an old project and become immediately productive not just because of the type system but because all Elm apps work the same.

Coming back to an old React app is usually a pain because everything changes between projects, even the state management architecture.

Exactly the same delightful experience here. Sadly it’s only become an even harder sell since then.

Every single place I've worked that adopted it has like one or two elm repos left where no one has had the time to rewrite it into ts yet, and there's maybe one developer who still understands it.

I've not seen anyone picking it for new dev in... a really long time.

Shame, really.

I use it at work. I tried to write Vue once and just hated it with a passion, so rewrote that part in Elm and was much happier.

> It's the kind of thing that even if you don't end up using, you come out with lessons that make you a better programmer.

Sort of a modern front-end developer's version of reading SICP even if you're not going to end up coding in Lisp, but because it makes you a better programmer, as you say. Interesting take!

For anyone new to Elm, remember that as of version 0.19, unless your project is one of the Elm core team's pet projects, you'll have a severely restricted feature set available. See https://news.ycombinator.com/item?id=22821447, https://news.ycombinator.com/item?id=17842400, and https://news.ycombinator.com/item?id=16510267 for details.

Jeez, at some point you folks who don’t like Elm’s decisions have to leave the theater so the rest of us can enjoy the show.

If you think a cult of personality is bad, you aren’t appreciating how much worse is, to the rest of us, the cult of anti-cheerleaders on every post that mentions Elm.

For years now any time someone wants to read about Elm, they have to hear from the same few HNers who don’t even use it yet refuse to let it go.

It’s like every time Dune plays in the movie theater, the same crowd comes in to explain how shit it is, how different it is from the book, in fact check out this ancient blog post about how bad it is, and there’s no way yall in the audience will enjoy it so don’t even try! The director sucks too, just look what he did! He fkin did that! It’s actually impossible to enjoy the movie once you know all the facts. And the guy who made the movie didn’t listen to my meticulous feedback and it hurt me cuz boy do I have opinions about how a Dune movie should be made, believe you me.

Meanwhile we just want to watch the dang movie.

I'm quite curious what Elm triggers so in people, that they years later actively hunts down discussions about it to interject their negativity.

I think maybe you ought to think about inverting your stance on this, because it's not necessarily virtuous to imagine that everyone repeating the same warning, over and over again, is due to some mysterious, inexplicable negativity. And it's not great to imagine that they don't know what they're talking about, or that they're just trying to scare people off with senseless FUD. Or that they didn't actually run into the problems they say they did. Or that they don't know the root cause.

Maybe a better question to be curious about is this: What can Elm do about the (self-evident in these comments, IMO) fact that a bunch of devs who really like it, feel like it's a bad choice? And, what SHOULD Elm do about that?

If a bunch of people think it's a tool foreboding enough to warn others off of it, and in the same thread some of those same people are saying they really liked that tool and wish they didn't have to do that, what benefit are you really getting from just dismissing their feedback?

Outspoken feedback is rare, just calling it negativity and paying it no mind rhymes a lot with the way Elm, writ large, has behaved. It's not indicative of a tool or ecosystem that wants to foster growth or continue development. That's part of the problem.

I disagree. I don't care what elm maintainers should or shouldn't do. It's not my problem, so that's not a question I want to ask.

I'm curious about why the same few, a vocal minority, spams every thread about elm with the same blog post. If you think we're dismissive, it's more because we don't want the discussion to be derailed for the umpteenth time.

People who make commercial decisions based on the support and development a language receives do indeed care. If you are making decisions with commercial or practical relevance you should care and not caring is negligence if you decide to use the product. Many people got burnt by the abandonment of Elm development (and yes, it has essentially been abandoned despite what the Elm community will say).

I think it's a bit disingenuous to pretend the goal of many of these critics is to improve Elm. They are clearly through with the language--as shown in their comments--and that is fine. But they're acting like they got dumped five years ago and still aren't over it.

Why would they not be over it, then? It's clearly made an impression.

They damaged the illusion of the "B" in "BDFL" with their changes in 19. Open-Source programmers like to believe that their toolchains and whatnot are egalitarian, and treat everyone as equals. Many accept the idea that the STDlib will be "more special," because its included in every copy of the language. This pill is made easy to swallow by the idea that your code, for your tool or library or whatever else, can be just as powerful as a built-in bit of code.

Elm's maintaners decided to break this. They created what amounts to a caste system for code. If your code was blessed, then it got all sorts of extra abilities not granted to un-blessed code. And the sole authority on blessing was the cadre of developers.

Now, as to why they did this is a different discussion. There are good and bad arguments on both side. But as to why it comes up all the time? Ego

That might be, but doesn't answer the question. There's plenty of tech I don't enjoy, still I don't interject myself into every discussion about those to bring it up.

It's like this meme. https://imgur.com/a/mjsMOGJ why do so many want to be the person to the left when it comes to elm? And so many years later?

This and the responses that are piling on with the same sentiment are offbase.

I am not seeking out opportunities to badmouth Elm. But as I am someone who is interested in FP and frontend tech in general, when I see an Elm story on the frontpage I click on it to see what folks are saying. And when I see exclusively glowing and positive statements (which was the case when I first posted) then I feel like I have an obligation to point out that there are some big issues with how Elm is maintained, because this is the sort of thing that _I_ would want to know before I spent a bunch of time digging into it.

If you want to watch the dang movie go ahead. But anyone asserting that those of us posting negative things about Elm are acting cult-like (seriously?) is being disingenuous. Considering the audience, there are good reasons to highlight the--IMHO major--problems with how the Elm project is run, and not mentioning them is irresponsible.

For anyone new to Elm, please know that you have a stable language with no major changes since 2018 and no official release since end of 2019, see https://iselmdead.info and decide if that is a bad or a good thing for you.

And if you are thinking of starting now, you should not focus on what undocumented feature (or hack) was taken away in 2018 that allowed injecting arbitrary JavaScript code that easily broke all guarantees of the language https://discourse.elm-lang.org/t/native-code-in-0-19/826 but rather if Elm fits your current (and maybe future) needs. If it does not, keep looking for alternatives.

The "no updates for past five years" is my favourite feature of Elm.

I have some five or so projects written in Elm and enjoy every time I don't have to upgrade them because no new version was released!

That's high on my list, too.

The only fear I have is that I won't be able to install packages that no longer exist when I switching machines.

But by running

  ELM_HOME="$PWD/deps" elm make ...

I can get those downloaded into the directories and add them to the VCS.

And for those who are interested, Evan (creator of Elm) gave a great Strange Loop '23 talk that hints at where he imagines things going, if he could figure out how to get the economics to work.

https://www.youtube.com/watch?v=XZ3w_jec1v8

I use Elm and am quite happy with it, despite the project being dead (and Evans horrible cult of personality).

I am also keeping on eye on Gren as a replacement: https://gren-lang.org/

Gren took the worst thing about Elm and made it even worse: https://news.ycombinator.com/item?id=36275171

Oof, why do this? What is the reasoning?

https://news.ycombinator.com/item?id=36278320

Gren is very open to contributions. This can radically change how this enforcement impacts users in practice. It's too early to say really.

I wouldn't bother with Elm. Among other things: https://www.reddit.com/r/programming/comments/fxvlow/why_im_...

PureScript (https://www.purescript.org) on the other hand is very nice.

PureScript made some ergonomically painful decisions (I value the logic behind their implementation of tuples but not having to use them in such a way), but I think the biggest point against it is how Haskell is moving into that space via JS and WASM compiler targets and bringing along its broader user base and library support

Yeah the way tuples work in PS is kinda painful, but there are some affordances for tuple-like pattern matching that smooth over some of that pain.

On the other hand, I feel like PureScript's records that utilize row polymorphism are such a game changer that it's hard for me not to get frustrated with Haskell records when I go back. And while I love where Haskell is going with WASM and JS support, I think it'll be a little while before that is viable for real-world projects.

> Haskell is moving into that space via JS and WASM compiler targets and bringing along its broader user base and library support

This has been an initiative for longer than PureScript has existed. I wouldn't expect it to replace PureScript any time soon to be honest.

I'm interested in applying Elm principles but in a standard React and Typescript app. Anyone have experience doing this?

It looks like redux has some inspiration from Elm, but I think the way effects are handled in Redux isn't as predictable as Elm.

elm is a lovely lang. it would be nice to have modern APIs on it.

here's the project for new eyes:

https://github.com/elm/core

https://elm-lang.org/

The website tells the full story:

What story does that tell?

React's would say 2022 - https://github.com/facebook/react/releases

There's engineering effort happening behind the scenes on both projects, the releases have slowed, and big changes are coming to both Elm and React.

Elm seems pretty much dead to me, tbh, which has prevented me from even trying it for the last few years and I know I'm not the only one.

There was a major loss of confidence and enthusiasm due to things like this. Very much not a project to build a business on

https://dev.to/kspeakman/elm-019-broke-us--khn

Honestly it's better now that it's dead. The 0.18->0.19 transition was a big disaster. Imagine if we got one of those ever year for the last five years! I think that's what would have happened if Evan had continued to be able to produce new versions.

Dead means it's super stable. Stable is good.

I believe the important part is not the date so much as the copyright.

Basically, if you build on Elm, you're living inside Evan's personal project.

There are upsides (Evan did a great job designing the language) and downsides (Evan's goal isn't being a maintainer, and he locked the ecosystem in such a way that many things can't be done without him).

He stopped caring in 2021

And right above that line is the compiler source which Evan said people should feel free to fork and publish as long as they don’t name it something confusing and divisive like Elm+

Haven't heard from this language since 2016 where a coworker tried this out but then gave up on it.

Reply on news.ycombinator.com