A similar post in 1999 would have been titled:
"Why native development sucks and Java Swing rocks: Porting to Mac OS 9"
Edit: My last sentence may or may not have somewhat proved what the grand parent was trying to say.
However, what we should be doing is making the browser nothing more than an x64 VM. That way, all of the underlying OS calls could be wrapped in an OS-independent way, and for those that are specific to a particular platform, a generic way to access host-specific features.
Because each generic OS call maps into a real OS call, every call can undergo a security check. We can use ACLs or web-based authentication, or distributed authentication, etc. Or perhaps none at all for something like "give me the current date".
Each "app" (and, they would be real apps!) would run inside a separate VM. Communications to other parts of the system - for example, to another running app - would be done via messages (or some other method that could also be authenticated).
Now, some of the beauty of this scheme is that existing apps could run without modification on this platform because the VM would trap all the "real" OS calls and authenticate them, validate them, etc. As in unix, I/O would get mapped to arbitrary streams; for example, if the existing app was console-based and did printf() and scanf(), those would be mapped to the user's keyboard and output of the VM on the screen.
I wrote a much longer version of this and sent it to Alan Kay, but I must not have his "real" email, as I've gotten no reply. (Or maybe I'm nuts...)
What is astonishing to me is that if one of the "big guys" (Google, Yahoo, Microsoft, ???) were to build this "Web-Enabled Application Platform" (WEAP sigh...) [perhaps using Xen] it would TAKE OVER the entire OS market. The only "program" a user would run (at least what was visible to her) would be WEAP.
I've never seen this idea written up anywhere else, so I hereby put this into the Public Domain.
This concept needs much more detail before doing a reference implementation, and I definitely haven't considered every corner case. But, given the exceedingly poor state of "the web" these days, something like this will (clearly!) eventually happen.
ARGUMENT: Native is ALWAYS faster than HTML5
MY EXPERIENCE: So what? Speed depends on what you're trying to do and how. Animating a loading icon for UITableView will not spin any faster than a loading.gif in HTML5 view. Similarly, being able to slide an entire UIView to the side at 120fps doesn't mean using CSS webkit-transform: translate3d(x,y,z) at 60fps looks any worse to the user. Speed matters when you're (a) crunching data and (b) updating graphics. If you're building HTML5 apps that need some serious data crunching, you can do that part in C and call from your code via a plugin. And unless you're making 2.5D-3D games, you don't HAVE to go native. And then you're most likely coding in C/Lua anyway. For most of the apps out there, raw processor speed isn't a necessity - responsive UI is.
ARGUMENT: HTML5 is ALWAYS easier/faster to code than Native
MY EXPERIENCE: Sometimes yes, sometimes no. It depends on your experience with all the available technologies. I can code views in HTML5 using CoffeeScript/Less/Bootstrap/Backbone relatively fast. I can code models/controllers in ObjC relatively fast. Views in ObjC get complicated and models/controllers in CoffeeScript/JS get complicated. If you have a UI-heavy app and you can code UI fast, go with HTML5. If you feel comfortable validating user data input in ObjC and have tons of forms, go with ObjC. There is no silver bullet.
ARGUMENT: HTML5 apps ALWAYS look bad/uncanny vs. Native ALWAYS looks boring
MY EXPERIENCE: Poorly designed apps look bad/uncanny/boring. I have to admit that using jQuery Mobile and similar libraries without doing any customization/tweaking pushes your HTML5 app into the uncanny valley. And unless you skin the Native UI, your app will look no different than the phone's native contacts list. My preference is to (a) Not use libraries that make fake native-looking-UI when doing HTML5 (b) Adding graphics/skin to native UI to make it standout from boring address-book UITableView lists. Ugly/boring apps are a graphic design problem, not a side-effect of platform choice.
ARGUMENT: HTML5 is ALWAYS easy to port, Native is not
MY EXPERIENCE: Far from the truth. When porting, you're not just porting to a different software subsystem but also different hardware parameters. Even the best designed HTML5 apps can't suddenly go from Android phones to iPad or iPhones to Nexus 7. Moreover, if you code the core functionality of your Native apps in C, it makes it quite portable. If you make your HTML5 views fluid/responsive, it makes it quite portable. If you're relying on special hardware functionality (camera, GPS etc.), it's a case-by-case issue of what's portable and what's not. If you have a data logging CRUD app that accepts user input on HTML5 views, posts to a remote server, and displays results, you might get away with 1-hour port like the author of this article. But more often than not, you have more issues to consider. In-App purchase? Yeah, can't port that easily. Facebook-integration? Can't port that easily unless you're using portable libraries.
Software development is just as complex on mobile devices as it is on servers. Your choice of platform (HTML5 vs Native) really depends on your specific app's requirements. There is no way you can make WordLens in HTML5 (today) and there is nothing wrong with going HTML5 if it saves you time and resources in the short and long-term. People need to realize that there are no absolute GOODs or BADs in software development. Pick the best option after you weigh in the cost of design & architecture, development, legacy support, resources, training, deployment, and maintenance.
My personal opinion based on my experience having written both native and html5 mobile apps is that the closest you can get to a "silver bullet" is a well thought out responsive HTML5 design packed in phonegap/cordova with native navigation elements. You get the benefit of snappy, native navigation while being able to go cross platform very easily with one code base.
1) speed - while not 100% fluid, with the latest phones this year and Android 4.1, rendering speed is easily kept within reasonable FPS (>40). On Android, even native apps aren't always fluid.
(Of course, in-app purchase and platform-specific libraries mean harder to port apps)
I must toss https://github.com/rogerwang/node-webkit/ into the mix. I have found it incredibly easy to develop with...and even easier to distribute.