Boy, the video's constant use of "the web" really annoyed me. I know that you have to cut down the jargon to make it presentable, and "HTML, CSS and JS" gets a bit confusing. What about "web technologies" or even just "a browser"?
Also: "You can run on less expensive hardware, because you've got less technology going on under the covers."
You can't really call a full HTML5 stack light-weight. Sure, you save some libraries, but that's mostly a space issue. I sincerely doubt that a JS-based "Angry Birds" would use fewer resources than a native app.
Having said that, I'm really looking forward to this. Hope there's a way to get it on older Android phones soon, my Nexus One is waiting for new life…
Mozilla very consciously uses the term "the web" because it evokes the right things in the minds of their target audiences: developers and end users. It has a sense that everything works together like "normal" web content. You don't have your videos stuck in an embeded plugin rectangle. You can control playback of audio with JS. Mozilla doesn't want you to look at a phone and think "I can run Firefox on that" because no one cares. They want you to think "I can use the whole web on this" because that's much more interesting.
HTML5, or perhaps better termed "emerging web technologies" are an incredibly heavy stack. You have 3 different means of markup being parsed from the get-go: HTML/SGML, XML and JSON. HTML is a quite lightweight component, OK. But then you get CSS. CSS used to be simple, but it's getting incredibly complex with tons of new standardised features and vendor prefixes. Initially it just drew lines and boxes in colour with text, positioned correctly on the page according to a few simple positioning systems. Now it draws coloured boxes and lines with 3d transformations, animated, with alpha transparency, a drop shadow and rounded corners, at the same time as rendering text, and positioning them correctly on the page using several different layout systems. Then, there's the image formats commonly supported. PNG, JPEG, GIF, and ICO (Windows, favicons). SVG, a fully-featured vector graphics format which also uses CSS, as well as having its own, different animation system, and its own scripting system! Then we have common audio and video formats. MP3, WAV, OGG, MP4/H264 and WEBM. As well as the subtitle formats. Oh yeah, MathML parsing is in there somewhere too.
And then we have Javascript, a simple, not terribly complex language. OK. But we also have tons of APIs for it. The Document Object Model API. The XMLHttpRequest API. The Canvas API - a complete 2d rendering context AND full OpenGL ES 2.0. WebSockets. Local storage and session storage. IndexedDB. Game controller API. Page visibility API. Audio composition API (forgot proper name). Touch events. BlobBuilder. Geolocation. History API.
Any serious candidate for an operating system is going to be complex. Personally I'm a little dismayed at current efforts to turn the browser into yet another cross-platform utopia. Some things will always be better native and pushing all this junk into the web browser just gets in the way of making basic things like a sane layout model that much more difficult.
First, JS & HTML are much more popular than Windows APIs. Second, I think johnrob meant that the DOM is more sane than most "desktop" APIs for laying out apps, not desktop publishing layouts.
But it's an open stack that is open all the way down. And it's being tested, used, and documented all over the net. That's not true of other operating systems.
I'm actually looking forward to the new APIs that will come out of this project - standardized web APIs that will allow Javascript to interact with everything on a device as if it were native code.
Regarding the Angry birds argument, if there were some type of deep-reaching JS "extensions" that expose lower level stuff I'd wager that you could get the game running pretty fast. I think Appcelerator/PhoneGap offer things like this. Granted, It is "twisting" JS, but I'd assume they are considering the limitations of the current "HTML5" platform and hopefully offer some solutions to get a "Web" Angry Birds version working. Additionally, there is already this:
That's why I used the comparison, it's definitely doable and I would assume that you'd get a decent enough performance out of it (as opposed to e.g. a JS-based Rage).
I just don't get the argument at all that this would enable it to run on a cheaper platform, i.e. somewhere where a native app wouldn't run. You're slicing away a tiny bit of overhead (once a kernel+browser is loaded), but adding more than that.
Wrong. Think of the three big mouths to feed in Android running modern apps or a browser (all of which require the embedded WebKit):
* Kernel
* Dalvik
* WebKit
The middle one is in fact a big memory and CPU pig for real workloads. Take it out, and B2G fits with room to spare on the 256MB QualComm phone we demo'ed at MWC -- ~128M used by kernel, Gecko, Gaia and apps at most.
Android does not even fit on this phone.
Your assumption that native-app framework and VM code loaded in practice is a "tiny bit of overhead" is false.
That looks like a full fledged game running in a canvas. It looks great to me. Is it somehow inferior to native Angry Birds? (I've never looked any other version).
Comments
Boy, the video's constant use of "the web" really annoyed me. I know that you have to cut down the jargon to make it presentable, and "HTML, CSS and JS" gets a bit confusing. What about "web technologies" or even just "a browser"?
Also: "You can run on less expensive hardware, because you've got less technology going on under the covers."
You can't really call a full HTML5 stack light-weight. Sure, you save some libraries, but that's mostly a space issue. I sincerely doubt that a JS-based "Angry Birds" would use fewer resources than a native app.
Having said that, I'm really looking forward to this. Hope there's a way to get it on older Android phones soon, my Nexus One is waiting for new life…
Mozilla very consciously uses the term "the web" because it evokes the right things in the minds of their target audiences: developers and end users. It has a sense that everything works together like "normal" web content. You don't have your videos stuck in an embeded plugin rectangle. You can control playback of audio with JS. Mozilla doesn't want you to look at a phone and think "I can run Firefox on that" because no one cares. They want you to think "I can use the whole web on this" because that's much more interesting.
HTML5, or perhaps better termed "emerging web technologies" are an incredibly heavy stack. You have 3 different means of markup being parsed from the get-go: HTML/SGML, XML and JSON. HTML is a quite lightweight component, OK. But then you get CSS. CSS used to be simple, but it's getting incredibly complex with tons of new standardised features and vendor prefixes. Initially it just drew lines and boxes in colour with text, positioned correctly on the page according to a few simple positioning systems. Now it draws coloured boxes and lines with 3d transformations, animated, with alpha transparency, a drop shadow and rounded corners, at the same time as rendering text, and positioning them correctly on the page using several different layout systems. Then, there's the image formats commonly supported. PNG, JPEG, GIF, and ICO (Windows, favicons). SVG, a fully-featured vector graphics format which also uses CSS, as well as having its own, different animation system, and its own scripting system! Then we have common audio and video formats. MP3, WAV, OGG, MP4/H264 and WEBM. As well as the subtitle formats. Oh yeah, MathML parsing is in there somewhere too.
And then we have Javascript, a simple, not terribly complex language. OK. But we also have tons of APIs for it. The Document Object Model API. The XMLHttpRequest API. The Canvas API - a complete 2d rendering context AND full OpenGL ES 2.0. WebSockets. Local storage and session storage. IndexedDB. Game controller API. Page visibility API. Audio composition API (forgot proper name). Touch events. BlobBuilder. Geolocation. History API.
Just to name a bit of it.
Any serious candidate for an operating system is going to be complex. Personally I'm a little dismayed at current efforts to turn the browser into yet another cross-platform utopia. Some things will always be better native and pushing all this junk into the web browser just gets in the way of making basic things like a sane layout model that much more difficult.
Then just stick with the DOM and XHR APIs. Those alone have been consistently crushing most desktop applications since ~2003.
Wow. Can you clarify? Are you saying something like Google docs is crushing Microsoft Office? What DOM/XHR app is crushing photoshop?
I think there is a new class of "apps" that are emerging as web based, but they are creating a new segment as opposed to crushing an existing one.
First, JS & HTML are much more popular than Windows APIs. Second, I think johnrob meant that the DOM is more sane than most "desktop" APIs for laying out apps, not desktop publishing layouts.
But it's an open stack that is open all the way down. And it's being tested, used, and documented all over the net. That's not true of other operating systems.
I'm actually looking forward to the new APIs that will come out of this project - standardized web APIs that will allow Javascript to interact with everything on a device as if it were native code.
Regarding the Angry birds argument, if there were some type of deep-reaching JS "extensions" that expose lower level stuff I'd wager that you could get the game running pretty fast. I think Appcelerator/PhoneGap offer things like this. Granted, It is "twisting" JS, but I'd assume they are considering the limitations of the current "HTML5" platform and hopefully offer some solutions to get a "Web" Angry Birds version working. Additionally, there is already this:
http://chrome.angrybirds.com/
That's why I used the comparison, it's definitely doable and I would assume that you'd get a decent enough performance out of it (as opposed to e.g. a JS-based Rage).
I just don't get the argument at all that this would enable it to run on a cheaper platform, i.e. somewhere where a native app wouldn't run. You're slicing away a tiny bit of overhead (once a kernel+browser is loaded), but adding more than that.
Wrong. Think of the three big mouths to feed in Android running modern apps or a browser (all of which require the embedded WebKit):
* Kernel
* Dalvik
* WebKit
The middle one is in fact a big memory and CPU pig for real workloads. Take it out, and B2G fits with room to spare on the 256MB QualComm phone we demo'ed at MWC -- ~128M used by kernel, Gecko, Gaia and apps at most.
Android does not even fit on this phone.
Your assumption that native-app framework and VM code loaded in practice is a "tiny bit of overhead" is false.
Well sure, but how is the Web 2.0 bubble supposed to keep going without trying to displace the entire actual computer?
Someday they'll try and download the hardware as FPGA over a RESTful web API, too.
That looks like a full fledged game running in a canvas. It looks great to me. Is it somehow inferior to native Angry Birds? (I've never looked any other version).