Program to where the performance puck is going to be, not where it has been

In the year of our lord, 2013, the thought of ARM-powered phones running the full web experience with JavaScript as fast as x86-powered desktops was a laughable pipe dream. Way back in those olden days, some three years ago, the iPhone 5 was off by about a factor of 10. It seemed impossible that this would change any time soon.

But it did. The new iPhone 7 runs JavaScript, as measured by the JetStream benchmark, FASTER than the fastest of the (non-pro/air) MacBooks you can buy today. The best 5K iMac with a 4Ghz i7 processor is now less than twice as fast as the iPhone 7 on the same test. The ARM CPUs are improving at an absolutely insane pace. Moore might have taken a seat with desktop CPUs, but he’s sprinting faster than ever on mobile.


The pace of progress have embarrassed many predictions of the future, but this specific example is still astounding. Three years ago is not that long!! In that time we went from “off by an order of magnitude” to “faster than most laptops”.

What’s even more important than the benchmarks, though, is how the consequences of this incredible leap of performance alters not only what’s possible on a phone, but what the common strategy should be.

Here’s a money quote from 2013:

Just to be clear: is possible to do real-time collaboration on on a mobile device. It just isn’t possible to do it in JavaScript. The performance gap between native and web apps is comparable to the performance gap between FireFox and IE8, which is too large a gap for serious work.

That gap is gone. So I suppose that means the iPhone 7 is now officially certified for Serious Work™ 😜.

Here’s what funny. In 2013, we built an iPhone app for our collaboration tool Basecamp using JavaScript and the web in a hybrid combo. We do have a lot of fun at work, but I’d like to think that the result were Pretty Serious none the less.

Using the mobile web as the core of our native apps was a gamble at that time. The institutional scar from Facebook abandoning HTML5 for pure native in 2012 was still fresh in the memory of most working at the intersection of the web and native. And to be fair, there were indeed some tradeoffs. Things clearly weren’t as fast as native, they were just fast enough.

That was an order of magnitude in performance ago! Now the performance of this strategy is not just fast enough to be passable, it’s more than plenty fast enough to be awesome. Or rather, a non-issue.

Granted, the performance of the iPhone 7 is a future that’s not yet widely distributed. Android in particular has a lot of catching up to do, but even at much less performance, they too are clearly within the habitable zone of performance. That place where other things just matter far more.

Now I’m not saying going hybrid carries no tradeoffs. There are still some interactions that occasionally feel less than native, and thus still lack that last tiny bit of polish. And there are clearly still applications, like high-end 3D games, that need every ounce of performance they can get. But with the performance afforded us today, the spectrum of applications that can be knock-it-out-of-the-park awesome using a hybrid web/native combination is very large indeed. And much, much larger than it was in 2013 when we forged ahead.

The productivity advantages of developing a multi-platform service using the hybrid approach are simply astounding. There’s simply no way we could have built Basecamp 3 in 18 months to cover the web for desktops, web for mobile, native iOS, native Android, and email without a hybrid and majestic monolith. Not without ballooning our development teams dramatically, anyway. That’s five platforms covering some 200+ separate screens of functionality.

This feels similar in many ways to the situation I outlined in Ruby has been fast enough for 13 years. When performance improves, it’s not just that the things we already do get faster. It’s that we can do new things, in new ways. Ways that would have seemed impossibly slow before. Ways that make people who had to do the hard work of fitting a full computer demo into 4Kb cry, but that none the less lifts the productivity of the masses.

It also reminds me of an anecdote from John Carmack, the legendary programmer of Doom and Quake. He talked about how when he was working on a new game, he had to program not for the performance of today, but for the performance of three years in the future, when his game would be finished. If he programmed for today, it would look dated when it launched. Doom and Quake always looked amazing because of this.

Think of that when starting a new app today. Are you programming for the state of the world as it looked in 2013? Or 2016? Or 2018? Program to where the performance puck is going to be, not where it’s been.


If you want to checkout how a hybrid app can feel, Basecamp 3 has some great examples in the iOS app and Android app. Both are sitting pretty with a 4.5/5.0 rating from hundreds and hundreds of ratings.


Enjoy this post? Get SvN updates delivered straight to your inbox.

No spam, no fluff — just one email every week with the latest posts.

Leave a Reply

Your email address will not be published. Required fields are marked *