Mozilla Chromeless: making desktop apps with web technologies
mozillalabs.com
mozillalabs.com
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.
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.
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.
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.
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.
Yes. http://www.reddit.com/r/programming/comments/apywt/qt_mixed_... http://news.ycombinator.com/item?id=2116815
> 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.
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
Chromeless sounds like a good idea but Google's V8 engine has been spanking Mozilla's engine for a while now.
They are working on it in theory, though I'm not sure what is taking so long: http://code.google.com/p/chromium/issues/detail?id=13148
It could have been a nice code name for the project, though :)
"Chrome is the user interface parts of the application window that are outside of a window's content area"
The name Chromeless makes sense.