En kodare

Anders Hovmöller
GitHub
twitter
email
About Blog Apps

Elm first impressions from prod

2017-10-17

(If you’re coming from /r/elm to read this, please mail me directly. I was banned there so can’t reply)

Since writing my scathing initial article on Elm I’ve mollified my position and eventually I was part of the group who pushed to start using Elm for production. It’s not because I love Elm (which should be obvious if you read the article linked above), but because I think it’s the best option available right now. We’ve used it for a while now so here are some initial impressions. I’ll start with:

The bad

Major language issues

Lots of boilerplate

We solve this category of problems with a code generator (an old version is available on github, I’ll publish new versions periodically with updates from what we learn in production). Using code generators has upsides, but I think it also shows some serious lack of features in Elm.

Grab bad

The good

This is a short list, but every point in it is a huge deal.

Summary

So far I am optimistic. I feel a lot more confident about the Elm code than I’ve ever felt about ClojureScript code. Especially when writing front end code this is very important to us, because we spend most our time on the back end so we need a language where it’s possible to make changes without mistakes even when we haven’t used that language for weeks or even months. Having the compiler smack us on the fingers instead of having crashes in the customer browser is very nice. “If it compiles, it works” is pretty close to the truth.

If you want to use Elm at work, I strongly suggest to set up some kind of code generator from day one. It will save you time and prevent errors, especially when it comes to json decoders/encoders. It will also make it easier to make sure your front end code is in sync with your back end.

« Overanalyzing kids shows: Bing Vastly faster Python integration tests »