Adobe Systems Incorporated

Are Mobile Web Apps Slow?

A recent blog post from Drew Crawford has generated many comments and tweets about the relative performance of web and native apps. Drew’s well-written post is notable for its thorough documentation.

So should we all pack our mobile web app work and go native? Well, no.

Though the article singles out JavaScript, it really dives into the trade-offs between garbage-collected languages – JavaScript, Java – with lower-level alternatives that require the developer to manage memory. For those applications that are extremely sensitive to the kind of unpredictable interruptions caused by garbage collection, Drew argues that they will always lag behind native implementations (or, rather, behind native implementations that manage their memory properly).

First, the performance of JavaScript needs to be put in perspective:  it is only a subset of the performance profile of most web apps. HTML, CSS, SVG and the network also consume CPU/GPU cycles. For some web apps, the layout and rendering of HTML/CSS/SVG consume the majority of CPU cycles (it is even possible to write a game without any JavaScript code albeit a limited one.) Not only does it mean garbage collection only affects a fraction of an application’s overall execution budget, but a large part of the platform can be optimized and improved for all apps. So JavaScript is only one portion of mobile web apps’s code and its strengths and shortcomings alike only affect that portion.

Web Platform

Figure 1: A web application’s CPU budget

One may argue that this does not matter: why would anyone ever want to use a language that is slower than native? Wouldn’t you always want the faster option?

As Drew’s article points out, productivity is also important to developers. Drew uses the example of hashmaps: while managed languages usually build those in, native apps either rely on harder-to-use versions or roll out their own. Thus a big motivation for using a language such as JavaScript is its ease of use and dynamic nature. While not perfect it remains a language that is more accessible to more people than native code. It also is the same language across many platforms and devices, while native code is inherently platform-specific. Trading off some performance (for a fraction of the application, as explained above) for broader reach is appealing for many applications.

In addition, a core motivation for using JavaScript is that it is part of the wider web platform and lets us leverage a very powerful native component: the browser engine. I think of JavaScript as the puppet master of the browser engine: a little bit of code can exercise a variety of powerful native features from CSS layout and restyling to hardware- accelerated animations.

Granted, there exist native libraries that provide similar graphical, animated or layout features to what browser engines offer (and more). However, no solution that I know of has the the flexibility and ubiquitous reach that the web platform brings to the table.

Finally, a web app is not just client code. At the very heart of the web is the concept of distribution, of content as well as code. A web app can leverage the web and distribute its computing needs. The collaborative 3D authoring application Lagoa is a shining example of that possibility, as it distributes computation-intensive work to the cloud, operations that even the most powerful client code could not handle as well. Web apps, by nature, have access to the flexibility of this powerful architecture.

Web apps are way past the hype phase and climbing up the slope of enlightenment. Articles grounded in hard data like Drew’s are certainly useful. But we need to be mindful about decisions we make and consider a web application’s overall context before making the jump to native, and forego the many benefits of the web architecture.

In some cases (e.g., highly computationally intensive game), native code may indeed be the appropriate answer. But in most cases, web apps demonstrate the way of the future, even though the ‘puppet master’ code will run slower than its native counterpart. Remember that this relative slowness is a trade-off for other important benefits, such as higher productivity and unparalleled reach.

8:10 AM Permalink