[jefflinwood]

The problem with HTML5 as an app interface isn't getting something to appear on the screen on any of the browsers, it's getting the user experience to match the native platform.

A similar post in 1999 would have been titled: "Why native development sucks and Java Swing rocks: Porting to Mac OS 9"

[megaman821]

Well, I guess to be fair. Windows 8 styling is something that you could do in CSS (and is done in CSS for some apps), so HTML5 apps will look native (to Metro).

[themckman]

Hell, looking at Safari, I see no reason why you couldn't put together an interface like this in HTML/CSS. To the grandparent's point about Java Swing, I don't have much experience with Swing, but I did see a little as I was entering college in 2003 and it objectively sucked. And that was 4 years after the hypothetical article title presented. I think the biggest thing hindering the HTML/CSS thing on certain occasions is performance, and even there, browser performance is pretty damn good these days.

Edit: My last sentence may or may not have somewhat proved what the grand parent was trying to say.

[lazyjones]

We'll see what happens to browser performance when most apps on the Win8 desktop are HTML/JS/CSS based and when typical displays have 300-400dpi... We'd probably get better performance if we resurrected NeWS.

[asadotzler]

300-400 dpi on desktops is a silly idea. 200 dpi is excessive for a display that sits a couple feet away from you. Even for laptops which have screens that are on average closer, 200 dpi is pretty much all you need. Going much beyond that gets you very little in terms of perceived quality while costing a lot more to manufacture.

[GeorgeTirebiter]

Exactly!

HTML5/CSS/JavaScript are finally moving in the right direction.

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.

Years ago, this would have been a crazy idea. But today's machines are so fast that I believe we're finally ready to accept the need for better security and authentication, and, at the same time, accept a bit of a slowdown of our apps to trade for robustness and safety. Not to mention the side benefit of getting rid of HTMLx CSS and probably JavaScript !

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.

[Evbn]

You may be interested in Chrome and NaCl and ChromeOS.