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

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.