Does anyone else wish that we could have the opposite? Web apps with desktop technology?
It seems strange that 20 years later the crude stateless hypertext technology designed to share physics documents has been hacked to serve desktop-wannabe apps. Yes, we all love the web's easy and ubiquitous deployment benefits, but what have we traded in exchange for that?
We've long since solved the problem of laying out desktop apps or printed materials. But it seems every time I read about CSS or Ajax hacks to get something similar to a desktop-style interaction it just boggles my mind at how much cruft we have to tack on to make the browser pretend to be a desktop system. Nowhere is this more apparent than the HTML5/canvas game development scene. While I'm cheering for open standards as much as the next guy, it's disappointing that a modern computer with its Gigahertz CPUs has trouble rendering a game that 20 years ago was being ran on CPUs in the tens of MHz range. We herald frameworks as our salvation, but these extra layers of abstraction will only serve to slow performance.
The Java applet, everyone's favorite web app bastard child was IMO at least a step in a (not the only) right direction. It would be cool if browsers supported a sandboxed execution environment that used a common open bytecode technology that allowed for languages other than javascript to be used (client-side python would be cool), and provided a common library for UI development and layout similar to what Java Swing has. It seems that everyone would love applets if they were introduced today using an open standard, implemented by the browser by default, and without everyone's memories of the horrible performance over dialup on orders of magnitude slower hardware and the whole Java/Sun thing.
Maybe it's time that we started looking for successors to HTTP and HTML designed with webapps/games in mind.
With regards to canvas, I'm looking forward to WebGL. It is based on a robust API that has been in use for decades (OpenGL), tuned for speed on low-powered devices (OpenGL ES), with full programmability (GLSL).
Browser support is still limited at the moment:
* Firefox 4 beta has already enabled WebGL by default
* Chrome beta has it turned on by default, I believe.
* Safari makes it available through WebKit nightlies.
* Internet Explorer is missing out, as usual.
But think about where they'll be in 1 or 2 years. I'm very much looking forward to high-quality 2d/3d content in the browser.
> Maybe it's time that we started looking for successors to HTTP and HTML designed with webapps/games in mind.
HTTP's by no means perfect, but it's roughly the right thing for most purposes and probably the part of the Web that needs revision least urgently. As to HTML, it's not so much that we need successors to it (though we do) as that we need markup-language browsers to be HTTP-loadable applications running inside a portable runtime instead of starting with hardcoded markup browsers and trying to bodge them up into a generic runtime plus GUI system. Your slogan for the day: "The Web Is Arse-Backwards".
By the way, notice that with (something on the lines of) NaCl + WebGL + appropriate cacheing we can could also get shot of the mobile-phone-native-app racket. No more Dalvik, no more iOS.
I'm with you 100%. The last thing I want as a user is to have my desktop experience reduced to that of a web app. Yes, there are some nice web apps that do some very slick things to try and approximate the usability and flexibility of a desktop app - but none that can truly match the sophistication of a non-trivial native client.
Perhaps the answer isn't to be looking for successors to HTTP and HTML - maybe the answer is trying to bring the best of web development tools (freedom to choose any language and tech stack) to native app development.
I expect this post is going to get downvoted to oblivion here, but I thought I'd share my opinion anyway.
>> We've long since solved the problem of laying out desktop apps or printed materials.
We've long since solved the problem of world peace and disappearing socks.
UI layout != print layout. And it's not really clear that we've solved UI layout any more than we've solved web layout. In fact, there's a bit of a trend in desktop UI layout towards web-like technologies such as DOM and stylesheets. Look at WPF and XAML, for example.
"[Using] web-like technologies such as DOM and stylesheets", is an insufficient qualifier here. XUL (Mozilla's internal UI markup language) uses those things, but if you were to say it's closer to Web-based UIs (i.e., using the CSS box model) than traditional desktop application UI layout, you'd be making a misstatement.
That's an excellent point. When one technology improves on another in certain aspects it's only natural that they be copied back into others. I just wish that we could have it both ways and use some of the stuff we've developed over the years in desktop app-land in web app-land.
You're right. Flash, Silverlight, Java applets, and Java Flex were all designed to solve these problems, but all of them suffer from the same problems: Their owners seek to control the platform and it has put users in a weird spot. Linux users can'tuse silverlight without resorting to Mono, Adobe doesn't provide flash for them either, as well as the whole mobile issue, and everyone still has a bad taste in their mouth from their experience with Java applets in the late 90s.
We've learned a lot in the past decade watching the WWW mature, and if there's one lesson to be taken away, it's that open standards are necessary for a healthy web.
Who remembers a few years back when Adobe Air was first making waves and Mozilla introduced Prism and Adobe's pr team hit the web to discredit it? Good times
Anyway, we've developed an internal app at my job targeting webkit on os x and we required the use of fluid, it was very nice not to have to worry about cross-browser issues. Shout out to Air as I understand and Prism (now Chromeless), more people should use this tech
We're doing the same using Google Chrome Packaged Applications, which is based on Webkit. We use FireBreath NPAPI extensions for any OS specific enhancements. The end result is noticeably faster than AIR and less resources.
Chromeless sounds like a good idea but Google's V8 engine has been spanking Mozilla's engine for a while now.
Not a lot of people know this but the recent version of Chrome supports running any web-page as its own app. Try it out from Settings [wrench icon] > Tools > Create Application Shortcut. It's great for todo apps or gmail. I know it works on Windows. The link seems to be grayed out in my OSX box for some reason.
Is Mozilla intentionally trying to create market confusion? It isn't obvious from the name, but this is built on XULRunner and has no relation to Google Chrome.
If you think that "Chrome" was chosen for any reason other than a direct reference to the widespread usage of the term with regard to Mozilla, you're crazy; i.e., if you have an agenda to name someone to blame for muddying the waters, pointing the finger at the Chrome team would be far more apropos.
It seems strange that 20 years later the crude stateless hypertext technology designed to share physics documents has been hacked to serve desktop-wannabe apps. Yes, we all love the web's easy and ubiquitous deployment benefits, but what have we traded in exchange for that?
We've long since solved the problem of laying out desktop apps or printed materials. But it seems every time I read about CSS or Ajax hacks to get something similar to a desktop-style interaction it just boggles my mind at how much cruft we have to tack on to make the browser pretend to be a desktop system. Nowhere is this more apparent than the HTML5/canvas game development scene. While I'm cheering for open standards as much as the next guy, it's disappointing that a modern computer with its Gigahertz CPUs has trouble rendering a game that 20 years ago was being ran on CPUs in the tens of MHz range. We herald frameworks as our salvation, but these extra layers of abstraction will only serve to slow performance.
The Java applet, everyone's favorite web app bastard child was IMO at least a step in a (not the only) right direction. It would be cool if browsers supported a sandboxed execution environment that used a common open bytecode technology that allowed for languages other than javascript to be used (client-side python would be cool), and provided a common library for UI development and layout similar to what Java Swing has. It seems that everyone would love applets if they were introduced today using an open standard, implemented by the browser by default, and without everyone's memories of the horrible performance over dialup on orders of magnitude slower hardware and the whole Java/Sun thing.
Maybe it's time that we started looking for successors to HTTP and HTML designed with webapps/games in mind.