DEV Community

Discussion on: I am the author of Elm in Action. Ask Me Anything!

matthewoden profile image
Matthew Potter

What is your biggest pain point when writing Elm?

rtfeldman profile image
Richard Feldman Ask Me Anything

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.

pruett profile image
Kevin Pruett

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?

Thread Thread
rtfeldman profile image
Richard Feldman Ask Me Anything

Right - if you use defaultValue to let the DOM's version of reality "take precedence" and use onInput to listen for changes, it's all good.

Unless you actually need to manually override that value! Then it's a pain. 🙂

eeue56 profile image

To expand on the Webpack issues:

  • Webpack is very memory intensive
  • 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)

I worked on this a bit to help fix it: