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.
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?
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.