Adding a web page as an icon to the menu, which will launch the browser and some page (app) in it is not really an example of HTML(5) based environment - by that account you can claim that even Maemo 5 with web page 'widgets' on the desktop was moving in that direction. Heck, you could claim that Windows 95 was moving in that direction with .url files/shortcuts linked to a browser.

And the Quake example, while being impressive for the time, does scream - it's just a browser! Granted, the new concepts like Canvas, WebGL and so on made it possible to port a full-blown game engine into a browser-friendly variant, but it will never be able to reap the benefits of native, or at least as-close-as-possible-to-native development - when you do it the traditional way, you can actually talk directly to the graphics sub-system (or in worst case through 2 intermediaries - gfx toolkit and drivers) and tell it to draw something where you want it, how you want it, with blazing performance along the way. When you do it in a browser, you have about 10 layers your instruction has to pass through before the graphics chip sends something to the display. And the same situation is for any other hardware access.

On battery-operated devices this aspect is anything but negligible, you can use the Android platform as a prime example of how you end up needing dual-core CPUs just to handle the basics on a satisfactory level (which also means abysmal battery performance with not much room for improvement) whereas other, closer-to-native devices get away with half the hardware, or less, needed for the same performance. Case in point - my N900, with all its quirks and bugs, and almost 3 years old hardware, and anything but professional-level apps, runs smoother than most, even this year's Androids and their professional-grade apps I've tried. Even when it comes to HTML, comparing MicroB with the native Android browser on most Android devices - MicroB blows them away, and I'm talking only about the performance part.

And what if you want to create your own browser (for whatever reason) on a platform that's HTML5-based? You'd be essentially writing a browser inside of a browser. Browserception?

With that being said, I'm sure that the hardware will progress and given enough time it will be able to cope quite satisfactory with all those virtual layers between the software stack and the actual hardware, so eventually HTML5-based apps should be able to provide enough wiggle-room for most needs, just as with Java from 10 years ago and today. I don't think we're there, yet, but that's a whole other subject. What I the find most annoying in that concept is that you're essentially restricted to one language, one toolkit, one way to do things, with various conceptual limits that HTML5 brings.

As a developer, those things are more important to me than things like open-source kernel or OS components. As volt above said - I wouldn't mind running a Windows 8 on my device as long as it doesn't restrict me in a way how will I create and distribute my apps, or at least doesn't restrict me as much as - you will use HTML5 or GTFO. Sure, the more open - the better, you're less at a whim of the OS developer and you can actually fix the bugs the developer fails to acknowledge, or doesn't want to be bothered with, but that is not as important to me (and the vast majority of developers) as is the flexibility and as-little-restrictions-as-possible when it comes to developing for that platform.

When it comes to programming, there is a plethora of ways to skin the cat, and no tool is the best for all cases (and in some cases one and one tool only cannot do the job at all), which is why it is inherently wrong to restrict development to only one channel. Case in point, HTML is not even close to the best way to describe a layout (due to its top/down origins), and JavaScript is inherently difficult to manage, debug and reuse (due to its lack of extensive set of natives, strict typing and prototype-based OOP - some of which were changed only recently). Sure, it's easier to create an info page with some basic interactions in HTML/JS combo than it is, for example, in C++, but writing something more complex, for example a game engine or some face recognition software in HTML5 (even if it would provide direct access to the webcam's feed) is a daunting task to be taken only by enthusiasts to prove that it can be done at some level. Not to mention that you have to rewrite every single library, that has been brewing for decades, into JavaScript, if possible at all, just to use features that you're accustomed to. And that's only from development POV, performance is a whole other subject.

HTML5 suffers from the same problem that all previous iterations of HTML suffered - a slow mammoth that is W3C, that takes years, or even decades to push even the most basic improvements, and at least the same time browser developers to integrate those. JavaScript was stuck for more than a decade due to Ecma International failing to push the new specs for ECMAScript, and even those from 2 years ago are not on a satisfactory level + many browsers don't support the full set of those and most developers don't even know that the changes exist. For a comparison, you can check what Macromedia, and even mammoth-itself Adobe has done with ActionScript over the same time period, starting on the same grounds of ECMAScript 3 - today you can actually create and manage a moderately complex project in AS3, while using good programming practices and being fairly productive, the same cannot be said for JavaScript even in its latest iterations.

I personally don't mind having an option of developing close-to-native HTML5 apps, for many use cases it is the most optimal solution, but making it prime-and-only development option is just wrong. Qt is probably the best of both worlds when it comes to portability vs performance, which is why I condoned that direction (as long as there is alternative, of course), HTML5 is a step in a wrong direction.