Facebook's new mostly-native iOS App has brought back the "HTML vs native" debate. I think the "answer" to this debate is fairly simple: Web apps might eventually dominate on mobile, but not yet... because there's still far too much work to be done in the OS's themselves.
If you're short on time, here's the basic idea:
Innovation in operating systems comes in waves. At the beginning of a totally new platform (minicomputers, mainframes, desktops, smartphones), the platforms themselves are so nascent that the operating system is key to unlocking the capabilities, so you need to be as close to the OS as possible to make the best apps.In the desktop world, it was the OS that needed to provide things as basic as multitasking, windowing user interfaces, device drivers, and network interfaces... because there was a time where THESE were the building blocks needed for breakthrough innovation in the application world: the first generation of office apps, browsers, games, etc. all used these capabilities directly through OS-level API's and libraries.
As OS innovation slowed down, and the underlying platform became more and more stable, the innovation moved upwards: towards the browser. Today, the desktop OS is basically just the infrastructure you need to launch a browser (hence the promise of projects like Chrome OS). [Side note: this happens in every industry... as once-complex products get commoditised, the innovation moves up the stack, e.g. re-assembling those commoditised pieces and building new things on top... that get eventually commoditised...]
On mobile, Android and iOS are adding huge new features and capabilities with each release. Whether it's integrating social apps (one-click Twitter sign-in), geofencing (enabling payment apps like Square, and all sorts of smart-reminder apps), or adding seamless cross-device sync (iCloud ... maybe), the pace of mobile OS change is way faster than on the desktop.
When there's tremendous innovation on the platforms themselves, the apps that deliver the best experience (that users will come to expect) need to be tied fairly closely to those platforms. With the rapid evolution of Android and iOS, building on a platform (the web) that's one-step removed from the OS isn't going to let developers build apps that are as capable and polished as native.
A huge shift: Beyond the phone
A smartphone today can talk to all sorts of other devices: TV remotes over WiFi, watches and headphones over Bluetooth, health-sensors and car stereos through dock connectors, and TVs over AirPlay. All this is beyond the reach of HTML apps. Browsers may some-day offer hooks to these capabilities, but by then the native apps will have captured the market and will be on to whatever new capabilities the OS's have exposed.
In a world where the phone connects to a constellation of other devices through all sorts of radios and protocols, web apps are at a significant disadvantage... which is a important, because this is one hot space in the next few years.
Will this change? Absolutely... At some point, the innovation on the core OS's will slow down, and HTML will be a great way to build apps... but with so many unexplored possibilities left (we've barely scratched the surface of what these sensor-packed, networked, always-with-you computers can do)... I wouldn't bet on this shift happening soon.
NB: Yes, there are super-simple apps that would be just fine as HTML5 apps, or HTML apps in a thin native wrapper... you might be trying to build just one of these apps. But if you're not, and your competition is native, you're at a disadvantage.
If you've got a little time, here're two more reasons the best apps will be native for some time to come:
Does your laptop ever get really hot, and start to spin up the fan? Whenever I notice this, it's invariably Chrome or Safari maxing out my CPU. Web-apps get a lot of latitude when it comes to resource consumption... as does anything, generally, that runs on a laptop. Unfortunately, to be able to get through a day of use, your phone has to be a lot more careful how it uses resources.
A lot of the mobile-OS-specific features like geofencing and background sync need to strike a balance between all-day battery life and great user-facing features. When iOS first let developers use geofencing, the power drain was enormous... more recently, it's become very reasonable... that kind of optimisation requires tight integration with the hardware (mostly WiFi, GPS, cellular radio) that neither web apps nor the web browser have access to. It's just one example, but there're many: mobile resource mangement is hard, and you need to be close to the hardware to do it well.
- Being able to move big binary chunks of data around (even, say, a photo-app) in DOM/JS land is hellish-slow.
- WebGL is cool, but not broadly implemented, and the kind of graphics performance a developer can get by writing straight OpenGL (taking advantage of sophisticated shader models on more recent devices) is astonishing (just play Real Racing 2 on a pair of iPhone 4S's, streaming split-screen graphics to a TV over WiFi!).
- CSS 3D is cool, but not broadly (consistently) implemented, and if you happen to composite things in the way the browser doesn't like, all that 3D acceleration dies, and you're back to super-slow (and power-consumptive) rendering on the CPU. So: want super-smooth graphics and transitions that render at 60fps? It's going to be a lot of work to get HTML+CSS to perform like native.