Building a web app with functional programming - Elm - part I

Summary

  1. Building a web app with functional programming series :bookmark:
  2. Definition of production ready :bookmark:
  3. Elm - part I :bookmark:
  4. Elm - part II :bookmark:
  5. Haskell - part I :bookmark:
  6. Haskell - part II :bookmark:
  7. Nixos :bookmark:

Hi again ! Great to see you for the first part of Building a web app with functional programming. If you’re here, it’s probably because you are interested in Elm (and you should be !).

This first part on Elm will focus on the language itself and the second part on its ecosystem.

Background

It should be said that before working with Elm, I had prior experiences with FP (Scala, Haskell, Lisp).
I tried Elm for the first time in 2016 with, I believe, the 0.16 version (0.19.1 at the time of writing). Back then, I had a hard time understanding some of its concepts (signals for example) but thought it was a promising language.
Couple of versions later, everything related to functional reactive programming, which also happened to be Elm’s toughest topic, were removed. Nowadays Elm is much simpler.

When I started working on Patchgirl, I wanted to learn something new and interesting. There was few compelling technologies: GHCjs, Purescript and Elm. As a backend engineer, I needed something easy to pick and quickly be productive with so I went with Elm which seemed to be the human friendliest one.

The language

Learning curve

Elm is a strongly typed language with a Haskell like syntax. I wish I could give a feedback on its syntax but because I knew Haskell beforehand, I’m biased and learning Elm felt dead simple to me.
What I can say instead is that while doing a workshop (thank you @rtfeldman for this great work) in my former company, the feedbacks were great and many of the developers (mainly scala devs) said it felt nice and easy to play with.

Power, you (probably) ain’t gonna need it

One feature that Elm lacks is powerful abstraction. It was designed to make it easy to learn and fast to be productive with.
I like to say that Elm is Haskell without the hard parts because you don’t need to know about concepts like Monad, Functor, Type classes and whatnot.
Elm provides a simple API that will be plenty enough for the vast majority of the cases. I’ve learnt to appreciate this philosophy that I believe is quite adapted to real world application.

So if you need a language that can generate code, avoid all boilerplates and provides powerful abstractions you should probably not use Elm.
If instead you just want to deliver quickly a high quality product then Elm is a great choice.
For my project, Elm was a great pick.

Elm architecture

I could talk about the elm architecture for hours but many have done it before me. In a nutshell, it’s a pattern to do IO computation (interact with the outside world, eg: send an http request, parse a form, …). One of its benefits is that it forces the developer to handle all possible cases like errors.
I need to pinpoint that it’s actually quite simple to understand. After browsing Elm’s guide you quickly grasp the main idea and can start play with it.

The compiler

Helpful

I’ll be straight to the point, Elm compiler is an AMAZING piece of work. It clearly was designed to be developer friendly. This is for me the best thing about Elm.

I think of Elm compiler more as a guide than a compiler. Most of the time it will tell you with human readable sentences what’s wrong with your code and in certain cases, it even gives you the solution to your problem.
As a beginner, it helped a lot picking up the language. Elm error message are both accurate and helpful. I almost never needed to google an incomprehensible error which is quite a delightful experience.

Performance

Let me talk about the compiler’s performance. Elm is a real beast. I have been compiling with many languages before and it was always frustrating to wait for the compiler to finish even for tiny modifications. With elm, you don’t have to wait a single second.

On Patchgirl, it takes less than 1s to compile roughly 6500 lines on a 5 years old laptop (an XPS 13).

elm make elm/Main.elm  0.46s user 0.27s system 82% cpu 0.898 total

I’m still mind blown by how fast that is and never thought such performance could be possible.
The compile time feedback is so fast that sometime, I think the compiler did not run at all.
In term of developer experience, it feels weird to no longer be able to browse twitter while it compiles 😶

Refactoring

As we improve our skills and with the product requirements evolving, we constantly need to refactor our software. With Elm’s strong typing and great compiler, refactoring is a child’s play. It is so easy that it might be boring as you have to put your brain in sleep mode and just follow the compiler errors/advices. There isn’t much more to say about it, it’s just easy and I love it ❤️

Conclusion

I had a huge crush on Elm and still has. I stopped doing front end development because of how frustrated I felt writing javascript. Elm brings everything good about FP into the browser without the cost of complexity and will satisfy both experimented and beginners developers.

Its type system (records and sum types) are adapted to design real world problem. Its compiler make refactoring a piece of cake. Baked in functional programming, it is maintainable and stable (no weird side effects, no runtime errors).

If I had to describe my experience with Elm it would probably be “ease, fun and productivity”.

Keep reading on elm with the second part here :bookmark:

:cactus: