Today we updated the Prezi player, which you can use to view and present your prezis. It is a huge change, completely moving the underlying technology from Flash to Javascript. Hopefully, nobody notices. It has been the biggest migration project of our working-lives, and has taken us almost four years to complete. With its release, I’m pretty sure that Prezi is among the top 1% of the most complex JavaScript applications on the net.

In celebration of such a time-consuming and difficult project, I have composed an indulgent and long blogpost that attempts to address multiple audiences. Because I am a sympathetic person, I have included large readable headlines for those with limited time or interest. Those with time to kill and a healthy amount of curiosity should scroll down slowly and read the whole thing. #oldschool

A topical opening comparison

(which might help also boost our SEO traffic to this post)

The World Cup is upon us. At its worst, the competition is a tribal celebration of nationalism centered around a game I don’t care for. At best, its a great excuse to drink with fantastic Prezi people from twenty-four countries in glorious late evening Budapest sunshine (we’re hiring). During one of these evenings, I heard a sentence from an English colleague that intrigued me:

“You can tell when the referee has done well if at the end of the game you didn’t notice him.”

A top-class referee will on average run up to 12 miles during a 90-minute match. That’s five miles more than most players, who are often half the age of a typical official. Imagine working so hard in order to go unnoticed while those around you revel in glory. For a group of Prezi engineers, no such imagination is required. Over the last 5 years, I have essentially been asking some of our top people to do the exact same thing–work really hard in order to go completely unnoticed. This is counter-intuitive for a company that’s all about making your ideas stand out, and having people take notice of you. But for the release of our JS Viewer, our most significant technological advancement since our public release, the key metric for the team is that most people don’t notice a thing. Actually, that’s not quite true, it’d be perfect if some people thought, “Oh Prezi seems a bit smoother than before”.

You can judge the results for yourself, but after having spent the past five years working on this release, I’m now delighted to say that we have a JavaScript player that works from your browser.

The part where I thank people and comment on the current state of JavaScript vs Flash

Flash, Dzso, Adam, Vuji, Loci, Sipi, Gazso, Lacika, Peti, Mate, Zozo, Greg, Zsol, Kalman, Rishabh, Matyi, Gida, Simone, Balint, Attila, Jeremy, Czapo, Andras, Csaba, Omar, Andras! Good job trying something new and different — I know you haven’t done this before.

I am extremely grateful to the people who worked on this release. Over the last half a decade, a total of fifteen dedicated and very skilled engineers have worked on this JS player at one point or another. But as important as they are, I cannot neglect to mention the many thousands more who have been waiting for this release. In April of 2010, the number of anticipators grew significantly when Steve Jobs declared the death of Flash. Before he did this, HTML5, JavaScript, etc (the names and trends keep changing, and I gave up tracking which one is cool right now) were pretty much just for hipster coders and anyone who liked to think they were better than the mainstream with no interest in producing usable results. But with Steve’s open letter, all of a sudden it became an industry-must to dump Flash. Sadly, Adobe’s technology has outlived the prophet of its demise, but now, it might just be (finally) dying. Am I proud that Prezi is part of this “revolution”? Yes. It’s great if everyone thinks we are a sexy company because we work with the coolest technology, even if most of those people don’t honestly know what the difference is. But I’m actually more concerned with the tangible benefits (read more about those below) this gives the people who use Prezi every day. And I’m amazingly proud of how we delivered these results because it was incredibly hard.

The bit where I detail the benefits

Flash’s competition has reached a stage where it’s actually going to give us a real difference. First, it’s faster, which for Prezi is extremely important. When you’re zooming around a 2.5D canvas, it’s important that you move slowly from one point to the next.

In Minority Report, Tom Cruise didn’t have to wait while the screen jerked around. Instead he swipes and glides around his interface, and people expect the same fluidity from Prezi. The move to JavaScript isn’t going to bring us one step closer to Pre-crime, but this version should make everyone’s presentations smoother. Also, while Tom looks great with those gloves on, I don’t think that giant screen is particularly easy to transport and herein lies the true potential of the technology shift: we believe this is going to lead to a seamless Prezi experience across all devices.

The part where I complain about how life isn’t fair.

The great thing about Prezi is that it zooms. Zooming is unequivocally awesome. Why? Because it illustrates relationships. Turns out that is important; if you want audience to understand and remember your message, which most people do, showing people your idea AND how it connects with your story at large by zooming from A to B, (or zooming out to reveal both A and B) increases your onstage effectiveness. This is why companies like the Crunch Fitness Franchise claim to have closed 30% more sales since switching to Prezi.

The difficult thing about Prezi is that it zooms. Zooming makes everything exponentially harder, for engineers. Let’s say I was working for a generic photo sharing platform. I should imagine that one of my main problems is making sure a photo looks as good on a 5-inch screen as it does on a 12-inch one. Prezi engineers have the same problem, and then the user asks to zoom in. In less than a second, we now have to present the same content from a different distance, and all the time make sure the projected image remains rich, sharp, and focused. And we have to do this while multiple people simultaneously view the content from various points around the globe using different browsers and operating systems. So if you’re asking how come SlideShare managed to release an HTML5 version in 2011 and we’re only doing it now in 2014, this is my answer: We zoom, they don’t.

