Elm in Production: Developer Reflections After 34k Lines of Code

I’ve been using Elm for the past two years. During that time I’ve written about 34k production lines of code in Elm across four projects. That work spans code from my very first day until today. My overall progression looked something like this.

A major part of Elm’s pitch is that it has no runtime exceptions. Does it mean there are no bugs? No, but they are much less frequent than in more orthodox languages. For me, most bugs actually appear in the interface between Elm and its impure environment.

How do you get into Elm and how to use it on a daily basis? Is the hype around Elm justified? Are the detractors right? Read on to find my take on the issues.

Disclaimer: Elm is my overall favourite language.

Effectively I’ve learned enough Elm to write my first production code within a couple hours. Then it took me a couple more weeks to get a fuller grasp of what’s going on. These here were roughly my stages of progression.

In the beginning I’ve started with the official guide. It’s a great place to start as it provides an overview of the language. However, for a beginner it can lack a little context. Often programming books provide more context, such as toy applications. Check out the new book by Richard Feldman (@rtfeldman) “Elm in Action” for a more complete guide.

While and after reading the guide, I’ve experimented with elm-reactor (seems to be abandoned/reworked now). Then I’ve integrated Elm with an ongoing Django project. Finally, I started to write some production code on the first day. The code still runs today, unchanged.

That initial production code was for an admin login. It was not necessary to rewrite that login interface, but it was a good opportunity for practice. Although today that’s an easy task for me in Elm, it took a little tinkering before I got it right on the first day. Don’t get frustrated, stay with it, after a little stubbornness usually things become clear and your brain wraps around new concepts, which then become second nature.

After some more coding, I’ve learned a lot from talks by Richard Feldman and Evan Czaplicki (@czaplic). Richard evangelizes Elm, while Evan is the inventor and main developer of Elm. I learned a lot from their talks here: “Scaling Elm Apps”, “Make Data Structures”, “The life of a file”.

Another good source for me was reviewing Richard Feldman’s RealWorld example app. Richard has a ton of experience writing in Elm, so his code is an excellent source to learn from.

Additionally, the usual applies: search for problems on Google/DuckDuckGo, read StackOverflow, check out the Elm forum. Consider joining the Slack channel. Code a lot, grow your code base, think deeply about the problems you code and how to solve them idiomatically, research and read. Grow larger projects and grow more complex projects.

Recently, I’ve discovered exercism for myself. Doing a track on exercism kind of feels like cheating when progressing through a new programming language. I’m currently using it to learn Haskell, but I’m sure that the Elm track is great as well.

I’ve been using Elm in a legacy project with Django (👍) and in new projects with Phoenix (👍👍). Both are relatively similar with regards to the integration with Elm, but both also have their quirks.

In both frameworks I began with server side rendering. Initially, I’ve started to replace existing features and then I began to add new features with Elm instead of templating. Most of the time I’ve used Elm for features that benefited considerably from interactive dynamism. But often enough I’ve also implemented other features in Elm, just for the heck of it. Try it out, it’s fun and provides good practice.

Check out gampleman/elm-visualization for some inspiration.

In both frameworks I’ve used webpack to get Elm running. It’s a pain. Each time I ended up wasting hours to get Elm running properly with webpack. This is not Elm’s fault, but still this nags me.

Once webpack is set up, it’s great though. During development webpack will trigger the compiler on file changes. In Phoenix you even get an automated page refresh out of the box.

In both frameworks, I keep the Elm code in the corresponding global static dir: `assets/Elm` for Phoenix and `static/Elm` for Django. One might want to separate the code by Django-app/Elixir application. However, I prefer to keep all the Elm code in one place and thus to keep the webpack config simple.

Again, in both frameworks, I’m using a RESTful API between the backend and the Elm code. That works neatly in Phoenix, which supports the full breadth of HTTP verbs. With Django there are limitations on the available verbs. For example, there’s neither PUT nor DELETE out of the box. So you need to improvise or use additional packages with Django.

With Phoenix I’ve tried out channels, which is an abstraction on top of web sockets. There are (abandoned 🤷‍♂️) bindings in Elm for that. However, for my taste there is still too much coding overhead. At least for my use cases the benefit did not justify the added complexity and extra effort.

In the beginning I’ve mostly used embedded apps in legacy code. The normal templates (Django templates and EEX) provide the placeholder for Elm and a dedicated JavaScript file bootstraps the Elm app. By now many of my older pages have multiple Elm apps running.

Let’s quickly go through the best parts of Elm. I am not going into details here, because I’d just be parroting the usual pitch. You can read about the details in others places.

Often Elm forces you to do things in a seemingly convoluted and complicated way. What I’ve realized after a while is that Elm actually only exposes the inherent complexity of the underlying problem. Elm forces you to face the complexity head on.

Furthermore, Elm provides you the tools to cope with that complexity. For example, decoding JSON values in Elm initially may seem overly complicated. Here’s an example where we decode a user struct with a decode pipeline.

