From JavaScript to Elm: A Blissful Journey

When building web applications with JavaScript, there are thousands of tools and frameworks to choose from. Most of these tools aim to make developing with JavaScript easier and more productive, and most of them help web developers achieve that. However, sometimes the language itself is the constraint. If you have built web applications in JavaScript, there's a good chance you've experienced errors like Uncaught TypeError: Cannot read property 'x' of undefined that end up taking lots of time to debug. The language does not help you catch these errors early enough in the development cycle, and they usually end up being discovered too late, mostly by your users reporting that something is not working.

What if you could release your web app with the confidence that you would never get any runtime exceptions again? What if every time you needed to refactor code, you could do it confidently knowing you have a compiler that would let you know of any errors and suggestions on how to fix them? What if you could get all these benefits today, right now?

Welcome to the world of Elm.

Elm is a language written specifically for building reliable web-based user interfaces and targeted towards the needs of modern frontend applications. It compiles to JavaScript, which makes it usable in web browsers, and is famous for its promise of No Runtime Exceptions. With Elm, you are guaranteed that once your app compiles, there won't be any crashes and you can devote your time to deal with the things that matter. Let's dive in and explore this language and what it has to offer.

Reliability

The best part of using a language with a compiler is you never have to deal with minute details such as typos and using undefined functions. You leave those to the compiler. Think of a compiler like a helpful assistant that helps you with the simple stuff and leaves the important logic details to you. One thing's for sure; you will make mistakes from time to time, and the compiler is here to make you aware when you make these mistakes and how to fix them.

Let's see how the compiler can be helpful with a real example. Let's assume we want to add up all the numbers in a list and while creating the list, we happen to make the slightest of mistakes by including one of the numbers as a string.

If we were doing this in JavaScript, this is how this might look:

const sum = function(numbers) {
  return numbers.reduce((acc, val) => acc + val, 0)
}

console.log(sum([0, 1, 2, "3"])) // Prints 33

Explore example in repl.it

This will print 33, not quite the result we expected 🤔

Now let's try to do the exact same computation in Elm and see what happens.

The code won't even run.

Elm expects all items in a list to be of the same type, and it notices that it is being asked to add numbers and strings, which is an ambiguous operation. The Elm compiler realizes our mistake and points out the exact list entry that is causing the mismatch and even adds some helpful hints and a link to the docs to explore things further.

This is exactly what I want in a language. I obviously made a silly mistake, which JavaScript ignores and gives me a result of 33 , which isn't really that helpful. I would prefer to know that I made a mistake and fix it rather than get a result that is obviously wrong.

This is what makes developing apps in Elm such a pleasant experience, since you always know the compiler has got your back. There are no surprises after you've released your app, and no more sleepless nights debugging why the sum of ​​1, 2 and 3 is ​33 😀

A Well-Defined Architecture

Elm has a standard way of organizing your application, and this pattern is called The Elm Architecture. You'll notice this pattern over and over again as you explore Elm apps. It enables you to separate your application into three parts:

• Model — the state of your application
• Update — a way to update your state
• View — a representation of your model as HTML

I find this to be a solid way of structuring web applications. The first part is the model, which holds your app state. Going through the Elm architecture examples really helps in showing how to model different types of data. I've also found union types to be helpful in creating custom types that express your intent more clearly.

The update section is how you change your app state. It receives an intent to change the state, computes the new state from the old one and returns the updated state object. Since everything is immutable in Elm, we are always returning a new state object after each computation, and never modifying the old one. This enables us to get a trail of how our model changes over time as people interact with it.

This concept makes debugging trivial since to reproduce a particular state, we can record the sequence of actions that were taken and apply them to the model to get to the state we want. This is the concept behind innovations such as the time traveling debugger, which you can check out in action in this Mario game.

Lastly, there's the view which is a visual representation of the model on the screen. Anytime the model changes, the view is updated automatically, and Elm is blazing fast at this.

The good news is that the JavaScript ecosystem is generally heading towards this direction with ideas such as a single state tree, reducers and pure view functions. In fact Redux is modeled after the Elm Architecture.

Try it

The best way to experience Elm is to try it for yourself. Even if you don't plan on using it on a daily basis, try it. Start with The Elm Architecture and take it from there. It will have a positive effect on any code you write in future. If it seems hard and confusing the first few times, give it five minutes.

The Elm community is pretty welcoming and you should join the Elm Community Slack and ask any questions that arise.

I can't wait to see what you build with Elm 😎