"Also, the web platform isn't ready to be the only platform available for applications."
That's the whole point. The web wasn't quite ready to subsume PDF, until people went and tried to do it, found the pieces that were missing, and got them added.
We expect and hope that we're going to hit a ton of things that don't work today, and that we'll have to make them work and get a standardized API and so forth. I think that's a better way to proceed than to make speculative sky-APIs on standards mailing lists.
We are exactly targetting mobile devices (handsets and tablets), because we agree with your assessment of where things are headed, and because that's where the app action mostly is today. (We want to solve the app-store-for-web problem too, but that's another project.)
This isn't just about the web apps you have today. It's about having your contacts manager, camera, gallery, dialer, SMS app, GPS-integrated maps, launcher etc. be hackable using web tech. That work will help on desktop as well, since many of those pieces are on desktop/laptop machines -- if you write OS-specific code to get to them, and you're allowed by the OS to interpose your version of it.
Maybe you're right, maybe it's a fool's errand. We think it will help the web grow in powerful ways, and make important internet technology be accessible to more user-focused customization, so we're going to try it. That's basically what we do.
I definitely agree with you that improving and expanding what the web platform can do is an important mission and I'm glad Mozilla is taking this up. Whether building an entire operating system in order to accomplish this is necessary is yet to be seen.
I think it is necessary for the same reason it was necessary for Google to create Chrome to get the other browser vendors to get serious about Javascript performance. Today Javascript is no longer a blocker.
If Mozilla can force other mobile OS vendors to get serious about exposing lower level APIs to the web through (open standard) javascript, it will mean a major win for all smartphone users.
Chronology: Chrome came out in early September 2008. Mozilla's TraceMonkey was under development from April of that year. True, we started on a JIT customized for JavaScript (i.e., not Tamarin) later than we should have, but we did not start because Chrome with V8 was known publicly and already in the market.
I believe Apple's SquirrelFishExtreme work was also going on in the summer of 2008, on a webkit.org svn branch.
Your general point is good: healthy competition helps the web evolve. We got the world we wanted in launching Firefox in 2004. The battle's far from over, what with all the lock-in on mobile devices and in social network sites.
well the other option is to build web applications that need these technologies, kind of like PDF.js and jsmad have done, but for some of the other missing technologies that you have listed and see what is missing. You don't have to build an OS to see what is missing - that's my point.
I do not understand your point. How is a pure web application going to implement device APIs for Camera, Mic, GyroCompass, Accelerometer, USB, NFC, the list goes on?
These must be provided by the OS. But various OSes do these differently, some only for native apps. We propose to make every one of these a web-app-facing API, and standardize or use extant standards -- and include security up front and all along, not "add it later".
No one has done this, and saying that you don't have to build an OS does not address how web apps might come to have such device APIs.
Of course the web applications themselves wouldn't implement these features, but they would act as test cases for the APIs that get added to the browser (e.g. Firefox). As you build these test case apps, you'd see what features are missing and implement them in the browser API, standardizing things along the way. If your point is to improve the web APIs available and find out what is needed, then build the features in the browser and build great applications on top of these new APIs that work on all platforms rather than just being tied to the Mozilla OS (at least for a while). If you truly want to make these features into standards you'll be adding them to Firefox later anyway, right?
The problem is that Firefox can't implement these APIs without OS support, and OSes don't have the same kind and number of such APIs. We are working on better cross-mobile-OS Firefox, but it cannot be our only bet.
What's more, Firefox is locked out of many mobile OSes (I do not mean iOS in particular), but the commoditizing hardware can support a fully open OS and web-based "home" and open web apps environment.
The increasing vertical lock-in and tying among all OS vendors (Android included) and the at best half-open- / delayed-open-source status (ChromeOS excluded, bless it -- but it won't support other browsers than Chrome) are problems for Firefox.
That's the whole point. The web wasn't quite ready to subsume PDF, until people went and tried to do it, found the pieces that were missing, and got them added.
We expect and hope that we're going to hit a ton of things that don't work today, and that we'll have to make them work and get a standardized API and so forth. I think that's a better way to proceed than to make speculative sky-APIs on standards mailing lists.
We are exactly targetting mobile devices (handsets and tablets), because we agree with your assessment of where things are headed, and because that's where the app action mostly is today. (We want to solve the app-store-for-web problem too, but that's another project.)
This isn't just about the web apps you have today. It's about having your contacts manager, camera, gallery, dialer, SMS app, GPS-integrated maps, launcher etc. be hackable using web tech. That work will help on desktop as well, since many of those pieces are on desktop/laptop machines -- if you write OS-specific code to get to them, and you're allowed by the OS to interpose your version of it.
Maybe you're right, maybe it's a fool's errand. We think it will help the web grow in powerful ways, and make important internet technology be accessible to more user-focused customization, so we're going to try it. That's basically what we do.