Decode.succeed
        IdentityRecord
        |> required "token" Decode.string
        |> required "emailAddress" Decode.string
        |> required "userId" Decode.string
        |> required "roles" (Decode.list Role.decode)
        |> required "institute" (Decode.maybe Decode.string)
        |> required "color" (Decode.maybe ColorPicker.decode)
        |> Decode.map Identity

In JavaScript you can just access the fields once you get a response from a RESTful API. The catch in JavaScript comes later on, when you start to add workarounds for missing fields and fields with unexpected data types, or when you start to modify your data type. This leads to plenty bugs downstream.

In Elm you need to decode the response first, explicitly defining every expected field. But once you’ve defined the decoder you’re good to go. Either you can decode the value as expected or you’ll get an error response, which you will be nudged to take care of explicitly. So things in Elm aren’t really more convoluted or complicated, but actually simpler; maybe one could call Elm’s approach more “honest”.

Elm is a great programming language, but for most people not necessarily what they are used to. It’s a functional programming language (whatever that means) with strong, static typing. Functions are pure (i.e. there are no side-effects). The language is strongly and statically typed, so you have to make sure that all pieces neatly fit together before you can run your code. All data is immutable. These three aspects are pretty much the antithesis to dynamic languages, such as Python or JavaScript.

In my view, after spending years with dynamic languages (e.g. Python, JavaScript, Groovy) that’s really a relieve. As I see it, static typing, pure functions, and immutability add a steeper learning curve and take some getting-used-to. However, these concepts vastly augment your power to wrangle the complexity when your project grows.

Pipelining (mostly `|>`) is another great concept, which allows to chain function calls, without nesting them and without having to name intermediate results. Once you know pipelines, you’ll really miss them in other languages, such as python (pipelines for PyTorch would be magnificent, 🤔).

There’s no

null/nil/None

type or as its inventor Tony Hoare calls it: “my billion dollar mistake”. Instead you have a type called

Maybe

, which is the same as

Maybe

in Haskell and

Option

in Scala. Using

Maybe

leads to a little more work and a lot fewer bugs!

Here’s an example how you can deal with a

Maybe

value.

case mInput of
    Just input ->
        transform input

    Nothing ->
        defaultTransform

Generic types are great and allow you to abstract your code via polymorphism quite a lot. That means that you can write functions that operate on mostly unknown types.

Pattern matching is really good, especially once you’ll start applying more advanced features, such as matching in function arguments, the

as

keyword, and advanced pattern matching on lists, records, and tuples. For example, here we’re matching a pattern in a function argument:

fst : (String, String) -> String
fst (firstValue, _) =
    firstValue

The compiler is great. The error messages help a lot. The type system in combination with compiler messages allows you to do big refactorings without a headache. The compiler is fast, which is especially important and convenient during development.

The resulting asset is small and executes very quickly. Especially, when deploying for mobile it’s great to have a small build that doesn’t lag during usage.

The new time travel debugger can be of great help. The debugger keeps a history of all actions (received messages) with their resulting state. You can then jump through all historical state changes while debugging.

Finally, Elm pushes you to stretch your brain. Elm is not Haskell, but if you’re only used to object oriented programming or imperative programming, you’re going to dive into a different world that you didn’t know existed. In the beginning the concepts will feel awkward, but after a while they’ll feel like second nature and you will probably prefer the functional programming style for many tasks over the imperative or OO style.

The Elm Architecture defines how you can structure your app. This pattern is used throughout the Elm ecosphere. Its use is not mandatory, but in the end seemingly most projects do apply it.

Because most projects use the same basic architecture, it’s quite easy to find your way around other people’s code. Still, there’s plenty of flexibility baked into the architecture. For example, the update function can be changed to include additional arguments, such as a random value, the current time, an authentication token or a Navigation.Key.

Basically the same architecture is used for single pages (akin to components), for embedded apps, and even for single page applications. Kind of fractal 💥.

Elm has a list of great packages. My favorite ones revolve mostly around UI. These include elm-ui, elm-bootstrap, elm-mdc, and elm-visualization.

These days elm-ui is my go-to package for the UI. Actually, alone elm-ui provides enough value to me, to use Elm in the first place.

Another great tool I found useful is elm-parser, which allows you to create simple parsers. I’m using them for complex form validation (e.g. validating a date input in a free-form text field), and to parse complex values in

Json.Decoder

instances.

Of course, there are plenty more packages for all kinds of use cases.

On a day-to-day basis, Elm is just fun to work with. When you write and deploy your code, you can be reasonably sure that the frontend will work properly. When you or your collaborators change some code, again you can be quite sure that you don’t break something else. Finally, large refactorings are quite relaxed. They still might take some time, but you won’t have the constant feeling that you just jumped into the abyss and there’s just no way out of it. Often enough I’m doing refactorings in Elm that I wouldn’t even think about touching in Python, or for the most part, even in Elixir.

