And combined with its inability to provide mature native APIs and its hostility towards libraries containing ports, this essentially kills the language.
Elm's current story for interacting with the wider web ecosystem is "reinvent the wheel a dozen times by DIYing your own wrappers around literally everything". Fine for a trivial toy project, not fine for building production software.
I understand why they made those decisions, and each choice on its own is logical, but that doesn't make the combined outcome any better.
You can also do lunatic things like overload the `Object` prototype and get synchronous FFI by encoding then decoding an object. I do this at work to get locale-aware sorting. I know you know this, but it'll be news to others in the thread.
Slightly important point: it's still safe FFI! Everything that crosses the JS/Elm boundary has to be encoded/decoded from serialized JS Objects. So it's hacky BUT it's not actually unsafe, which is kind of funny. I have an example where I use it to effect locale-aware sort. This repo is a benchmark test of that: https://github.com/perkee/elm-js-sort-ffi-speed-test/tree/ma...
Elm's current story for interacting with the wider web ecosystem is "reinvent the wheel a dozen times by DIYing your own wrappers around literally everything". Fine for a trivial toy project, not fine for building production software.
I understand why they made those decisions, and each choice on its own is logical, but that doesn't make the combined outcome any better.