Skip to content →

Web vs native

imageWhen Steve Jobs first launched the iPhone in 2007, Apple’s perception of where the smartphone application market would move was in the direction of web applications. The reasons for this are obvious: people are familiar with how to build web pages and applications, and it simplifies application delivery.

Yet in under a year, Apple changed course, shifting the focus of iPhone development from web applications to building native applications custom-built (by definition) for the iPhone’s operating system and hardware. While I suspect part of the reason this was done was to lock-in developers, the main reason was certainly the inadequacy of available browser/web technology. While we can debate the former, the latter is just plain obvious. In 2007, the state of web development was relatively primitive relative to today. There was no credible HTML5 support. Javascript performance was paltry. There was no real way for web applications to access local resources/hardware capabilities. Simply put, it was probably too difficult for Apple to kludge together an application development platform based solely on open web technologies which would get the sort of performance and functionality Apple wanted.

But, that was four years ago, and web technology has come a long way. Combine that with the tech commentator-sphere’s obsession with hyping up a rivalry between “native vs HTML5 app development”, and it begs the question: will the future of application development be HTML5 applications or native?

There are a lot of “moving parts” in a question like this, but I believe the question itself is a red herring. Enhancements to browser performance and the new capabilities that HTML5 will bring like offline storage, a canvas for direct graphic manipulation, and tools to access the file system, mean, at least to this tech blogger, that “HTML5 applications” are not distinct from native applications at all, they are simply native applications that you access through the internet. Its not a different technology vector – it’s just a different form of delivery.

Critics of this idea may cite that the performance and interface capabilities of browser-based applications lag far behind those of “traditional” native applications, and thus they will always be distinct. And, as of today, they are correct. However, this discounts a few things:

  • Browser performance and browser-based application design are improving at a rapid rate, in no small part because of the combination of competition between different browsers and the fact that much of the code for these browsers is open source. There will probably always be a gap between browser-based apps and native, but I believe this gap will continue to narrow to the point where, for many applications, it simply won’t be a deal-breaker anymore.
  • History shows that cross-platform portability and ease of development can trump performance gaps. Once upon a time, all developers worth their salt coded in low level machine language. But this was a nightmare – it was difficult to do simple things like showing text on a screen, and the code written only worked on specific chips and operating systems and hardware configurations. I learned C which helped to abstract a lot of that away, and, keeping with the trend of moving towards more portability and abstraction, the mobile/web developers of today develop with tools (Python, Objective C, Ruby, Java, Javascript, etc) which make C look pretty low-level and hard to work with. Each level of abstraction adds a performance penalty, but that has hardly stopped developers from embracing them, and I feel the same will be true of “HTML5”.
  • Huge platform economic advantages. There are three huge advantages today to HTML5 development over “traditional native app development”. The first is the ability to have essentially the same application run across any device which supports a browser. Granted, there are performance and user experience issues with this approach, but when you’re a startup or even a corporate project with limited resources, being able to get wide distribution for earlier products is a huge advantage. The second is that HTML5 as a platform lacks the control/economic baggage that iOS and even Android have where distribution is controlled and “taxed” (30% to Apple/Google for an app download, 30% cut of digital goods purchases). I mean, what other reason does Amazon have to move its Kindle application off of the iOS native path and into HTML5 territory? The third is that web applications do not require the latest and greatest hardware to perform amazing feats. Because these apps are fundamentally browser-based, using the internet to connect to a server-based/cloud-based application allows even “dumb devices” to do amazing things by outsourcing some of that work to another system. The combination of these three makes it easier to build new applications and services and make money off of them – which will ultimately lead to more and better applications and services for the “HTML5 ecosystem.”

Given Google’s strategic interest in the web as an open development platform, its no small wonder that they have pushed this concept the furthest. Not only are they working on a project called Native Client to let users achieve “native performance” with the browser, they’ve built an entire operating system centered entirely around the browser, Chrome OS, and were the first to build a major web application store, the Chrome Web Store to help with application discovery.

While it remains to be seen if any of these initiatives will end up successful, this is definitely a compelling view of how the technology ecosystem evolves, and, putting on my forward-thinking cap on, I would not be surprised if:

  1. The major operating systems became more ChromeOS-like over time. Mac OS’s dashboard widgets and Windows 7’s gadgets are already basically HTML5 mini-apps, and Microsoft has publicly stated that Windows 8 will support HTML5-based application development. I think this is a sign of things to come as the web platform evolves and matures.
  2. Continued focus on browser performance may lead to new devices/browsers focused on HTML5 applications. In the 1990s/2000s, there was a ton of attention focused on building Java accelerators in hardware/chips and software platforms who’s main function was to run Java. While Java did not take over the world the way its supporters had thought, I wouldn’t be surprised to see a similar explosion just over the horizon focused on HTML5/Javascript performance – maybe even HTML5 optimized chips/accelerators, additional ChromeOS-like platforms, and potentially browsers optimized to run just HTML5 games or enterprise applications?
  3. Web application discovery will become far more important. The one big weakness as it stands today for HTML5 is application discovery. Its still far easier to discover a native mobile app using the iTunes App Store or the Android Market than it is to find a good HTML5 app. But, as platform matures and the platform economics shift, new application stores/recommendation engines/syndication platforms will become increasingly critical.

