# Two experiences with Elm

**URL:** <https://discourse.elm-lang.org/t/two-experiences-with-elm/919>\
**Category:** Show and Tell\
**Created:** [March 17, 2018, 3:55am UTC](https://discourse.elm-lang.org/t/two-experiences-with-elm/919 "2018-03-17T03:55:36Z")\
**Posts on this page:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![rtfeldman](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/rtfeldman/32/50_2.png) [@rtfeldman](https://discourse.elm-lang.org/u/rtfeldman)\
**Post date:** [March 19, 2018, 9:30pm UTC](https://discourse.elm-lang.org/t/two-experiences-with-elm/919/10 "2018-03-19T21:30:58Z")

</div>

> [@spookylukey](#):
>
> The question is, would my code be better and more robust for that kind of change?

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](https://discourse.elm-lang.org/t/native-code-in-0-19/826) is this:

> [@"Native Code" in 0.19](https://discourse.elm-lang.org/t/native-code-in-0-19/826/1):
>
> The fact that generated code is not pinned to some specific format means that I can change it dramatically without the community paying a big upgrade cost. In fact, I have done that a few times already! This has allowed me to (1) make Elm code a bunch faster overall and (2) shrink the size compiled output quite significantly.

The “custom event” approach relies only on public browser APIs, whose extreme emphasis on backwards compatibility has sometimes had [hilarious consequences](https://developers.google.com/web/updates/2018/03/smooshgate?utm_source=feed&utm_medium=feed&utm_campaign=updates_feed). 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](https://blog.codinghorror.com/falling-into-the-pit-of-success/) where it becomes clearer that the more robust solution is to rely on stable browser APIs instead!

---

_[View the full topic](https://discourse.elm-lang.org/t/two-experiences-with-elm/919)._