You keep using that word “performance”

Every few months, indeed, it seems with ever increasing frequency, the topic of the performance of web technologies comes up.

Most recently, Drew Crawford’s much lauded, detailed piece “Why Mobile Web Apps are slow” has been doing the rounds. You knew it was just a matter of time before it was going to show up on the various blogs where “native apps (read iOS) are always better” holds sway.

Despite that, Crawford goes into laudable detail (and I mean that, I do think we need far more fact based discussion of these issues, rather than retreating to neutral corners and coming out swinging.) Crawford looks at the performance of JavaScript in comparison with “native” technologies, both in practice (using benchmarks like SunSpider) and in theory (considering why Garbage Collected languages like JavaScript, and Just In Time compiled languages like JavaScript, let alone Interpreted languages like JavaScript in webviews on iOS, where Safari’s JIT compiler ‘nitro’ isn’t available).

The conclusion is that the performance of JavaScript based apps is currently too slow for developing mobile apps. He cites the particular example of photo editing apps.

But Crawford’s position is really just a far better argued, more evidenced-based version of this comment on a blog post I wrote about performance 3 years ago

Performance: There’s just no getting around it. Compiled code (ObjC/​Java) is faster than JavaScript. Period. An argument can not be made to the contrary

Which is both true, and banal.

Developers never care about absolute performance, well, at least sensible developers. Yes, sufficient performance is necessary, as well captured in this recent article at Forbes magazine. Once that threshold of sufficient performance has been reached, there are myriad other critical considerations as to the tools, platforms and languages we use. Among them time to market, platform reach, development cost, maintainability, or in Luke Wroblewski’s case with Polar, the ability to avoid long frustrating delays waiting for AppStore approval.

And of course it’s worth observing that most likely the vast majority of our application’s execution doesn’t actually even happen in our JavaScript, so making the exclusive focus on this aspect of performance misguided. It happens in the browser’s internal CSS, DOM, compositing and other engines.

And much of it happens beneath even the browser level in exactly the same system-level APIs that native apps rely on. Among many examples are CSS animations, and transformations, which if done appropriately get handed off to the GPU, and don’t even touch the JavaScript engine.

Of particular pertinence to Crawford’s argument are CSS Filters, supported in Safari on iOS (but not as yet Android). Again, these bypass JavaScript entirely to apply filter effects directly to HTML and CSS based content, including of course images. Essentially, whatever you can do with Instagram filters (an image editing app I believe), you can do in the browser, with no need whatsoever for JavaScript to be involved.

Undoubtedly building applications with web technologies presents significant challenges regarding performance. But one thing I’ve learned time and again in the last 30 years is that Moore’s Law is a tide that lifts all boats. It’s like a crystal ball for developers.

All of which brings me back to a recent rant of mine, “not ready for primetime“. As technologies emerge, and mature, but before they are “ready for primetime” is precisely when they represent the most opportunity. Sure, you can complain about it being more work, and more of a challenge to get right. But it’s those out there solving the problems who’ll reap the rewards.

Bonus viewing

Want to learn more about making your JavaScript work as well as possible, see Web performance guru Stoyan Stefanov on JavaScript Performance Patterns at Web Directions South 2012.

One response to “You keep using that word “performance””:

  1. This ultimately makes me think of William Gibson’s comment that future is here but is not evenly distributed. Gibson clarified this comment by stating that new technology doesn’t ultimately have much impact until it approaches ubiquity in keeping with your comment that Moore’s Law is a tide lifting all boats.