Recently I started getting very interested in Elm, a functional programming language for the front end that compiles down to HTML, CSS and JavaScript. I’ve never really found myself drawn to compile to JavaScript languages before, but the more I heard about Elm, the more interested I became.

The Inspiration for Redux

I first heard Elm mentioned as I began learning Redux, the data handling layer for React and other front end frameworks. While creating Redux, Dan Abramov looked to the Elm architecture for inspiration. Redux is a solid data handling paradigm, so what inspired it must be pretty great, right? In any case, I was intrigued.

Then I began watching Elm keynote videos to learn more high level stuff about the language quickly. The speakers gushed over Elm. They cited its functional, declarative style, great error handling, and ease of refactoring as major points in Elm’s favor.

No Red Ink’s Experience with Elm

One presentation in particular really planted the seed for me (video below). Speaker Richard Feldman spoke about how user friendly Ruby on Rails is for the backend, and how he had wished there was a comparable language for the front end.

When his company, No Red Ink, switched from their previous stack to React + Flux, it was a major upgrade for them, but there were some headaches associated with refactoring.

According to Richard, the React stack is really great at taking multiple, complicated layers, and organizing them in a way that is easy to reason about. This is my feeling on React as well, an ecosystem I really enjoy working in. But when No Red Ink’s product wasn’t as effective as they had hoped, they saw a need to do a major refactor.

I know from experience the headache this can be from when I swapped Flummox for Redux on a project for Concur’s App Center. In my case, I was really only changing the data layer. From the sound of it, Richards team needed an entire product overhaul, and the React paradigm wasn’t exactly facilitating it.

Then they started to test out Elm. Not only does Richard claim that Elm is quick to build and simple to refactor, he also claims that their team makes sizable refactors on a regular basis without headache. Ok, Elm is something that I needed to see.

My First Impressions of Elm

To get my feet wet, I decided to follow Richards straight forward tutorial on creating a live validating form with Elm. It’s a great tutorial, even if it suffers from some unfortunately formatted code snippets (the lines don’t wrap, so some longer lines of code get cut off making you guess what’s going on).

So how do I feel about Elm after this first experience? Pretty great actually!

1. I Like the Syntax.

Below is a code snippet from the tutorial. To me the syntax seems fairly Ruby-esque. Parameters are space separated after the function declaration, giving it a clean look, and functions automatically return the last thing declared.

Beyond that, it surprised me just how simple it was to add validations to this short form. The logic was simple, terse and effective. From my first foray, I can see why Elm’s proponents praise the language for development efficiency.

view actionDispatcher model =

form

[ id “signup-form” ]

[ h1 [] [ text “Sensational Signup Form” ]

, label [ for “username-field” ] [ text “username: “ ]

, input [ id “username-field”

, type’ “text”

, value model.username

, on “input” targetValue (\str -> Signal.message actionDispatcher { actionType = “SET_USERNAME” } )

] []

2. The Errors are… Polite?

Yeah, that’s right. These are the most polite error messages I’ve ever seen. I remember working with Ruby on Rails and thinking just how useful their error messages were. With Rails, you can develop a basic crud app without any scaffolding by simply following the error messages.

Elm’s messages seem to be just as, if not more useful than those in Rails. Wow!

Here’s an example:

The 2nd argument to function `onClick` is causing a mismatch. 65│ onClick actionDispatcher { actionType = “VALIDATE”, payload = “” }

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Function `onClick` is expecting the 2nd argument to be: { … } But it is: { …, payload : … } Hint: I always figure out the type of arguments from left to right. If an

argument is acceptable when I check it, I assume it is “correct” in subsequent

checks. So the problem may actually be in how previous arguments interact with

the 2nd. Detected errors in 1 module.

Oh, and when downloading dependancies, Elm makes you feel kind of like the Capt. Picard (yes, Next Generation is my Star Trek):

Some new packages are needed. Here is the upgrade plan. Install:

elm-lang/core 3.0.0 Do you approve of this plan? (y/n)

Why yes I do approve, number 2.

3. Functional Programming FTW

This one is kind of obvious. Elm is a functional language. I’m a fan of functional programming, and exercise functional practices in JavaScript. Elm was my first trip into a purely functional language, and I have to say, I really liked it.

Functions in Elm are pure, meaning they have no side effects. Functions explicitly return their last declaration. They are called by a space. I haven’t delved deeply enough into Elm to expand any more on this yet, but I hope to soon.

4. It Just Seems Very Efficient

I sorta already covered this when I talked about syntax, but Elm seems to take very little effort to get semi-complex things done. Of course my experience with Elm is super limited thus far, but what I’ve heard and what I’ve seen seem to line up with this.

Expanding on that: one thing I’m looking forward to learning more about is how much easier Elm supporters say it is to manage and refactor than something like React or Angular.

I’ve seen a few people claim that everything is easier without offering up concrete examples or anecdotes. If you’ve used Elm in production and agree with the above statement, please share just what about it is easier (or conversly, if you disagree I’d like to hear about that too).

Conclusion

I’m really excited to take a deeper dive into Elm, and though the Elm community is small, they also seem very passionate. Time will tell how the Elm language fares, but I have high hopes for it thus far. I’ll be sure to share some deeper insights once I have the footing to do so. Til then, ttfn.