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.

The Web, Documented

Every great software platform needs some essential ingredients: one or more programming languages, great tools such as editors, compilers and debuggers, frameworks and libraries that make things easier, an enthusiastic community that help each other out and good documentation that helps get the most of the platform. The web platform is probably the biggest, fastest growing and most ubiquitous platform in the (short) history of computing. And while it has many of these essential elements, there is one that was still lacking: official documentation.

Think about what you do when you have a question about HTML, CSS or JavaScript. There are probably a few sites you trust, a few printed books you keep close at hand, if you’re old-fashioned, but more times than not you just search what’s out there and see what comes up. It could be a well maintained, up to date, credible source, or it could be articles or blog posts that are out of date or just plain wrong.

And the web platform is not static! The browsers keep evolving and implement new functionality, specs keep getting updated, and new specs get proposed and implemented. Best practices evolve as well.

Since there’s no single, definitive resource to go to, there’s no way to know for sure, except through trial and error.

All of that is changing today. The W3C – in collaboration with Adobe, Apple, Facebook, Google, HP, Microsoft, Mozilla, Nokia, and Opera – is announcing the alpha release of Web Platform Docs, a new web destination that will become the definitive resource for all open web technologies. You can find the W3C press release here. The Web Platform Documentation (WPD) will include:

  • API documentation
  • Information on browser compatibility
  • Examples
  • Status of specifications

And the WPD project will be open and community driven, just like the web. WPD is built on top of MediaWiki, the same engine that powers Wikipedia — which means that anyone can contribute. The initial content is being provided by many of the stewards listed above, but anyone with knowledge, examples, snippets or other relevant information is welcomed and encouraged to contribute.

The stewards have been working incredibly hard on this project for a bit over a year, and I want to congratulate them on the launch today. We are very proud to be participating in this effort. This is the culmination of the effort to build this infrastructure, but in many ways this is also a first step. It is now up to the web community to help create and maintain the most comprehensive and authoritative reference for web technologies. So, go check it out and start contributing. Document the web!