I wonder if Joe Hewitt is not going to wait, and he will channel his energies into helping HTML5 catch the native app rocket ships. Go beyond Firebug.
[1] http://techcrunch.com/2010/04/30/joe-hewitt-web-development/
Can it? It feels like the browsers are slaves to their own success; what the web desperately needs to compete with native applications is the antithesis of what the web has become. To compete, the web would need:
- A runtime environment that can run complex applications -- including games -- with high performance on low-end mobile devices.
- Support for languages other than JavaScript, without having to compile to JavaScript (for why javascript is not an adequate compilation target, see above).
- A common, consistent, high-level application UI toolkit, with support for re-usable UI components. The seperation between HTML, CSS, and JavaScript is the wrong one. We need 'native' widgets rendered in canvas, using a coherent hierarchical view-based design -- not the DOM. You can build this on top of HTML/JS/CSS (see Obj-J/Cappuccino), but that's like saying that all turing complete languages are equal because they can emulate each other.
Any progress that a particular vendor might make (such as WebSockets, NaCL) will be held back by the other vendors (looking at you, Mozilla).
If you help the web catch up to modern native apps, you'll have just re-created native apps -- sandboxed, native code execution speed, coherent application libraries, etc...
Also, performance on the mobile space is a matter of waiting 2 or 3 years. Mobile perf is moving up fast, partly by browser revs and partly by better hardware. People used to say we needed something better than javascript and the dom on the desktop as well, and a few years of moore's law made that discussion irrelevant. Browser tech isn't bad enough to need replacing, so i don't see it getting replaced.
To compete, the web environment has to change drastically, but those that have invested in the web as it exists today don't want to change.
> Browser tech isn't bad enough to need replacing, so i don't see it getting replaced.
That's just the thing, though -- for applications, it is being replaced.
Back to mobile, the app stores make it way easier to ship native apps, and the browsers make it harder to deploy web apps. The consequence is that on mobile native still wins. The app stores may turn out to be better than the web for shipping apps. The web won't win that fight by making it easier to build better apps, it will only do so by making it easier to ship.
The web has the distribution problem solved, but as an application technology platform, it's horrible. Now that we've got a route forward with distribution of native apps, the native app market is growing by leaps and bounds, and it's the web that needs to catch up.
What I'd like to see is a common application platform, PNaCL based, with consistent high-level APIs .. but that would NOT be the web as we know it. It would be another native application platform.
If we were to use PNaCl, even once Google sorts out all the technical issues, in order to compete with native mobile apps, a whole ecosystem of toolkits and libraries will have to be created. That will take time, and we will see growing pains just like the ones we're seeing with mobile app frameworks for JavaScript.
Compare this to the status quo with JS. In two years, JavaScript will be as fast as NaCl for 90% of applications out there. Look at the speed of LuaJIT, which is the closest cousin to the modern JS engines, compared to C [1]. And this is on scientific number-crunching microbenchmarks! We don't have to throw away the lingua franca of the web in order to achieve good performance.
Let's look at the modern platforms:
- Microsoft is innovating heavily on the language front with C#, F#, and the CLR. I'm not a big fan of Microsoft's platforms, but there is no denying that they're doing very interesting work in language and runtime design.
- Google is innovating with Android, the Dalvik VM, and an application development framework not too much worse than Apple's. You have the NDK at your disposal, and many GL-based games can be ported without too much complexity from iOS. Numerous languages are being ported to the JVM, and are supported on Android.
- Apple is innovating with UIKit and high-level high-quality application development frameworks. Even if ObjC isn't particularly cutting edge, it's a reasonable solution for building large applications, it's fast enough, and you've got C at hand.
The browser makers, however, are fighting over whether or not WebSockets can actually be included in the browser; meanwhile, Apple rolled out GameKit support for automatic peer-to-peer session negotiation over bluetooth, wifi, and the internet to support multiplayer games.
The web as an application platform is broken, and will continue to be so as long as browser makers attempt to force everyone to stick to one language, lacking a standardized platform API, using a poor view model (DOM/HTML/CSS), stuck in the browser's limited sandbox.
I wrote this a few years ago on the exact same subject and advocated that a real VM plus application stack is required for the browser if it is to compete with native applications.