Hacker News Reader

Comment by miniBill | Hacker News Reader

FFI is still mostly done through ports (or web components, for the view part). This is an intentional choice and likely to stay until 1.0 and beyond

View on HN

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.

Haha, yeah I didn't realize there would be a monkey patch route to FFI in Elm. Can't control the runtime. Is there a good read up on this technique?

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...

Great hack, thanks! And yea I was missing some native string api when I abandoned Elm at 0.19.

Reply on news.ycombinator.com