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 “Test The Web Forward” Movement: engaging the community to move towards a better Web

What makes a better Web?

Features are certainly important and there are multiple improvements to the web platform in the woks, for example the “SysApps” working group, the Linked Data effort or the new functionality added to CSS (such as CSS Regions and CSS Filter Effects which Adobe is actively contributing to).

However, while features are obviously key to a better, richer web, they are one of several elements which, when combined, deliver an enhanced web experience.

One is proper implementation of the web standards. For the web platform to be reliable, it is very important that implementations follow the various standards properly and reliably. The specifications define what browsers and other web components should do, but we need to make sure that implementations stick to the specification, from the most common features and down to the most obscure corner cases.
Tightly related to proper implementation is interoperability. It is possible, and this has happened many times in the past, to have standards, pretty solid implementations but poor interoperability because of various interpretation of the specifications by implementors. For example, in the early days of the Web, there were a lot of discrepancies between implementations of the Cascading Stylesheets specification. Interoperability issues are the plague of web developers as it either neuters the use of features (because the feature is not guaranteed to work in a consistent way across browsers for example) or weakens its appeal (because it will only be available to a fraction of the end-users).

Testing is the key to insure proper implementation and address interoperability issues. And great testing is the recipe for great implementations and awesome interoperability.  In the realm of web standards, testing comes in the form of specification test suite which are used to validate that a specification is implementable.

The testing challenge

Unfortunately, writing tests is fraught with difficulties. It requires dedication, expertise, persistence and careful attention to details. In addition, it is important to have the widest test coverage as possible to ensure testing depth and the desired implementation quality and interoperability. Historically, it has sometimes been difficult for implementors of particular specifications and working groups defining specifications to create test suites that are as deep as they would like. This issue has been at the root of implementation, interoperability and adoption difficulties for new standards.

Test the Web Forward

Move the Web Forward” is a grass roots movement that engages the community and challenges those passionate about the web to act on their desire for a better web. “Test the Web Forward” is exactly in that spirit: there are implementation or interoperability issues which the community of developers is painfully aware of, let’s try to enable developers to do something about this and contribute to better test suites which are an excellent way to improve the web.

Following that train of thought, Adobe and others in the community such as Microsoft, Mozilla, Google, W3C and Facebook have started to engage the community to contribute to web standards tests with a series of events call “Test the Web Forward”. To date, three events have been held: one in San Francisco (in June), one in Beijing (in October) and one in Paris (also in October). So far, about 700 new tests have been created that will be contributed towards web standards test suites. The events are typically held over a day and a half. During the first half day, experts from the standards working group (such as the CSS or SVG working groups in W3C) give short presentations about standards testing frameworks, browser bug filing and other topics related to reporting issues, isolating problems or ready a specification carefully to identify testable portions. The full day that follows is dedicated to ‘hacking tests’ in groups where the web developers work with the experts to write new tests, convert tests that may need reformatting or review existing tests so that they can be integrated into official test suites.

The following blog posts relate the events as they happened in San Francisco, Beijing  and Paris and this video gives a good description of what the events are about, how they foster interest in testing the web, generate good discussions, suggestions and produce concrete results.

Next Steps

While the Test the Web Forward events are fun, there is a desire to find ways to keep engaging between events and at the recent W3C Technical Plenary meeting in Lyon, France, Adobe suggested concrete ways for interested web developers to keep contributing. There are also very interesting discussions about how the “Test The Web Forward” movement relates to the Web Platform Docs effort and a lot of suggestions that the two efforts should be closely related.

It is very encouraging and exciting to see the web community interested in contributing to a better web and offer time and expertise in efforts such as TestTWF. Our team at Adobe will continue working on this effort and with our partners to help it grow and further demonstrate its efficacy to help build a better web.

So if you and your team are passionate about the web, want to help move it forward please follow #TestTWF on Twitter and visit to learn about upcoming events and new developments around this initiative!