The pain point that leaps immediately into my mind is build tools. I'm not gonna sugarcoat it: Webpack has been slow and crashy and I can't wait for us to stop using it.
However, I'm assuming you meant "pain point specifically with Elm the language." For me it's definitely that union types are not comparable yet. I really want to be able to use them as keys in a Dict for things like form validation. Unfortunately this is a ways off because the implementation requires modifying how Elm generates JS code to include a bit more information at runtime.
My #2 pain point is how much of the Web platform still requires interop to access. For example, if I could use an Elm library with a nice API that let me work with IndexedDB, I'd probably be up until 2am upgrading Dreamwriter.
Oh, and there's that value doesn't Just Work the way it does in React. This is kind of inside baseball, but it can Just Work in React because setState updates synchronously, whereas Elm does requestAnimationFrame batching to improve performance. The alternative of defaultValue works fine for most use cases, but when it doesn't it's a big pain. I can conceive of a way to make value Just Work, but it would be a pretty invasive change for elm-lang/virtual-dom.
Hm, interested in hearing more about the issue with value and how it's affected with requestAnimationFrame batching. Is that to say if a text field isn't "bound" to the model with key presses, relying on the DOM to keep state, there will be inconsistencies?
If there are multiple entry points (i.e lots of bundles) then Elm is not very good at parallelizing shared asset control.
Elm-make is slow, and if the dependency tree triggers an expensive change, then it's important to realise that Elm causes a slow re-compile - but webpack is responsible for filling up memory, and therefore slowing everything down
Webpack can segfault (and does if you aren't careful)
github.com/elm-community/elm-webpa... switches the way that node-elm-compiler was looking for dependencies, and helped fix a pretty bad problem of opening too many things.
The pain point that leaps immediately into my mind is build tools. I'm not gonna sugarcoat it: Webpack has been slow and crashy and I can't wait for us to stop using it.
However, I'm assuming you meant "pain point specifically with Elm the language." For me it's definitely that union types are not
comparableyet. I really want to be able to use them as keys in aDictfor things like form validation. Unfortunately this is a ways off because the implementation requires modifying how Elm generates JS code to include a bit more information at runtime.My #2 pain point is how much of the Web platform still requires interop to access. For example, if I could use an Elm library with a nice API that let me work with IndexedDB, I'd probably be up until 2am upgrading Dreamwriter.
Oh, and there's that
valuedoesn't Just Work the way it does in React. This is kind of inside baseball, but it can Just Work in React becausesetStateupdates synchronously, whereas Elm doesrequestAnimationFramebatching to improve performance. The alternative ofdefaultValueworks fine for most use cases, but when it doesn't it's a big pain. I can conceive of a way to makevalueJust Work, but it would be a pretty invasive change forelm-lang/virtual-dom.Hm, interested in hearing more about the issue with
valueand how it's affected withrequestAnimationFramebatching. Is that to say if a text field isn't "bound" to the model with key presses, relying on the DOM to keep state, there will be inconsistencies?Right - if you use
defaultValueto let the DOM's version of reality "take precedence" and useonInputto listen for changes, it's all good.Unless you actually need to manually override that value! Then it's a pain. 🙂
To expand on the Webpack issues:
I worked on this a bit to help fix it: