(Photo by Diego Madrigal from Pexels ) 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. Elm is my overall favourite language. Disclaimer: How I learned Elm 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. Official Guide (, “Elm in Action”) In the beginning I’ve started with the . 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 ( ) “ ” for a more complete guide. official guide @rtfeldman Elm in Action Coding with Django and Phoenix While and after reading the guide, I’ve experimented with (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. elm-reactor 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. Watch talks by those in the know After some more coding, I’ve learned a lot from talks by Richard Feldman  and Evan Czaplicki ( ). Richard evangelizes Elm, while Evan is the inventor and main developer of Elm. I learned a lot from their talks here: “ ”, “ ”, “ ”. @czaplic Scaling Elm Apps Make Data Structures The life of a file Read other peoples’ code Another good source for me was reviewing Richard Feldman’s . Richard has a ton of experience writing in Elm, so his code is an excellent source to learn from. RealWorld example app Join the community Additionally, the usual applies: search for problems on Google/DuckDuckGo, read StackOverflow, check out the Consider joining the . 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. Elm forum. Slack channel Bonus: Exercism Recently, I’ve discovered 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. exercism How I’ve been using Elm I’ve been using Elm in a legacy project with (👍) and in new projects with (👍👍). Both are relatively similar with regards to the integration with Elm, but both also have their quirks. Django Phoenix Piecewise adoption 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 for some inspiration. gampleman/elm-visualization Integration with Django and Phoenix via webpack 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. RESTful APIs over channels (sockets) 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 🤷‍♂️) 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. bindings in Elm 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. Things I like 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 Exposing complexity 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. https://twitter.com/elmradiopodcast/status/1254912574115557377?s=21 Furthermore, Elm provides you the tools to cope with that complexity. For example, decoding JSON values in Elm initially may seem . Here’s an example where we decode a user struct with . overly complicated a decode pipeline .succeed |> required .string
        |> required .string
        |> required .string
        |> required ( .list .decode)
        |> required ( .maybe .string)
        |> required ( .maybe .decode)
        |> .map Decode IdentityRecord "token" Decode "emailAddress" Decode "userId" Decode "roles" Decode Role "institute" Decode Decode "color" Decode ColorPicker Decode 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”. The language itself Elm is a great programming language, but for most people not necessarily what they are used to. It’s a functional programming language ( ) 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. whatever that means 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. (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 miss them in other languages, such as python (pipelines for PyTorch would be , 🤔). Pipelining really magnificent “I call it my billion-dollar mistake. It was the invention of the null reference in 1965.” — Tony Hoare There’s no type or as its inventor Tony Hoare calls it: . Instead you have a type called , which is the same as in Haskell and in Scala. Using leads to a little more work and a lot fewer bugs! null/nil/None “my billion dollar mistake” Maybe Maybe Option Maybe Here’s an example how you can deal with a value. Maybe mInput input ->
        transform input ->
        defaultTransform case of Just Nothing 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. Generic types is really good, especially once you’ll start applying more , such as matching in function arguments, the keyword, and advanced pattern matching on lists, records, and tuples. For example, here we’re matching a pattern in a function argument: Pattern matching advanced features as : ( , ) -> (firstValue, _) =
    firstValue fst String String String fst The compiler is great. The help a lot. The type system in combination with compiler messages allows you to do without a headache. The , which is especially important and convenient during development. error messages big refactorings compiler is fast 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 . 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. stretch your brain The Elm Architecture (TEA) 🍵 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. The Elm Architecture 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 💥. High quality packages Elm has a list of great packages. My favorite ones revolve mostly around UI. These include , , , and . elm-ui elm-bootstrap elm-mdc 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 , 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 instances. elm-parser Json.Decoder Of course, there are plenty more packages for all kinds of use cases. Blissful everyday use 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. Things I dislike 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 Missing advanced language features 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 ( 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 , which is rather similar to Haskell and which has more advanced features. flip PureScript Getting a random value, the time etc. Some things are surprisingly cumbersome in Elm. These issues pop up because Elm has no side-effects. For example, getting the time or a can be surprisingly convoluted. random value 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. Missing packages 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. 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. Material-UI For some problems, there are just no good packages. For example, I’ve used 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. Hands-on-Table Hard to find bugs Some bugs can be hard to find. I usually debug with log statements. Logging in Elm is relatively inconvenient: . 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 🤷‍♂️. let _ = Debug.log “log name” “foo” in ... Recursive imports 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 Scaling the architecture (🤔🤷‍♂️) 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 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. update Things I dislike even more 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 you need to use a . Dict comparable Comparables are defined by Elm and you can’t implement a type yourself. That means you can’t just use an algebraic data type as a key in a . In Haskell that’s resolved in a nicer way. comparable Dict You define your ADT and derive and and you can use your new datatype as a key in a . 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. Eq Ord Map What’s next 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: , , some more . GraphQL Haskell/Elm Bridge 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 ( ). I’m posting  my experiences with Elm, Elixir, Haskell, and PyTorch. @chronz_peter

Chain

Google

Slack

Twitter

Follow me on Twitter for more: (@chronz_peter)

Read My Stories

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

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

Too Long; Didn't Read

Companies Mentioned

Coin Mentioned

Peter Chronz

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

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

Too Long; Didn't Read

Companies Mentioned

Coin Mentioned

Peter Chronz

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES