Elm V.S. JavaScript, a honest look

Edit: looking back this is written when I was trying to rewrite stormcrow in Elm. This is basically the first sizable project in Elm. As such, I think I gravitated far more towards new and fun abstractions. This I think accounts for most of my distraction. It happens with any new programing language or thing. Elm is actually all about fast feedback. It does force you to think about edge cases early but these are just educational experiences. They round out design. Do they slow down development? Probably. However they don't stop you from handling things badly. You can do that if you wish, you just tend to handle stuff better than when it's obvious and in your face. It forces you to put less faith in the idea that there will be no bugs. Gives you more empathy for that 1% that did happen to get the system in a bad state. Not only that, in Elm it gives you the power to actually change things confidently. Renaming? easy! pulling things out into a file, trivial. Changing how you store state to a more convenient data store? Completely protected. Logic errors are mostly all that's left. That's so much less to worry about! The power to change, confidently.

This was a more stark contrast when I started to refactor the JS. it was horribly painful! Very error prone, had to constantly try it out and go back and forth between the browser and my editor. I still don't know if it works under all situations.


Elm trades convince for stability. It forces you to handle every edge-case. This is great for the fact that the product will never break in certain ways, however there is a tradeoff. That is of making things take a little longer to make. Elm is less interactive and less GTD oriented. I find often I lean towards playing with the type system for hours rather than just hacking something together. Many times the simplest, even simplistic solution is the best because it avoids a huge amount of distraction that comes by over abstracting.

The main time that JavaScript becomes scary is when you refactor. In dynamic languages we don't rename things. Renaming something would be dreadful to the system. It's like impossible to find everything and very nerve racking!

However that matters little to the business. They need features and care little for the edge-cases. They don't want things to totally suck but they mostly need things to work in the happy path.

Nobody is going to care that much if they mess with a data picker for too long they can get it into a bad state, but they will care that they have a date picker. JS can give the latter a lot faster.

It's like the craigslist model. It's not optimal but it's good enough, and it's popular and effective. It's not crazy smooth but if anything goes wrong it's on either party to handle that.

The thing I love about JS is that it lets you fail fast with little resistance to get to a solution. Being a dynamic language it lets you play in runtime very often. You can see it working or not working. You're using the interface that the user is using more often than not. You're doing integration testing all the time.