To be clear I don’t use Elm in production so my thoughts are purely speculative. However, when you remove FFI to JS - in a language which is focussed around the web platform, which evolves pretty quickly - and you only have a handful of developers, it strikes me that just keeping up with the Web API bindings alone, is a lot to undertake. For example, if you want the new Web Transitions API, I guess you’ll have to hope you can call it through JS ports.

As others have noted, the Elm architecture has influenced many more pragmatic frameworks that have taken the key principles while still allowing work to get done.

I’ve used Elm a few times for hobby projects and while it’s super nice to model state and render most HTML and CSS (and is even enjoyable to write), you always feel that one day you’ll become too locked in and that Evan may decide to go live on a farm.

> What is lacking in the 2019 release and in what ways does the frozen feeling make things bad in reality?

Things I've personally missed include websockets, missing features in the browser interface like preventDefault in the Keyboard API, etc. It's not a big deal, but if you need lots of less covered APIs and have to develop ports for many little things, it becomes an annoyance.

In professional contexts, I haven't had trouble with Elm, but others have reported missing the kind of features people usually require, like server-side rendering, the ability to deploy a private package repository that doesn't feel like a hack, etc.

0.19 was a great version, but it is very barebones, and some new developments that have happened in other ecosystems just didn't happen because of the way contribution works in Elm.

If you only need what's already there, Elm is glorious. If you don't, you know it. Evan can't really be blamed for it, as he's always been very clear about that, but at the same time, it's kind of a pity to see such a great work that can't really be extended.

> If you only need what's already there, Elm is glorious

But how can you reliably know that'll be true in the future? Elm scared me away because I thought I'd be going along perfectly fine and suddenly get a straightforward new requirement that is strictly impossible.

(For those who haven't looked into Elm the issue is that to call javascript functions synchronously you have to be whitelisted by the compiler. One of the explicit reasons for this is that the language designer thinks it's bad when there are multiple competing libraries solving the same problem).

For instance, the projects I worked on were professional software. People don't care so much about SSR and first page rendering speed. We also didn't need the latest shiny browser APIs, or to tweak CSS to perfection, and we reasonably could say that this wasn't going to be the case in the future.

In that context where many devs were backend devs or self-taught, so using JS wasn't that important, since we were going to train anyway. Actually, training to Elm felt much saner than training to JS.

However, the tech remained niche for all the reasons I quoted in my first message.

Websockets is like two ports? Maybe three with the connection event.

I think this was a very charitable summary of both sides. Thank you.

I’m curious about this too.

There are no obvious landmines in the Elm compiler.

I adore using technology that feels “finished”.

I personally view its infrequent updates as its best feature.

I agree this should be acknowledged.

In this particular case, the workaround is luckily simple:

  case String.fromInt n of
    Just "-1" -> True
    _         -> False

I'm generally fine with language quirks like this, but I understand why others wouldn't be.

A number is not a string, you should not have to convert to strings like this. Evan's response on that issue is very typical - ask a question, get a negative reaction, completely ignore it and years later zero indication of a fix or change.