Two experiences with Elm

Absolutely, but I can see why it wouldn’t appear that way at first!

To build on what Robin said, the key point from Evan’s post is this:

The “custom event” approach relies only on public browser APIs, whose extreme emphasis on backwards compatibility has sometimes had hilarious consequences. However unfamiliar that appraoch might feel the first time you try it, if it works today you can expect it to work tomorrow.

In contrast, the Native approach relies on a secret API that is designed to break in brutally unforgiving ways without notice at any time—including changing formats (0.17 → 0.18), output languages (Web Assembly), or even disappearing altogether (0.18 → 0.19).

Native has never been a robust way to do JS interop from Elm. Closing the door on it for good creates a pit of success where it becomes clearer that the more robust solution is to rely on stable browser APIs instead!

13 Likes