I can’t wait :-).

(Image credit – iPhone SDK)

Published in Blog

  • This is a good alternative opinion, based on what users want rather than what techies want: http://mattgemmell.com/2011/07/22/apps-vs-the-web/

  • Do you use Windows gadgets?

  • Ben

    This may just be me (and we’re just crystal-ball gazing so I guess we’ll let history decide), but I think economics win out in the longer-term: solutions will evolve to address (although not necessarily 100%) pain points like the one he calls out as developers/platforms embrace new paradigms because of their economic interests.

  • Ben

    No — 75% of what I do is in Chrome 🙂

  • Ben

    No, the vast majority of what I do is in the browser and I never bothered to figure out how to use it 🙂

    That may change with the new WinPhone7-style interface on Win8, but we’ll see

  • Ben

    No, the vast majority of what I do is in the browser and I never bothered to figure out how to use it :)That may change with the new WinPhone7-style interface on Win8, but we’ll see

  • In 20 years definitely.

    The big question I have for you, is when do you think the line will be blurred between native apps and HTML5 apps.

  • Ah yeah, I don’t think desktop widgets (on both OS X and Windows) are all that big of a deal on the desktop anymore. At least I haven’t seen anyone use it for much more than looking at current weather conditions.

  • I think when cellular network data speeds start approaching consistent rates matching what native apps use when reading/writing off a local disk (varying per app).

  • Ben

    I disagree. You’re making the assumption that a webapp has to be pound-for-pound equivalent to a native application — I don’t think that’s true because developers will come up with alternative back-end processing schemes to take care of that (doing some of it locally vs doing some of it in the cloud) — a bad but illustrative example: when you run Salesforce, you don’t need to host your company’s entire CRM database on your computer and search it/write to it — so even though you have a web-speed latency issue, you still can get complex BI visualization/database operations with the webapp. Intelligent batching/use of local processing can go pretty far. 

    I think the two real bottlenecks (although they are fairly intertwined) are: 
    (a) when browser performance gets “good enough” that latency/lag from using local UI and local graphics is not significantly noticeable (doesn’t have to catch up completely with native but “good enough”). Given what we’ve seen in advances in browser performance, I think we’ll see that happen in the next 2-3 years.
    (b) wider support for local storage/processing APIs — so that you can credibly do the work in the browser; this is slower than I had thought (Google only now has started rolling out Offline Gmail and Offline Google Docs and they’re not great) — so I’d forecast next 3-4 years

    Again, I’m going to reiterate — to me, there is no real difference between a native app and a next-gen webapp — its purely a question of delivery and the properties of the delivery vehicle; the “webapp” delivery vehicle today still has major work to do, but longer term, I think of this as just a new means of distribution, much like Steam, OnLive, and Gaikai are just new ways to deliver the same game

  • Ben

    Replied below to Joe 🙂

  • That’s a good point–I didn’t think about business apps. Do you think this would be the same for graphic/data intensive apps like gaming?

  • Ben

    I think with things like HTML5 Canvas, WebGL, and Google’s Native Client you are going to see a lot of local processing and graphics performance (because Javascript is basically run in the browser); this makes it easier for you to handle things that need to be handled in the cloud in the cloud (i.e. accessing a business database or storing the next level of a game in the cloud) but do a lot of the UI/graphics stuff locally — so I actually think games are a great fit for the browser model

    I think the bigger issue is with things that require a ton of processing power on large files (i.e. editing multimedia/photos, CAD) — its harder for me to see a HTML5-based competitor to Photoshop/Premiere because the web environment will have a performance disadvantage *and* not really be able to rely on the cloud as easily to cover this up. 

  • Whenever I play online games, they always seem to be designed so that the majority of the game is downloaded locally before playing. Are you saying with things like Canvas, WebGL, etc, that shouldn’t need to be necessary?

    If you’re referring to the time required to transfer “large files” between local and cloud, I agree. But I’ve found that the apps themselves can be comparable. Take Sumo Paint for example — http://www.sumopaint.com/

  • Ben

    Re: Sumopaint: I need to try it out — but can you do all the crazy filters/things that you can on Photoshop?

    Re: game question: I have no idea 🙂

  • It definitely can’t do *all* the crazy things, but I’m not so sure if it’s because it’s not capable, or if there’s just a lack of development resources.

    (I like seeing the width of these replies get narrower and narrower. Reminds me of Google Wave.)

  • Ben

    Yeah me too — my layout doesn’t leave that much space so I’m curious how much deeper this gets…

  • Speaking of native vs web, Plex looks to be putting more emphasis on their media server’s web app cross-platform compatibility: http://brian.plexapp.com/2011/09/12/web-manager-an-introduction/

  • Pingback: Chrome Remote Desktop()

  • Pingback: Where do the devices fit?()

  • Pingback: A Few Months with the Chromebook()

  • Pingback: Why Comparing Google Drive to Dropbox is Missing the Point()

%d bloggers like this: