On desktop computers web apps have come to dominate many application categories. They are easier to develop and deploy across multiple platforms and it’s possible to iterate much faster. A very large number of developers would like to be able to apply the same technologies and techniques on mobile devices but very few are able to do so successfully, particularly for mass market consumer apps. One of the most important reasons for this is performance. Resolving this issue is much more about politics than technology.
Are mobile web apps doomed to be slow?
Back in July, Drew Crawford wrote a blog post that got a lot of attention essentially claiming that JavaScript performance on mobile devices was simply too slow for serious apps and likely to stay that way for the foreseeable future. It showed, amongst other things, that the browser on the iPhone 4S was around four times slower than the slowest browsers capable of running Google docs real-time collaboration or Google Wave back in 2010. He claimed that ARM processors were not going to get faster rapidly enough to make a difference and JavaScript runtime improvements had stalled and were unlikely to make significant progress. Technically both of these points seem to have been proven wrong already. Apple just announced the iPhone 5S, with a processor twice as fast as the iPhone 5, which was in turn twice as fast as the iPhone 4S – so we have four times more raw CPU performance than we had just two years ago, theoretically enough to support 2010 desktop class browser performance. Also, Mozilla are working on asm.js, which uses a subset of JavaScript compiled ahead of time (AOT) and promises to enable apps to run in the browser at just 1.3 times slower than native performance – almost another four times speed increase versus the current five times slower than native performance of modern JIT compilers.
In addition to being at least partly incorrect this is also looking at a very narrow area of browser performance, a point well made in Sencha’s blog post in response. Across all vendors there are key performance areas where each is 10-40 times behind another. In reality, most of the major performance issues that prevent web apps from being competitive with native apps are related to graphics performance. Mobile device users have come to expect slick animated UIs which are only enabled by GPUs on the devices rather than, say, manipulating the DOM with JavaScript. Fortunately HTML5 and CSS3 provide several opportunities for GPU accelerated graphics with e.g. Canvas, CSS animations and WebGL. So, as mobile hardware and browser software continue to improve over the next couple of years competitive web apps should be just around the corner, shouldn’t they?
Platform wars and politics
With the technologies available or on the very near horizon today, plus improvements to mobile browsers across the major platforms, there’s almost no doubt that we could have competitive web app performance. The problem is that to get there requires platform providers and OEMs to adopt the technologies and implement the improvements – it’s not necessarily in their interests to do so.
Apple and Microsoft want users locked-in while Google wants them logged-in. Mozilla wants the open web everywhere but Google funds them. Opera recently gave up on writing their own browser core and use Google’s instead. That’s over-simplifying but fairly accurate. With other browser vendors attempting to prevent the user tracking that Google’s business model depends on (through default Do Not Track settings or third party cookie blocking) the best way to ensure users stay logged-in is to get them all using Chrome. This means they’re fighting a new browser war for control of the desktop web and taking that to the bulk of the mobile market through Android. In the process they are building several browser technologies to differentiate rather than standardise (e.g. they’ll prefer their own Native Client solution to asm.js).
At the same time Apple wants a great browsing experience but wants developers to build native apps rather than cross-platform web apps. As such they adopt most new web standards quickly but are very slow to include any that might enable high performance web apps – e.g. WebGL has been implemented since iOS 4.2 but only enabled for iAd, not in the browser, also Apple has famously not enabled their JIT compiler in the WebViews used by wrapped web apps* (needed to access native APIs) slowing their JavaScript performance by almost four times. Mozilla’s asm.js seems a very unlikely candidate for Apple to adopt anytime soon. Unless their new CEO makes a major change of strategy, Microsoft seem determined to follow the Apple model, although they might need first class web apps enough to accelerate their standards adoption.
A ray of light?
While there may be several classes of app for which mobile browsers are already good enough, for those hoping to develop all apps with web technologies, the news is not all bad. Although it seems unlikely to be possible to deliver a single solution with great performance everywhere, we might not be far from being able to deliver a good level of performance almost everywhere. Although Apple appear to have some strategic performance limitations, they also have some of the fastest hardware on the market. At the other end of the spectrum good Android browsers are reaching low end smartphones and the Firefox OS, also targeted at low cost devices, has an excellent web app environment. The other good news is that while we have real competition in the mobile market, browsers should keep getting better all round. We’re unlikely to see the return to stagnation of the Internet Explorer dominated early 2000’s.
* Apple do have a good security reason for doing this but they haven’t been in a hurry to resolve it either.
