[ricmo]

The pain of developing web applications is largely dealing with cross-browser DOM and CSS issues. Swapping in a different scripting language may give you faster code execution, classic class-based inheritance and a packaging system, but as far as I can see it does nothing to help with layout issues, widget creation and other UI issues.

[jerf]

The pain of developing web apps today. Having faster execution makes a new class of web apps possible. (The other two things you mention are incidental next to having native code speed.) The longer you've been developing on the web, the worse your blinders are when it comes to what we could really do with native-code speeds.

[ricmo]

OK, how exactly? Web apps now, and presumably in the future, are essentially engines focused on manipulating a DOM structure, which is then rendered (with any luck, correctly) by the browser, right? So unless you're talking about effectively ignoring the DOM and rendering applications solely via use of Canvas or SVG, what is the magic sauce that flavors this <i>new</i> class of web apps?

[jerf]

Image and video manipulation, alternate widget sets (which nowadays tend to require at least one of heavy image manipulation or OpenGL to really work correctly), 3D applications that actually work and aren't just static models rotating (because now you can actually afford to manipulate vertexes with some intelligence). Online games that use a combination of these techniques. Apps that grab video from your webcam and do something with it. (Mozilla demonstrated that: http://arstechnica.com/open-source/news/2009/02/mozilla-demo... ) The dream of doing distributed computing by just visiting a web page could come true (like for X@Home). An OS in your browser would become not-a-joke. Native VNC instead of flash. Native encryption run by the app instead of the browser, possibly permitting ssh-in-the-browser. Actual typesetting could be implemented (surprisingly computationally expensive) allowing actual competition in the Office space.

You rather proved my point, unfortunately. Web apps are not about "DOM manipulation". They are about delivering no-install applications over the internet. They have historically been about DOM manipulation because that was all they could afford to do performantly (and that only barely at times). As that changes, so does the web. We're getting a ways along this path anyhow (http://code.google.com/p/quake2-gwt-port/ ), just with increasingly fast JS and other tech, but it's only going to grow more.

[ricmo]

We're talking (or at least I thought we were) about replacing the scripting language in a browser, which visually renders the structure and styling of a DOM. That's how browsers work.

Replacing the scripting language of a browser does not magically make the applications you describe possible, any more than it's possible to draw high quality vector graphics on a 5250 green screen. You're presuming all sorts of hardware-accelerated graphics, network connectivity, font manipulation and many other fundamental sorts of hardware manipulation that just isn't possible within the confines of (most of today's) web browser.

What you describe is indeed possible, e.g. Silverlight and Air, but putting a new scripting VM in today's browsers is not going to get you there. You're not talking about web applications, you're talking about a new class of web browser.

[jerf]

The web browser is the web application platform. Did you follow the link to Quake 2? It runs in browser you can download right now. And while the apps I mentioned do need some more support from the browser platform, that support is actually mostly there in some browsers. The only thing missing is native code speeds.

Are you keeping up with what web browsers are doing lately? They've turned a corner and are burning rubber now that we're increasingly less tied to Microsoft every day, and Microsoft's efforts to hold things back are no longer working. I'm hardly even hypothesizing, you can get demos of many of those things right now.

[wmf]

If you have a fast VM and <canvas>, you can do all your UI that way (see Mozilla Thunderhead) with virtually no cross-browser problems.

(Edit: I see that you already mentioned this further down the thread.)