Elm at Prezi: Functional Reactive Programming for The Web - Engineering at Prezi

The cost of writing JavaScript is just too high. Every new and innovative feature costs too many lines of JavaScript code, and every line of JavaScript code costs too much time to maintain. Nevermind making that code performant. That’s a job for a code generator, not an engineer. JavaScript is broken, but that doesn’t mean we have to put up with it. And we don’t intend to.

Starting today, Evan Czaplicki is joining Prezi on a full-time basis. He’ll continue to develop Elm, a statically-typed, functional-reactive programming language that compiles down to JavaScript and runs in the browser. Elm’s development will remain open-source, and all the development that occurs within Prezi will make it into every release. The goal is to provide a viable, open-source language that’s both an alternative and complement to JavaScript for front-end development. Here’s why we think Elm is that language.

Functional Reactive Programming

Elm is a language built around functional-reactive programming (FRP). That means two things. First, it’s a functional language—functions are first-class values, values are immutable, and you can’t reassign variables. Second, the way Elm handles user input is different, and more concise. For example, your web application might want to know when the mouse position changes. In Elm, the mouse position is a special kind of value called a Signal that you can embed in expressions. When the mouse position changes, the Signal changes value, and every expression it appears in is automatically recomputed. You don’t have to use callbacks, so you avoid inversion of control and callback hell. The result is shorter and easier to understand programs, written in a declarative style.

FRP has been a subject of academic research for years. It’s not new. But Elm is applying FRP concepts specifically to the problem of developing GUIs for the web. It’s also taking a novel approach to supporting asynchronous computation, the details of which you can read in this PLDI paper. Doug Crockfordsaid it best at MLOC.js: It just doesn’t make sense to create another Java-like language and expect it to spur innovation in the way we develop GUIs for the web.

Static Typing

Once any code base grows to millions of lines, it’s hard to keep track of how a change in one part of the code base will affect another. It’s even harder when you’re dealing with a dynamically-typed language like JavaScript. But Elm is not like JavaScript. It’s statically typed, so the compiler will ensure that you’re respecting the type assumptions that you make throughout your code base. A type system is no replacement for tests, but it does give you much more confidence in your changes while you’re in the thick of development, without any additional effort.

Compilers Can Optimize

That is, without any additional effort from the developer. The Elm compiler translates Elm source code to JavaScript, and type checking is part of that process. If type checking of a program is successful, then the compiler not only verifies your type assumptions, but is also aware of those type assumptions. Combine that with the fact that Elm is a purely functional language and suddenly compilation turns into a huge opportunity for optimization. Those optimizations can range from the typical such as deforestation and let-lifting, or they can go as far as targeting ASM.js for certain sections of generated code.

Keep Moving Forward

Elm is still a young language that has some growing to do. But in a short amount of time it’s attracted a strong community. It has a promising future ahead, and that’s something we want to make sure is realized. The best way to do that is to become a part of that future. Check out some examples, start using it, and start contributing. The Web cannot afford to wait for an alternative to JavaScript.