Jamison Dance hit a home at his React.js Conf 2016 keynote. Here’s the YouTube of his 30-minute presentation, talking about a new programming language called Elm. He’s exactly the sort of person I love working with: intelligent, humorous, experimental. His presentation wasn’t looking to teach us how to program in Elm, but rather why we should want to learn to program in Elm. At a high level, here were his reasons:

  • Elm has a strongly typed system so that you don’t have to spend as much time worrying about the edge cases of your data flow. Functions have to return specific values, not just anything. Oh, and they don’t allow null as a return value.
  • Elm only allows stateless or “pure” functions. In other words, the only things that the function can use are things that are passed to it. This means that no dependency injection or mocking is necessary to test the function, and it’s a lot harder to right buggy functions that have unexpected outcomes.
  • Data is immutable. A function that takes in a user object, for example, can’t modify that user object directly. It can only return a copy of that object.

Underlying Jamison’s presentation was a quote he gave from Edsger W. Dijkstra:

The competent programmer is fully aware of the strictly limited size of his own skull.

Elm was built with this limitation in mind. It handles stuff that computers are good at so programmers can handle the stuff humans are good at: building user experiences that are unique to a given application’s domain.

This is a really appealing concept. When I first studied JavaScript, it was the most frustrating language I’d ever seen. It was more frustrating than C or C++, even. Maybe that was because it was the first functional programming language I’d tried to learn. Out of the box, traditional C-based languages are a lot more intuitive to a beginning computer scientist to learn. With JavaScript you can write anonymous functions, create variables that can store any data type you want, change that data type on the fly, reference object properties using array syntax, on and on.1

This isn’t to mention the subtle memory gotchas you can inadvertently slip into.2 For instance, since arrays are referenced by memory, you can create two variables pointing to the same array. Modifying an item of that array will modify both variables. If you perform the concat() on one of those variables, however, you’ll split the references, since that function returns a new array. Check it out:

var myArray = ['red', 'white', 'blue'];
var copy1 = myArray;
myArray[1] = 'green';
console.log(myArray); // ["red", "green", "blue"]
console.log(copy1); //  ["red", "green", "blue"]
myArray = myArray.concat('orange');
console.log(myArray); // ["red", "green", "blue", "orange"]
console.log(copy1); // still ["red", "green", "blue"]

Not only is JavaScript a hard language, but the things that it’s used for on the modern web are hard. In a Single Page Application (SPA), a JavaScript program can live for a long time, and a lot of changes can take place during that period. Its state doesn’t end until the user closes the browser. For this reason, building a SPA is more similar to building a native app for an operating system than it is to building a web page. If you’re building a SPA and you have a background in traditional web pages that are reloaded every time the user wants to visit another URL, you’re in for some unexpected complications. Things that used to get reset will now potentially remain as they were from the previous URL, unless you mindfully reset them.

Without great effort, red errors flow long and deep in browser consoles when JavaScript is present. I’m in agreement with Jamison: in a way, it’s sad that services like TrackJS can exist, despite how dearly I love TrackJS. It proves that a company can build a business around telling us when and where our JavaScript failed. I haven’t written anything in Elm yet, but from the looks of it, it’d be near-impossible to have runtime errors, given it’s a strongly typed compiled language with strict standards. In Jamison’s words:

I think Elm is what the JavaScript community is evolving towards, but it’s built into the language.

It’ll be interesting to see if Elm becomes a hugely popular language, or if we keep using JavaScript but increasingly adapt its standards into our frameworks and projects.

The JavaScript community is moving incredibly fast. Thanks to AngularJS and ReactJS, we’re building apps that are much more client-centric than what was possible 10 years ago. Back then, being a front-end developer meant writing HTML and CSS, but now, as many programming skills are required for building for the client as they are for the server. No matter what direction things go from here, one thing’s for certain: this story is far from being finished. It’s the Wild West. We’re still figuring out where the puck is headed, and it’s a fascinating and exciting journey.


  1. One of the computer science students at Northeastern State University built his senior project in JavaScript. If I remember correctly he lost literally weeks debugging a issue caused by his omitting to declare var in front of a variable in a function, which of course caused its scope to be global. If you’re looking for a great read on JavaScript scoping, Dr. Rauschmayer has the article for you. ↩︎
  2. Am I entering a rabbit trail here, just because I want to talk about a bug that took me an hour to figure out the other day? Absolutely. Would stuff like this not be possible with Elm? I’m honestly not sure since I haven’t worked with it yet, but for the purposes of this article and the sake of argument, let’s say it couldn’t. ↩︎