The long truth about short web apps

The slow truth about web apps

For years one of the biggest knocks on mobile web apps was performance -- they just never felt as fast or as fluid as native apps. Yet proponents of web apps have begged to differ, and sought to show that web apps could, if not today then one day, prove good enough for general purpose use. Tired of the subjective arguments, Drew Crawford has tried to present an objective analysis on Sealed Abstract:

But the real elephant in the room here is that in all these articles on this subject, rarely does anyone actually quantify how slow JS is or provide any sort of actually useful standard of comparison. (You know… slow relative to what?) To correct this, I will develop, in this article, not just one useful equivalency for JavaScript performance–but three of them. So I'm not only going to argue the "traditional hymns" of "wa wa JS is slow for arbitrary case", but I'm going to quantify exactly how slow it is, and compare it to a wide variety of things in your real-life programming experience so that, when you are faced with your own platform decision, you can do your own back-of-the-napkin math on whether or not JavaScript is feasible for solving your own particular problem.

We spent some time debating this topic on Talk Mobile as well. As someone who distinctly remembers it taking nearly half a minute for the webOS calendar to open on my Palm Pre Plus, and the early generation of sweet iPhone apps it's almost inconceivable to me that anyone would argue web apps, cloud-based or local, could come anywhere near native performance. As to whether they could eventually become as fast, one day, that seems like an impossible argument for anyone to make primarily because native apps show no sign of slowing down any time soon.

What can be argued, I think, is that in some cases web apps make sense despite their performance. Speed and smoothness are important elements of an app, but they're only two elements, and in some cases other ones might take precedence. The idea of an informed trade-off makes a lot more sense to me than simply an HTML5 dream and wishing it so. An app you have to access from any device, any where, for example, makes availability more important than speed, and that's something web apps excel at.

Anyway, at nearly 10K words, you might want to block out some time from Crawford's piece, or InstaPockAbility it for when you do have time. If the subject of web apps vs. native code interests you, it's well worth it.

Source: Sealed Abstract via Daring Fireball

Have something to say about this story? Share your comments below! Need help with something else? Submit your question!

Rene Ritchie

Editor-in-Chief of iMore, co-host of Iterate, Debug, Review, Vector, and MacBreak Weekly podcasts. Cook, grappler, photon wrangler. Follow him on Twitter and Google+.

More Posts

 

-
loading...
-
loading...
-
loading...
-
loading...

← Previously

OS X Mavericks Preview: Maps help you find your way, integrates with iOS

Next up →

AT&T want to buy Leap Wireless, get all your Cricket iPhones

Reader comments

The long truth about short web apps

8 Comments

Forcast.io is amazing, but it's absolutely not mistakable for native. It is, however, ubiquitous via the web, which is a fine trade-off.

Maybe realizing web apps don't have to compete on performance is the first step to figuring out where they can best native?

With web apps, the benefit is cross platform convenience. That being said, if there's a choice, I always go with real desktop apps.

An excellent read! Even if you aren't a proficient programmer this article would be interesting for you to read. Very good language and on-the-point.