A year of Elm

It hasn’t quite been one year since I wrote the first post on Elm, but it’s not that far off and the title was clearer that way. In this time I have written three programs in Elm, each one more complex than the last:

1. Client for the catalogs generated by cataloger. My RPG resources catalog is an example of the result.

2. Prexxer, a “Dress-up” application to combine sprites and create characters. You can see the code on GitHub.

3. NARROWS, a storytelling system halfway between online role-playing games and improvised Choose Your Own Adventure books.

The first one was useful to get to know (and love) Elm, and of course to get my RPG resources catalog online. With the second I learned about Elm ports (the interface to interact with JavaScript) and got a bit more comfortable with Elm. With the last one, the only one that has a back-end (written in ES6, though; Elm is only for front-end), I learned how to structure big applications in Elm, how to use the excellent ProseMirror, and how to use much more complex Elm ports.

What I like about Elm

• It’s a simple language with few concepts, easy to learn and understand. After my initial (small) struggles, I have mostly loved it since.

• The Elm Architecture is really nice and simple, and it’s nice that it’s integrated into the environment. It’s like having a framework for free with the language.

• Everything immutable: the easy way is the right way.

• Nice, clear, useful compiler error messages.

• Generally nice toolchain.

• Static types help you a lot, mostly without being annoying.

• Newer major versions of the language simplify things further and make things clearer and less error prone (I’ve been through two major updates).

What I don’t like about Elm

• The compiler seems slow and often seems to compile older versions of the code. This might be my own fault, as I have a custom Brunch configuration with an Elm plugin and I don’t even understand Brunch all that well. In comparison, the TypeScript compiler was amazing.

• Some complex types and interfaces, notably the modules for HTTP requests and JSON parsing. The former improved a lot in the new version, Elm 0.18.

• Newer major versions of the language break compatibility and you have to rewrite parts of your application, which is really annoying… but also worth it.

• I’m not that fond of currying. Sometimes I feel like it makes some compilation error messages harder to understand.

Conclusion

I’m really happy I gave Elm a try almost a year ago. Although I’m looking forward to going back to ClojureScript for some project, I really, really enjoy Elm, and it has almost become my defacto front-end language/framework.

• elm
• frontend
• functional
• functional programming
• projects
• role-playing games
• rpg
• storytelling

First impressions of Elm

For my next pet project I decided to learn Elm. Elm is a functional language similar to Haskell, that compiles to JavaScript. These are my first impressions so take them with a grain of salt.

Syntax

Elm’s syntax is similar to Haskell’s. I had tried to learn Haskell a long time ago but failed miserably because I couldn’t understand the types. I did not find Elm’s syntax to be a problem, and it was nice and simple, especially compared to Elixir, the last language I had learned. However, I think it was the first time in my life that I wished I had had a small syntax description or guide before diving too deep into the language. For me there were two confusing things:

1. Sometimes I saw a bunch of words that were separated by spaces or by commas, and it took me a bit of time to realise that function arguments are separated by spaces, but elements in a list or similar are separated by commas.

2. Compound types that have more than one word, like List Int. That one is easy to figure out of course, but when I saw Html Msg I had no idea what it meant. I’m still not completely sure, in fact.

The first point in particular has an implication: if you use the result of a function call as an argument for second function you must enclose the first function call in parentheses. This all seems super obvious in retrospect, but when staring at code that uses a DSL-like library to generate HTML in a language you’re starting to learn… well, it would have helped to have the first point spelled-out. Example:

    ul []
     (List.map (tagView sectionPage)
        (ModelUtils.getSectionTags section))

Here we have a call to the function ul that has two arguments: an empty list and another list, namely the result of the call to List.map. Note how the whole List.map must be enclosed in parentheses: otherwise, it would be interpreted as a call to ul with four arguments, not two. In the same way, both arguments to List.map must be enclosed in parentheses, too.

Elm Architecture

Although strictly speaking you don’t have to use it, the Elm Architecture is a fundamental part of Elm. It’s the high-level pattern for application architecture when writing Single-Page Applications in Elm, the main usecase for the language. The pattern is very similar to redux and friends in React, but it’s nicer and more natural in a functional, statically-typed language like Elm.

In short, it means separating your application in sub-applications that have a model, a React-style view produced from the model, a set of messages the view can send, and an update function that receives messages and changes the model. Besides, Elm supports commands and subscriptions, which gives a nice, clean interface for WebSockets and other things.

Conclusion

Although I’ve been looking forward to going back to ClojureScript, and in particular learn and play with Om Next, Elm is certainly a worthy contender and totally worth checking out, especially if you’re using React and you want to go one step further.

I admit I did get frustrated now and then with the static types, and at first a bit with the syntax (see the two points above) and the indentation. However, all in all I enjoyed learning and using Elm a lot, and it feels very clean, productive, and just nice to program in.

The application I wrote was very small, though, and I didn’t quite get to explore patterns in how to split an application in several sub-applications. I did read a bit about it but didn’t get to use anything fancy.

And if you want to see what I built, head over http://rpg.hcoder.org/ for the site, or https://github.com/emanchado/rpg-catalog for the code.

• elm
• frontend
• functional programming
• programming
• programming languages
• web
• webapp