My thoughts on Elm Lang

A little context. I don’t like JavaScript. I never have. I probably never will. But it’s a tool that continues to be very important. From web development to node.js applications, I’ve written A LOT of JavaScript over the years. Arguably, the node.js applications I wrote influenced my software development interests and skills as much as anything I’ve ever worked with. And I believe node.js (and the requisite JavaScript revolution) changed the software development industry for the better in a lot of ways (e.g. async programming).

I had a nice break from JavaScript for about 18 months but have recently found my way back.

And, again, I find myself desperate to find a replacement for JavaScript.

I should also note that I tried CoffeeScript four or five years ago and it made me swear off transpiled languages forever.

However, forever didn’t last as long as I thought it would. I’ve been prototyping a few things over the past few weeks that required JavaScript and I’m frustrated and looking for a replacement. I was considering three transpiled languages; Elm, TypeScript, and Scala.js.

Elm was the language I was most interested in. It is a strongly typed, functional programming language with an error handling model I appreciate and a relatively novel approach to interop.

This week I read all of the docs, did some tutorials, and partially prototyped a solution to a feature I need to build for a project.

And my Elm use is complete. I will not be using it going forward.

There’s a lot to like about Elm in practice.

• It’s a decent functional language with a very, very small vocabulary.
• The syntax goes a long way to reduce clutter.
• The error handling is very modern and reminds me of other languages like Scala and Rust (all of which inherit from the same places).
• Data binding is intuitive once you understand other parts of the language.
• The tools are pretty good given how young they are.

There are some bad parts of Elm as it exist right now, however.

• What documentation exists is very incomplete, spread across the Internet, and there isn’t enough of it. After reading the docs, doing some tutorials, and reading some example applications, when I tried to write my own Elm code I felt like I was missing a lot of what I needed to know. Two examples: Figuring out how to work with the DOM in an existing application is downright painful. The let/in idiom, for people that don’t come from a language that has it (I didn’t), is really bizarre and badly needs more explanation and examples.
• Interop between JavaScript and Elm is really convoluted and unnatural. I really, really didn’t like the Interop story. I want to be able to download a JavaScript library and use it from within Elm. Instead there’s the port concept which is novel (although it smells a little like JNI) but the most unintuitive part of Elm I used. I understand the tradeoff but the current solution really chafed.
• The language itself isn’t bad but feels like it isn’t done. This conclusion could be the result of the lack of docs.
• This isn’t specific to Elm but…

I don’t care what people say, virtual DOM is a step backwards. Mixing HTML with your primary language today, is just as bad as it was during the ASP days. I got out of that business a long time ago and I’m not going back.

The problem with the virtual DOM as it pertains to Elm is that I couldn’t do much without it if I wanted dynamic updates.

Ultimately, what dooms Elm for me, is the same problem I have with a lot of JavaScript frameworks and my very limited exposure to other transpiled JavaScript alternatives. The value proposition stinks. There’s not enough good to outweigh the friction.

I would not use Elm in my free time. It’s not for me. Which also means that I’m probably not going to consider it for my day job.

On to TypeScript