(Emphasis mine.)
Evan was open about the fact that the 0.19 design is the design he intended from the beginning, back in 2011. 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 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:
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 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!)