More detail — WARNING: Probably only interesting to geeks.

The problem we had to solve: different browsers render texts slightly differently

Let’s take the example of font rendering. Did you know that different browsers use different font rendering algorithms? At first glance, nobody recognizes the minor differences between one and the other. When you zoom in on the text those differences get amplified. As an extra challenge, we also have a native mobile version that must be pixel-perfectly identical to the JS version. So we ended up creating our very own text renderer. Just like Flash did 15 years ago.

Visual productivity tools are hard

Animation performance is crucial for anyone using prezi. Nobody wants jerky prezis. So we had two engineers fine-tune the rendering of large amounts of content to the canvas in the last four months. Yes, we are using Canvas. Bitmap caching of small but complicated drawings had the biggest impact on the median frame rate. Thanks to Flash, we already had some experience in optimizing the speed of rendering on a canvas-like platform.

“The key learning for us has been that dedication, hard work, and optimization of how you are using Canvas can yield hard performance animation even in HTML5.”

One of the charts we use to monitor the speed of rendering.

The first steps are always: set up and automate the right measurements, and then monitor the speed.

Prezi also needs high performance drawing of vector graphics. Nobody wants a pixelated chart or logo, nobody. Flash was really good at vector graphics, JS is not as good (we know about SVG; if you want to know why SVG was not the best solution for us, feel free to invite someone from the team to come and talk at your conference or meetup.). So we ended up creating our own vector graphics renderer based on Shumway (yes, we are going to publish all of our improvements, Mozilla will merge soon).

The biggest challenge was adding clipping to Shumway. I guess nobody thought about how Shumway could be used to render small parts of huge vector graphic files (like PDFs). But our users do like to zoom in…

Large JS codebases are hard

Besides zooming there was one other big challenge: We have a pretty enormous codebase compared to the average web-based JS application. If you don’t agree that a large codebase can be challenging, then read this TechCrunch article.

When working on a large code base, we prefer typesystems and compilers. That’s why we write the majority of our code in Haxe. We are big Haxe fans. For your curiosity: we are also experimenting with Typescript. And yes, we are using Emscripten to compile some code of the text renderer from C. Regardless, we are a language agnostic group of people, so we support any X-to-JS language.

“We invested a huge amount of engineering time in building our own toolset, something I really recommend to all teams working on large applications.”

We are big fan of microcomponents (we built the app from 18 independent components), automatization, and devops like deployment.

We created and open-sourced our own module system and build system based on Gradle. Auto-scaled Jenkins nodes are running the tests on 7 browsers after every commit. We automatically publish all versions to the production system and make them available for everyone. Of course, fine grained feature switches make selective rolling out possible. The whole tooling system is build to increase developer happiness. And could make you happier than improving the tool used by millions. That’s why it’s important to lower the time it takes from changing the code on a local machine to making it available for people to use. At Prezi, this takes only 15 minutes.

So why only in 2014?

We launched Prezi in 2009? iPhone without Flash appeared in 2010. Why didn’t we release a JS version earlier?

It was not our key focus until 2013. We have had a native iOS version since 2011 and our users seems to be happy with Flash. Still sounds like bullshit? Here’s the other reason:

We tried two really bad approaches before this project.

The vanialla HTML5 version using DOM + CSS3. It never went to production.

First we tried to use vanilla HTML5, DOM + CSS3 animations. Cool, huh? Nope. Not cool. We never could turn this version into a high-quality enough product. So we shifted the focus to a native iOS version.

Our second project aimed at having a full multi-platform codebase: generating JavaScript and native apps from the same codebase. Why? Because we always wanted to have 100% pixel-perfect identical prezis on every platform. It took us almost a year to realize that the goal is important but our solution was a really bad idea.

Today the JavaScript and native teams are totally separated. Both use their own toolsets, processes and environments. The key learning?

“In the long-term, using a popular platform’s standard processes and toolset results in a higher quality product and happier engineers. Don’t fantasize about using an obscure toolchain to write-once a small core codebase. Engineers actually love to write code. “

For managers

If you’re this far in, you’re either a dedicated reader, or someone who scans through the headings for the parts you’re interested in. Either way, I’ll get to the point.

In all honesty, we have been working on this for a long time. As I alluded to, we flirted with the idea since 2010. During this time, we overcame the various difficulties by being what I call “truly agile”. I like to use this combination of words because it makes me feel like some kind of influential thought-leader. In reality, it means some quite simple adjustments to the way you work. These are (in order of importance):

Generate enough money to hire people. Hire the right people. Give them the right infrastructure and culture to succeed. Trust them. Dedicate them to one task (in this case the technology shift). Give them clear accountability. Always have an “almost ready” version. This will force them to think about what they have to do instead of what they’ve already done.

There’s also something to be said for ensuring you learn from mistakes, but this is part of hiring the right people dedicated to the right task working under the right culture.

For journalists

I could deny that we’re working to create a JavaScript/HTML5 editor for Prezi, but I won’t. You only need take a look at our jobs page (did I mention we’re hiring), and you can see this is what we’re working on. If you’ve read the rest of this piece, you’ll know how hard it was to get this far (if you didn’t, scroll up), and as such I won’t be promising when this will happen, just that I’m confident that we are on the right track to getting there.