3 min read
on Jun 9, 2015
In this talk from Forward 2, Prezi CTO and cofounder Peter Halacsy discusses JavaScript functional reactive programming and the Elm programming language.

Prezi is an online presentation creation tool that runs in the browser and on mobile platforms. In the talk below, Peter Halacsy, co-founder and CTO of Prezi, discusses functional reactive programming, and explains why Prezi is committed to investing and growing FRP.

Thanks to New Circle, providers of advanced JavaScript training, for filming and producing these videos.

Complex Interactions

A mouse click is just a mouse click, but in Prezi it could be a zoom command, a selection command or any other command depending on the state of the application. Peter shared a post-mortem document written by Prezi engineers describing a bug relating to inconsistent state. He describes how embarrassing it was to discover one particular bug which could have been avoided using functional programming.

According to a document published by Adobe in 2006:

33% of code is in event listeners

50% of the bugs are coming from that code

90% of the interaction designers concerns are covered by this code

First, we had the idea of MVVC, similar to Knockout.js. Unfortunately, this doesn’t scale; you tightly connect the model and view which is automagic but not the solution.

Complex Interaction

Peter read a paper in 2012 “Deprecating the Observer Pattern,” which connects the view and the model (albiet in the wrong direction.) When he saw Scala.React, they thought “This is the solution for all of our problems! We can use declarative programming to write the rules of interaction!”

How nice would it be if we didn’t need engineers? Designers can define the interactions, because they’re the ones who care about how it should work, and then it should just work. That’s declarative programming. It won’t work in the next 20 years, but this is a good dream.

Type Safety

After Scala.React, something else happened. Peter was an ex-functional programmer. Peter now likes type checkers and type safety. One guy took four Python open source libraries, took a type checker and pointed out that only one of those four projects didn’t have any type errors; he found 17 bugs in 6,000 lines in a library with high-coverage unit tests. Why not use type checkers if they work?

Here’s a silly code sample to illustrate how type checking is important:

Screen Shot 2015-05-01 at 12.38.09 PM

Everybody knows not to do this, but what are the consequences? One of Prezi’s very few outages was caused by a programmer forgetting to add the return to the else branch. It would be great if the compiler could find these mistakes.

Strong Opinion

Compilers make large scale creativity possible. We like craftsmanship. We care about high quality and practice pays back. We should avoid repetitive, manual work. We don’t need to spend all our time writing unit tests if we can catch more errors with the compiler. You need tools and systems to design complicated projects.

Automagic Sync

Cache invalidation is hard. In a growing company, you would like to build a microservice-oriented architecture, and it’s difficult to synchronize these distributed systems. Reactive programming can help solve this automatic synchronization issue for you.

“We all are writing future legacy code. If your code won’t be legacy, it’s useless.”

It’s important to care about how readable your code is. JavaScript is not super good for that. Reactive programs are easier to comprehend. As an ex-functional programmer, we really love immutable data structures.

Introduction to Elm

Screen Shot 2015-06-08 at 7.55.52 AMElm is a very fast, functional typesafe reactive in-browser language that compiles to JavaScript. It’s one of the fastest languages, and is faster than Angular, Backbone and React. When you let the machine handle the synchronization, you get faster software. Prezi has adopted Elm to increase their code speed. When they use FRP in Prezi, they are using FRP with Elm.


Prezi is hosting MLOC.JS June 17-19 in Budapest. The challenge is to make really big applications — millions of lines of code — in JavaScript.

More From PubNub