Finally, Elm is fun to use on a daily basis. Even when projects grow I can make good progress without running into complexity walls.

Nothing is perfect, so there are a couple of things about Elm that don’t suit me that well. Keep in mind that the benefits and downsides are not static. For me this list changed considerably during the last two years. A novice has different requirements than an advanced user. Also, before you read this remember that Elm is my overall favourite language.

My first, and probably biggest complaint, is about advanced languages features, especially abstractions. Many people complain about those, but I don’t see them as a showstopper. Also, they were no issue for me until I was becoming an advanced user. I would like to have typeclasses, more advanced functions on lists, dicts, and functions (

flip

is gone 🙁), pattern matching on function signatures (with fall-through), and guards. I understand that these features are mostly missing to keep the language simple and consistent. Especially for new users that’s a good choice. My guess is that actually the lack of those features might be the reason why Elm is more popular than PureScript, which is rather similar to Haskell and which has more advanced features.

Some things are surprisingly cumbersome in Elm. These issues pop up because Elm has no side-effects. For example, getting the time or a random value can be surprisingly convoluted.

A pure function cannot produce a random value or the current time itself, since side-effects are required for that. If you need the current time somewhere deep down in a function, you need to first send out a command to the runtime, then you get a message with your value, then you need to write a handler / case in your update function, and then you can go on with your business. This whole process can force you to change a lot of function signatures on the way.

React has nicer themes. On sites such as theme forrest, you’ll find plenty of themes with React components. You can still use those themes in Elm, but you’ll have to write the Elm integration (at least a couple of wrappers/renderers) yourself.

Material-UI is really impressive. There’s nothing as impressive as material UI (react) for Elm. Elm-mdc, elm-bootstrap are great and will suffice for very most applications. However, material UI is just more polished, including its animations and page transitions.

For some problems, there are just no good packages. For example, I’ve used Hands-on-Table in a project. When I used it the first time with Elm it was hard to get to work and required some hacky code. I had to write my own wrappers via JavaScript interop. Now, anybody else who wants to use the Hands-on-Table will have to do the same, because I can’t publish my interop code. Packages that use the port mechanism for interop cannot be published in the package repository 🤷‍♂️. Additionally, probably no one will write a table package that is as advanced as Hands-on-Table for Elm any time soon. So you don’t get proper access to the arguably most powerful JavaScript table package. That’s a trade-off for not having run time exceptions. Fair deal to me, but you’ll have to decide use case by use case.

Some bugs can be hard to find. I usually debug with log statements. Logging in Elm is relatively inconvenient:

let _ = Debug.log “log name” “foo” in ...

. Granted, it’s a lot worse in Haskell. Another good approach for debugging in other languages is a step-debugger. Well, there’s none for Elm 🤷‍♂️.

Recursive imports can be a nuisance, because they are not allowed in Elm. Recursive imports can be hard to avoid sometimes because reality is messy at times. You can easily end up with weird references between data structures. Although a nuisance, this issue shouldn’t appear to often and there are ways around it.

Although I’ve written plenty of Elm code and although I had to scale my applications again and again, I still don’t know how to do it properly.

I try to stick to writing modules around data structure. This approach sometimes leads to files that are a couple thousand of lines long. I’ve got

update

functions that span hundreds of lines. Although it’s kind of discouraged, I often separate parts out using the page pattern. However, creating a page that can keep track of its own state involves quite some overhead. You’re practically writing another app, which is embedded in your main app. However, writing a page without its own state often doesn’t seem a good choice to me, mostly because it blows up the code of the surrounding module.

Setting up Elm and issues due to missing abstractions bother me most.

The first issue has not too much to do with Elm. But setting up Elm with webpack to work in Django or Phoenix gets me every time. For me it takes a lot of fiddling until the setup works properly.

While some missing abstractions only lead to some more typing, there also are worse cases. As an example, when you want to restrict the keys to your

Dict

you need to use a

comparable

.

Comparables are defined by Elm and you can’t implement a

comparable

type yourself. That means you can’t just use an algebraic data type as a key in a

Dict

. In Haskell that’s resolved in a nicer way.

You define your ADT and derive

Eq

and

Ord

and you can use your new datatype as a key in a

Map

. So in Elm you either lose type safety over those values (by using strings directly) or you have to do some awkward manual conversion between ADT values and strings.

I’m coding Elm nearly everyday and I am looking forward to Elm’s future. Furthermore, there are plenty things I would like to explore more in Elm. Probably next up: GraphQL, Haskell/Elm Bridge, some more gampleman/elm-visualization.

Besides that I’m going to experiment with expanding the Elm experience to the server by developing a backend with Haskell. End-to-end type safety from Postgres to the browser sounds very appealing to me.

Actually, Elm might be the best pitch for Haskell for web developers!

If you like this article, please follow me on Twitter (@chronz_peter). I’m posting my experiences with Elm, Elixir, Haskell, and PyTorch.