Elm in 5 minutes

This is a very short intro to Elm, which doesn’t focus on the language itself, but instead on its purpose, architecture, tooling, advantages and drawbacks. It’s essentially what I would have liked to read to help me get Elm more quickly.

Including horrible slides quickly made using post-it notes, as well as some text.

Elm is a language that compiles to JavaScript. It’s got no backend component. It’s all happening in the browser. Using elm can happen in two ways:

in your MVC framework, you can write components in Elm that get compiled to JS to be integrated into your front-end. Just like SASS gets compiled to CSS, or ES6 compiles to JS. elm-make is a command line tool that does the compilation

2. Your whole front-end can be written entirely in Elm. You just pop your files in a directory, run ‘elm-reactor’ and take your browser to localhost:4000

(There’s actually a 3 : you can also use Elm modules as web workers)

Elm is a language: functional and statically typed. Its syntax is similar to Haskell. The author has made a lot of efforts to make it easy to use: very nice error messages, good toolkit (editor plugins, debugger, compiler), unequivocal style guide, etc.

Elm is also an in-browser MVC architecture (sorry for the typo in the picture), which can integrate with the rest of your site by providing a way to talk to existing JS code.

Code looks like this (you don’t need to try and understand all of it just yet):

“No DOM” means that you never have to manipulate it. All you have to do is provide a function that builds your HTML from your model, as the HTML is regenerated at any interaction. It’s faster than you think thanks to a very fast DOM diff implementation.

Strong type checking means that most type errors will be caught when compiling. You will be forced to write safe code (handling all cases of a case, for instance), and won’t have to worry about dangerous stuff, like type coercion. It’ll make you trust your code more.

Drawbacks:

Your CSS and HTML are written in code (see the view function above). It looks declarative (YAML-ish) but is indeed code. So while that lets you do anything (bye bye SASS), it looks horrifying at first. And breaks the separation principle.

Given the radical changes mentioned, it makes Elm a steep learning curve for JS devs. Using plain JS to do reactive is full of pitfalls, not because of ReactJS or other frameworks, but because of the language itself. Elm helps dramatically, as the reactive paradigm is part of the language’s architecture.

After 4 months, I think I’m over the hump in terms of learning, and I think that eventually the advantages will make up for the time spent learning. It’ll depend on industry adoption, of course. But even if elm doesn’t become mainstream, your time won’t be wasted, having learned to write code in a more functional way, which is essential with reactive front-end development.