On Wednesday, 28 December 2016 14:18:13 UTC+7, Mark Hamburg wrote: > > My point was that the calls for Elm optimization could largely be > mitigated through a combination of fast enough for most purposes (arguably > already there) coupled with a reasonable escape hatch to the host > environment (as of now JavaScript and not really there) for the cases when > it isn't. I'm suggesting that rather than investing in fancy compiler > changes, some changes in the runtime architecture to allow performance > intensive central loops to be written in other ways would be cheaper, > simpler, and would arguably address some of the other issues that have > floated up recently. > > Elm has a weird ambivalence about native code. On the one hand, Evan has > pushed back pretty hard in the past out of fear of getting tied to crappy > JavaScript libraries and has pushed for doing everything in Elm. This is > reflected in the relatively small amount of native code based work in the > standard Elm package repository. On the other hand, when pushed on how one > is supposed to do something that is currently difficult in Elm — e.g., some > MDL conventions — others in the community have pushed for using native code > rather than trying to write it in Elm. > > My recommendation would be a middle path that says we believe most things > are better in Elm but here are its limitations and here is how you can > cleanly and easily reach outside of Elm when those limitations prove to be > a problem. While the currently documented mechanisms may be clean, they > aren't easy for many cases. Ports are extremely awkward for cases that > require both a request and a response to that request. Effects managers are > undocumented and discouraged. And native modules themselves are barely even > admitted to let alone documented as a thing. Improve that situation and any > concerns over both performance and interfacing to the broader world are > substantially mitigated and Elm can better focus on its core mission. Fail > to improve that situation and every effort to grow the market for Elm will > also grow the pressure for it to do everything well. >
Mark, you raise a good point: as an interim measure, make it easier to generally interface to JavaScript including easily adding subscriptions if necessary. But that will only happen if Evan and others see it that way, which they may not if they see it as "Elm is already good enough (for our use)". -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
