3 ms·
For anyone new trying to get into Elm (as a language/tool), I would look elsewhere. ReasonML, PureScript, TypeScipt, etc are all better featured solutions. Havi
by thepratt 7y ago
For anyone new trying to get into Elm (as a language/tool), I would look elsewhere. ReasonML, PureScript, TypeScipt, etc are all better featured solutions. Having said that, the article is well written and thorough for anyone wanting to take a look into Elm.
But there are massive problems with Elm itself which make it impossible to consider seriously. I have and still do use Elm in production, and went through the nightmare upgrade from 0.18 to 0.19.
1. Elm ports are not sound. Elm will tell you everything is good but doesn't do simple checks - as say PureScript does - to see if your port code actually exists or adheres to the defined contract. There are other tree-shaking issues, but Elm does not know and does not care about the js you've written.
2. Evan holds the naive view that everything can be rewritten in pure Elm and there's no reason not to. An overwhelmingly common use-case is 3rd party services or tracking libraries where it's impossible to re-implement; these apparently don't exist.
3. Elm applications, without a Redux-style (domain-specific to Translator) pattern, end up being horrendous spaghetti code of everything knowing about everything. Cmds and Tasks are a pain to work with when they should be interoperable in some manner.
For small embeddable or personal projects Elm is a fun tool. I don't see it being more than that until more community involvement is permitted - removing the dictatorship.
- fortran77 7y agoElm has solved big problems with us, and for everything that can run in the "pure Elm" side of things, we have very few problems.
- nilkn 7y agoFor what it's worth, PureScript is much more complex than Elm. I see people recommend it, but I don't see people actually use it nearly as much as Elm (not that Elm is super widely used, of course). I do agree that the biggest thing Elm needs is to open up development, break down the "dictatorship" as you put it, and accelerate the pace rapidly.
- wtetzner 7y agoI think OCaml/ReasonML seems like the nicest choice, even if you're using the Elm architecture. Functors make it really easy to combine components, which actually makes it nicer than Elm for the same tasks.
- hombre_fatal 7y ago> Evan holds the naive view that everything can be rewritten in pure Elm and there's no reason not to. An overwhelmingly common use-case is 3rd party services or tracking libraries where it's impossible to re-implement; these apparently don't exist. He quite loudly holds the opposite view: instead of thinking you need to port everything to Elm (very common urge for newcomers), keep it in JS and use it over a port.
- thepratt 7y agoAll the wording in https://discourse.elm-lang.org/t/native-code-in-0-19/826 https://discourse.elm-lang.org/t/native-code-in-0-19/826 seems to indicate the opposite. I'm not saying jQuery bindings are a good idea, but saying no to _everything_ b/c you don't want jQuery bindings is.
- KurtMueller 7y agoRegarding #3, would you mind pointing out some good resources/examples that illustrate this pattern?
- thepratt 7y agohttps://medium.com/@alex.lew/the-translator-pattern-a-model-for-child-to-parent-communication-in-elm-f4bfaa1d3f98 https://medium.com/@alex.lew/the-translator-pattern-a-model-... describes the pattern quite well in elm-first terms.