# 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:** 4

<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 17, 2018, 9:25pm UTC](https://discourse.elm-lang.org/t/two-experiences-with-elm/919/4 "2018-03-17T21:25:24Z")

</div>

> [@spookylukey](#):
>
> The Elm leadership need to understand that if they go around promoting Elm, talking about it as if it is a **production ready language** and getting people excited, and then intentionally make the compiler refuse to compile users’ code simply because **they disagree with what features people are choosing to use** , and simply dismiss these users as “not many people”, they cannot expect to retain good will from the community, and don’t deserve to either.

(Emphasis mine.)

Evan was open about the fact that [the 0.19 design is the design he intended from the beginning, back in 2011](https://discourse.elm-lang.org/t/native-code-in-0-19/826/2). Is it fair to call unintended, undesirable behavior (aka a bug) a “feature people are choosing to use?” To me, fixing a bug before even more people come to rely on its unintended behavior seems like the most responsible thing to do.

Is Elm a production ready language? This is objectively true. There are too many examples of [Elm in production success stories](https://www.google.com/search?q=elm+in+production) for it to be false.

As for the notion that Native is _necessary_, as opposed to expedient, so far that hasn’t held up under scrutiny. You can see threads on this forum (and others) where people described their use cases, and others came up with solutions that didn’t use Native. I’ve seen this happen at work, where we’ve used Native in the past out of expedience, and have since found that we can do everything we were previously doing with Native using a mix of ports, custom elements, and polyfills. Turned out we didn’t need it either.

As Evan noted on the other post:

> [@"Native Code" in 0.19](https://discourse.elm-lang.org/t/native-code-in-0-19/826/1):
>
> For folks who are really anxious about this, I really encourage you to talk to folks about it in a friendly way. I have not yet heard a case with no answer, and we have lots of time to work through things in a good way.

I don’t know all the details of your scenario, but if you want to run a performance-critical JS algorithm in response to user actions, one way you could do that is by writing some JS to attach a custom event handler to a DOM node managed by Elm, which runs the calculation and then [fires a custom event](https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Creating_and_triggering_events) containing the result of the calculation. Elm can listen for _that_ event instead of the original event, and decode the result as normal. Should work, yeah?

(That said, solutions are probably better discussed on a different thread, assuming you would like to discuss them. I think if you make a separate post outlining your particular scenario, you might be pleasantly surprised what solutions people come up with!)

---

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