Elm argument

I know that usually introducing a new language is overkill. This is because the cost of learning a new language isn't worth the benefits you gain. Usually they are more trade offs than benefits anyway.

Elm is different because it has huge benefits with a small learning curve. And the trade-offs are in the right places.

Elms benefits

The main three benefits that elm provides over JavaScript is:

1. no runtime exceptions
2. enforced SemVer
3. everything being purely functional.

Essentially this means that all of JavaScripts runtime exceptions become compile time errors in Elm. for instance all of the following things can not happen:

• dealing with unhandled Null/undefined/NaN is not a function
• A library changed their API and only bumped a minor version.
• unhandled exceptions being thrown (there are none)
• adding a string to a number or other unexpected polymorphism
• accessing a key in a object that is not there
• refactoring and not finding where all the places you need to change
• etc...

Think about what this means for us. Less time hunting down bugs means more time making features. Static Typing also means less tests, with higher reliability.

Tests are also easier to write because all functions are pure in Elm.

Also refactoring is far less error prone because the compiler can find all runtime exceptions. Confident refactoring means it's easier to pay off technical debt

Elm is easier to learn than JavaScript

Elm is a very small and focused language designed over 5 years to make front end programming easier. It's easier to learn because there's far less to learn. Plus it has tons of overlap with JavaScript and Elixir.

To replace Elm you would have to have the following libraries in JavaScript and use them everywhere:

• React + write all your prop types
• Redux
• immutable.js
• Babel (plus a ton of extensions)
• Lodash
• Flow Es lint to pick up the slack
• A testing framework like jest or something
• redux debugger
• perfect code reviewers that find all your runtime exceptions?

Using all these libraries in JavaScript is best practice in our company yet it's so hard to get all this setup it usually takes a few days, even with the boiler plate. All this is the default in Elm and feels just add light as a vanilla JavaScript project.

Elm is also easier to learn because it's similar to Elixir due to being functional, having pattern matching, and even having our favorite |> operator.

While we write mostly functional JavaScript at it's core it's still a prototypal OO language with many inparitive parts.

The costs of Elm

Elm does have some costs. The main one would be there's some boiler plate code to interop with JavaScript. This is because Elm requires everything to be immutable and has no null so you have to transform JSON into Elm data structures. However there's tools to automatically transform JSON into Elm decoders. However this is also a benefit because it removes the danger of working with JSON structures that all too often cause runtime exceptions. Elm makes you handle these before you break production, not after.

It also requires you to talk to JavaScript over "ports" which are basically a pub sub style channel. This is because if JavaScript threw any exceptions Elm would lose its policy about no runtime exceptions. While this can seem inconvenient you're trading that for no runtime exceptions which is going to be worth it in the long run.

Give it a try

Talk is cheap, a real experiment is the only way to really tell if Elm is right for us.

---

Backlinks:

• Elm