Dealing with complexity

Most frameworks attempt to make the experience “easy” by hiding the actual complexity of what a webapp truly is. Such an application always has a lot more possible states than we expect when we start coding.

Many of those unexpected states translate into bugs, often runtime crashes. Then we spend a lot of time tracking them down, and this time is usually a big part of the total time spent on a given application.

Elm does way better than hiding complexity: it forbids you from ignoring it and gives you the mean to tame it.

The Elm approach to solve this general problem is to force you into dealing with every possible state of your application. If you don’t, the compiler will stop.

This fantastic ability is a reality because Elm is a functionnal language. It allows the compiler to check every branch of your code and to make sure you deal with every possible result of every function call.

Event though it can be very frustrating when you start with Elm (thinking functionnal is not easy when you have years of non-functionnal programming), the compiler will quickly become your best friend.

Once a part is done, it will not silently break into pieces as soon as:

• you try to update a few libs just to get security fixes
• somebody touches a nearby piece of code and does not try hard enough to check for secondary effects

Once made your friend, the compiler gives you a freedom you rarely experience in a framework. A TRUE one, that allows you to consider almost any change in your app without being scared.

Refactoring

You know this dreaded moment when you have to make a decision on rewriting a given part of your application?

If you have a little experience you know what it means: if you don’t have enough unit-tests you may know way too late that you introduced new bugs because you have forgotten to adapt some other part(s) of the program to your changes.

With Elm, this risk is very limited: as soon as you change some api, the compiler will force you to fix each and every place where your api is used.

You will sleep like a baby, even if you make some refactoring in you internal API 2 days before releasing, because once it compiles, you know you did not forget anything.

And even if you manage to forget something the compiler did not see, tracking it down after a bug report is generally very easy.

Refactoring is not a hard decision anymore.

Beautiful code

Coding with Elm forces you to think. You cannot write random code then try to fix it until it works. Thinking first is not only more efficient but required!

And we can feel it in the final result: the code is globally better structured than what we usually get with other languages/frameworks.

Ecosystem

Ever heard of JSFatigue? Feeling it?

Do you dream of a place where using a third-party library does not mean that each build of your application may fail because of a change in it?

A place where no api change can ever be silently published and blow up your program a few hours before releasing?

This safe heaven on earth exists, and it’s http://package.elm-lang.org/. You may not find as many things as on npm, but most of those you will find here are actually usable.

Focus on the code

All this makes the webapp built with Elm very robust, and sooo comfortable to maintain!

A few weeks ago we had a big rush on one of our projects. Many tasks, some of them complex, had to be done.

It was the occasion to realise how much Elm allowed us to focus on coding features, when other parts written in django, python or go all implied so many distractions like runtime exceptions to track down, third-party library not doing what was expected because of some dependency changes, etc.

Others will rarely break your app

Playing with CSS is not my strong point, but fortunately other people on my team are very good at it. When needed they work directly on the elm app, even though they are not familiar with Elm.

And it all works perfectly: they cannot break everything by accident, as the compiler will stop them. And if they have trouble figuring out how to produce the piece of domtree they want, guiding them in the code is quite straightforward.

The same thing with big templates in a complex django app, for example, is much less safe: how much time wasted looking for a bad closing tag that broke the entire layout!

Maintenance cost

This point is particularly important if you need to convince your management (or your client) that choosing elm is a good decision to make.

From what we have seen so far, the maintenance of our elm code base is much lighter than with other languages we use, for all the reasons I mentionned before.

We seldom need to come back on the elm code, and when we do, it is a lot safer and we hardly have regressions because of a fix in the elm codebase.

This and the fact that the ecosystem is very stable makes us confident that anything we write in elm is here to last with little maintenance effort.