Hacker News new | ask | show | jobs
by lambdas 26 days ago
Did the restrictions on JavaScript get resolved? IIRC, they made it so you had to use their “Ports” mechanism to interface with JavaScript, and you couldn’t write your own wrappers.

There was some drama when someone forked it so you could write your own JavaScript wrappers/FFI too?
1 comments
miniBill 26 days ago
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
link
crote 26 days ago
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.

link
1-more 26 days ago
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.
link
lolc 25 days ago
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?
link
1-more 25 days ago
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...
link
lolc 25 days ago
Great hack, thanks! And yea I was missing some native string api when I abandoned Elm at 0.19.
link