[Hermitian909]

Kolme's comment is a very good reason, as someone who picked a non-standard frontend language I'll add my 2 cetns. I'm working on a project that went from javascript to reasonML when we felt the lack of a really strong type system was making managing the complexity of our app (which is unusually complicated) unmanageable.

When I was evaluating Elm it was my favorite choice out of all the various strongly typed flavors of javascript, clean syntax, good abstractions, and very strong runtime guarantees. The thing that made us reject it, and will keep me from recommending it to others, was the change made, I believe in version 0.15 which, as I understand it, restricted FFIs so that only core maintainers could write them. I know several companies have frozen their version of Elm due to the change.

Particularly when working with external packages written in JS, not having an escape hatch is a huge vulnerability. We've already hit one instance since using Reason where if we could not drop down into pure JS we would have had to either rewrite one of our main dependencies or at least hard-fork it and re-write substantial portions of the application, a multi-month (maybe multi-year) slowdown that would have killed the project.

At this point I would not recommend Elm to anyone who is not willing to rewrite any pure javascript module they might want to use (this may fit the bill at some very large corporations).

[carapace]

That may have changed?

https://guide.elm-lang.org/interop/

> But what happens when you need to do something in JavaScript? Maybe there is a JavaScript library you absolutely need? Maybe you want to embed Elm in an existing JavaScript application? Etc. This chapter will outline all the available options: flags, ports, and custom elements.

I haven't looked at it in depth yet.

[Latty]

Ports have always existed. The change was to stop people writing "effect modules" which were the unsafe version of this where you could run arbitrary JS.

The upside to this is that because ports work by message passing, it means that all the language's guarantees can be held even when using them, and packages can't do anything without you knowing about it.

The downside is it is a lot more verbose and awkward. In my opinion, it also makes community contribution to the standard library a lot harder.