I feel like I have just seen the future and it is very bright. This would make mobile development so much easier and open up a completely new range of possibilities.
Just imagine ....
- writing just one app that runs on every desktop and mobile phone out there.
- apps which update entirely automatically, without any extra line of code, because they are basically just cached versions of a website.
- a designer, who just knows CSS & HTML, can make an entirely new GUI for your phone.
- an eco-system where the development of the interface (HTML) is completely separate from the kernel/browser and you can choose which kernels/rendering engine to run on your phone, independent of the user interface and vice versa.
- etc. etc.
Kudos to Mozilla for their vision and for not just developing the technology, but making a good looking prototype to demonstrate it.
However, I am a little bit skeptical that a web-based OS will perform the same as a native OS, especially in terms of battery consumption. But smartphones only get more powerful and html rendering engines only faster, so it can only be a matter of time. Also a little nitpick with respect to the title: the OS not entirely build using HTML, CSS and JS, it's just the user interface, which is just small part of the OS (compared to the kernel, etc.).
EDIT: I know most of this is already possible in principle, but the user / developer experience would be completely different.
- Everything is already one terrible interface for everything. Make a better interface.
- The better companies will minimize this. We still depend on cloud services like Gmail, github et.. on a day to day basis. And they still mess it up occasionally.
- There are ready designers who know nothing about UI design for each particular device pumping out apps.
- Look at the linux ecosystem. I think its working out.
* I don't know what programs you're using. I think the iOS interface is great and rife with amazing UIs by both Apple and 3rd party devs that I enjoy using every day. If your devices have terrible UIs that are non-unique, that's your business.
* I rely on those services via clients that beat the hell out of the native web offering. Cloud services are an inbuilt way of life, cloud or web-based apps can go die in a fire as far as I'm concerned. They have two benefits: Developer simplicity and access from anywhere. Everything else is just downsides.
* Of course, but making it easier doesn't help. Just like with all fields, most programmers and software designers are amateur and lazy. IMO making even easier for these people to create terrible apps and making it the cornerstone of a mobile OS is a really bad idea.
* ...You're joking right? I don't even know where to begin with that one, except to look at Linux on the desktop numbers and then come back to me.
This is another Visual Basic craze, in which someone creates a way for non-programmers to program and everyone piles on thinking it will be the next big thing.
The way I see it is this: the apps, the GUI and the underlining OS would be completely decoupled from eachother (much like Linux/BSD and Gnome/KDE). The OS would be free software, because that is what FOSS is good at (not end user facing software).
For the apps and GUIs there would be a marketplace (or ideally several), where people/companies can sell or give away for free their software. Most GUIs and apps would suck (just like most apps suck today). But there would be a few ones, which are truly great, much better than Google or even Apple could ever make them. And these would not be made by big companies, but by small startups consisting of creative people.
All software can update. There is nothing fundamentally different between a web apps' ability to update and a desktop applications' ability to update. If you need any proof of this, just look at Chrome.
Once you run software on your computer, if that software can connect to the internet, it can update itself!
there is something fundamentally different, you can choose not to update a native appp, you can also choose to run an old verion. you can also continue a native app if the creator decides its not worthwhile, or google buys them out
My point is that there is nothing* preventing any native app from including code to update itself. Over time, I believe that more and more native apps will do this. For example, Firefox is moving in that direction now.
* Except for in the case of iOS. Apple has a policy that apps are not allowed to update themselves. But there's still no technical limitation.
Right so we're discussing the reality of the situation, which is that web apps would have no choice but to force update (as they would be run server-side and hence the client wouldn't have a choice) and that native apps could be possibly, but aren't.
I thought that the general consensus was that you never wanted multiplatform anyway. Not because it can't be done but an app that looks and acts the same on both iOS and android (for instance) will suck horrible on at least one platform (but probably both).
Apps which will update automatically? That's just as possible with native apps but you have the option to turn that off - because it's a bad idea for a lot of applications. In general if you don't respect that as a developer I don't want to use your apps.
You can make an entirely new GUI for android right now if you wanted to. But for the same reason as in my first paragraph, you really don't wan't to fragment your userbase. The GUI guidelines are very important for apps to integrate well, as an app developer you would now have to support all those third party interfaces that will change every five minutes... I wouldn't call that a bright future.
Designing a good GUI is hard and if you have managed to make it easy it is going to be really bad.
> I thought that the general consensus was that you never wanted multiplatform anyway.
There is no consensus. It's like there is no consensus on static vs. dynamically typed languages. Both are good for different things, both have an important place.
On the one hand, without multiplatform apps, new platforms have a problem. The original iPhone had no apps, but it ran the web and everything on it. Likewise, without multiplatform apps, people on minority platforms - Linux, OS X, etc. - have far fewer choices.
On the other hand, without platform-specific apps, you miss out on a level of customization and tailoring that isn't possible in a multiplatform app.
Designing a good GUI is hard indeed and it requires a completely different skill set than the engineering task of writing a good OS/kernel/broswer. That is why ideally the two should be taken on by different teams in my opinion.
So the plan is to force the UI-team to work in javascript and that way automatically get rid of the kernel-guys?
No, but seriously, who does that today? (aside from one-man operations) And how is this going to help?
As to a third party GUI, I'm fond of the idea in for instance the android world. Instead of manufacturer-specific user interfaces, why not a third party interface developed by an independent company that doesn't produce phones. As it is now manufacturers care more about being unique than good and google doesn't put enough effort in it because everyone will change it eiterway.
But there are serious obstacles to succeeding with that and I don't see why that has anything to do with the development-side of it.
> No, but seriously, who does that today? (aside from one-man operations) And how is this going to help?
People used to write code in assembly and interface directly with the hardware. Then OSes and compilers came and made everything easier for everyone involved. Only a few highly specialized hackers know how to write device drivers and assembly anymore.
I am convinced that in a few years from now (remember I was talking about the future) the majority of developers will be "frontend developers" who know HTML/CSS/JS (or hopefully JS replaced with something more productive). Right now that thought might suck, but imagine how many tools and libraries will be available by then.
> But there are serious obstacles to succeeding with that and I don't see why that has anything to do with the development-side of it.
I am not sure what you are talking about. I am talking about completely decoupling the user interface from the rest of the OS, a little bit like it is the case on the desktop with Linux / BSD and KDE / Gnome. Only that making user interfaces does not require a lot of technical knowledge.
EDIT: Just to clarify. I am talking about a hypothetical future mobile OS not Android or iOS. The way I am seeing this is a little bit like WordPress plugins. There would be a default GUI, but most people would download a custom one. A large number of UIs would be free, but if you want to be hip you need to pay for the latest one. There will be an entire new class of UI designers, just like since a while ago there is a new class of mobile app developers.
EDIT2: The OS itself would be FOSS and the hardware would dead cheap, because it is just a commodity. Eventually it will replace desktops, for instance with a special javascript API to run a virtual machine, which can run a desktop OS on your phone, if you need one, e.g. for development.
I'm not arguing against the use of a high-level language.
I also thought of *nix as an example, and that is in my eyes a perfect example of how you do not want it to be (the result at least).
I don't get the need for many different interfaces. You do realize that as an app developer you have to constantly adjust your app for different interfaces, and people complain they have to make high-resolution interfaces for the ipad3 - that's nothing compared to trying to adapt to different user interfaces.
A user interface is an investment, a whole ecosystem that many generations of applications depend upon. You don't just change it at will, think about all the inconsistencies you'd have to deal with.
>However, I am a little bit skeptical that a web-based OS will perform the same as a native OS...
I believe the idea is that it will be native on ALL devices, thereby eliminating the need to convert one application for multiple devices. An application written in HTML5/CSS/JavaScript for the web should function the same way on a mobile device OS that is essentially a web browser. Am I wrong?
This makes absolutely no sense. This is borderline an insult to system developers -- because system software is what the device is running directly.
I'm all for people to state a bit of sensationalist statements so they can sell there shit and be understood by the general public and so over, but this is going way too far. Being proud of an intrinsically limited product (this is a linux that runs only one program by design, so this is less capable than an android or whatever) for the improvements it can brings as side effects is one thing, but a statement like "this is running the web directly" is misleading because it will be understood as the real stuff by less knowledgeable people who will believe in some kind of incredibly innovative magic, like a magical processor "running the web" or i don't know what idiotic fantasm, instead of taking the thing for what it is: a system that can do less, with maybe some advantages as a side effects, but of course some inconveniences too.
>This makes absolutely no sense. This is borderline an insult to system developers -- because system software is what the device is running directly.
It's ok. We're used to it. From the desktop to the laptop to the netbook to the phone, Mozilla and Google have been trying to exterminate us for years.
> Mozilla and Google have been trying to exterminate us for years.
I highly recommend you take a look at PNaCl: portable LLVM binaries run in the NaCl sandbox. Since LLVM bitcode can be JITed (or even offline compiled before execution), you would be looking at optimized code for whichever target you're running on. Very exciting stuff.
Which requires that people use Chrome, running a web-browser to run native code that gets JITed from bitcode... at that point, why not just pull the blocks from the Jenga tower and run native code on your processor through an executable file loaded by an operating system?
This runs a Linux kernel with some components in common with Android like libusb, so really linux is the operating system and there is a browser running on top of it.
It's more than a user interface though. It's a platform for Web applications that let those apps reach all the way down to the full capabilities of the hardware.
Perhaps we share a definition disconnect. Is X11 a platform for a user interface or is it a OS?
I lean to the former definition but I'll be the first to agree that I come from an earlier time. When 'windows' came out it really was a user interface on top of MS/PC-DOS (and it still is IMO) however now several generations of folks have been brought up saying that Windows was the OS.
You're right, in fact the Linux Kernel was used to minimize changes OEMs would have to make to support B2G. Also, Mozilla has been working with Qualcomm to make sure that B2G is optimized for their chips. It should be very interesting to see the potential market shift once B2G is released.
There are a lot of "looks promising" comments here. Am I the only one who thinks this does NOT look promising?
Aside from games, rendering a markup language is one the most taxing things we do on our mobile devices. When I get handed a new phone to play with, the first thing I do is load a non-mobile optimized website and see how it scrolls. This worst-case scenario is a good indicator for how laggy and jittery a mobile OS will be at sporadic times throughout the day.
Now a mobile OS built entirely on the worst-case of rendering HTML, CSS, and JS for every interaction? Sure, devices will keep getting faster as time goes on. But keep in mind that as device performance over the years increases, so do our expectations. I am skeptical that this will ever deliver a sufficient user experience when compared side by side to other mobile OSes.
> Aside from games, rendering a markup language is one the most taxing things we do on our mobile devices. When I get handed a new phone to play with, the first thing I do is load a non-mobile optimized website and see how it scrolls. This worst-case scenario is a good indicator for how laggy and jittery a mobile OS will be at sporadic times throughout the day.
The point here though is that you have less overhead by focusing just on the web. Running a web browser on a normal mobile OS, as you mentioned, runs a browser stack on top of the normal OS. There is additional work there, for example, on Android to run the browser you also run the Dalvik VM, etc. And the underlying OS and userspace is optimized for native apps for that platform, not just for the browser.
B2G purposefully has just one VM - JavaScript - and just one native app - a web browser, and the underlying OS is optimized for running exactly that, not native Android apps or native iOS apps in addition to a web browser.
It's too early to say how the final result will be. But the approach makes sense and is worth trying.
I am skeptical that this will ever deliver a sufficient user experience when compared side by side to other mobile OSes.
Wasn't the same sort of thing said about the desktop vs the web? Sufficient is the key word here. If the experience is good enough, where users are willing to overlook design quality for the sake of not having to worry about constantly installing and updating apps, then this should do the job. Convenience is king.
I agree, people under-estimate the resources required to render typical web content, and also tend to forget how even on the high end devices that the web experience isn't particularly good.
Depends. "Worse is Better" used to be one of the most reliable phenomena in the software industry. That would suggest a more open, network-centric, HTML-based interface should win, despite annoyances or bugginess.
But that rule doesn't seem to be holding true for the mobile market.
I don't really understand it. Maybe simplicity, affordance, and marketing are now the important factors, given the kinds of users we are now reaching.
If B2G wasn't performing well at this stage, I doubt they would push forward with it as hard as they are. The transitions and scrolling between "home-screens" shown in the video look quite smooth to me.
Lots of us do use actual applications on our actual computers. If I didn't receive a GMail app with my Android phone by default, I would go download a Thunderbird-equivalent app. Web applications are bloated sacks of and perform similarly on anything smaller than my desktop-replacement laptop.
"You can run on less expensive hardware, because you've got less technology going on under the covers. You don't have to pay the penalty of a big smart phone operating system if you're running directly on the web."
That's misleading. Sure, you might need fewer resources to pull something like a simple web page. But try using web apps that are the equivalent of native apps on Android or iOS, and you'll need a lot better hardware to run those just as well.
Could you explain why? I might be looking at it a bit too naively, but how system build for running interpreted JavaScript apps can perform better than one designed for compiled ones?
It doesn't perform better. But at the low end, you don't need to bootstrap a java VM (like Android) just to check your email and browse the web etc. You can do the little things on less hardware.
No, but you have to bring along a whole browser just to interpret code that checks the mail...
Anyway you spin it the low end that can't manage android will never in a million years be able to run an "OS" in javascript. There is a reason they demo it on a SGSII ;)
You just need to look at the original Pre. It was less expensive hardware (by today's standards) and it has webOS with web apps, and apps on the Pre always suffered inferior performance compared with apps on Android phones with similar hardware. It wasn't until the Touchpad that webOS apps had good performance, and even then the dual-core processor with 1GB RAM wasn't enough, they needed a couple of OS updates to get app performance up to speed.
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).
This is a really promising direction to take for Mobile Apps. If I can write amazing HTML5+JavaScript apps for the Mobile then the logical extension to this is to write the Uber-app "Phone OS" using these technologies as well.
Lets get this working on at least the Dual & Quad core beasts first and worry about the lesser-hardware ones as B2G evolves
Good work Mozilla and keep Pushing the "Open Web". A walled garden despite its many advantages, is still a Gilded Prison for some.
Regardless of how it is, it's too late: Android is the new Windows, iOS the new System7, and everything else is the equivalent of AmigaOS, OS/2, BeOS, etc...
About ease of development being a gateway to shovelware, yeah right as if the artificially high and expensive barrier to iOS is keeping all the fart apps away. The fact is if there's money to be made then everyone will try to get in, even the wantrepreneurs hiring cheap coders to copy some old game and repackage it as something new (for more information check Harvest Moon).
If Android has more freemium shovelware is simply because it became the dominant OS in that industry, so wantrepreneurs are targeting that market instead, same as it happened with Windows and MacOS.
As I was watching the video I was thinking the same thing that WebOS has been out for years. I'm sure the underlying technology and framework is quite different from Mozilla, but it's not a ground-breaking idea.
Perhaps they should take the opportunity to work on the newly open sources WebOS which is likely to be able to grab more market share than an entirely new Gecko OS.
WebOS uses JS+HTML but it does not expose nor advance standards-based APIs for all the phone hardware capabilities like B2G. Also, WebOS requires you use their framework where B2G lets you use any frameworks or no frameworks -- it's really just like the real Web plus a bunch of DOM APIs for things like the phone's telephony stack and vibrator and accelerometer and all that.
Really as it should be. If the software was any good it would make using it feel like nothing at all. The only attraction left is the screen/battery/camera/wifi quality.
I've been waiting to see something like this for a long time.
This definitely blurs the line between calling an app native or web based, at least from a business-marketing standpoint. However, far more interesting is to see the waves of innovation that APIs have created. APIs are becoming the personality of computer systems in the sense that they allow interaction and shielding from the outside world. As long as developers know how to interact with a system's personality they can now build just about anything. Furthermore, experience is becoming the new IP so I believe that such technologies will bring more and more experience innovation by providing easier and faster paths for high-level programmers to contribute to the ecosystem.
So, I noticed there was no mention of multi-touch events in the video, and none of the apps demonstrated used multi-touch. I did some digging to see whether this was a gap or whether mozilla had been working on multi-touch in browser (since the consequences of such a change for JS APIs are interesting to consider).
Mozilla has apparently been working on multi-touch in browser as one can see in these two links:
It is possible they see their OS as being suited for one-handed devices. One of the things I do not like about Ice Cream Sandwich on my Galaxy Nexus is Google has removed the "+"/"-" buttons in most of their native apps so now I have to either use some really unwieldy one-handed finger contortions or use two hands to zoom in and out. I think an argument can be made that in many instances at least on a smart phone as opposed to a tablet multi-touch while being fun to use is actually a step backwards in usability.
The reason I'm excited about this that I won't need to wait for the carriers to update my UI. I imagine there will be a whole rage of interesting 3rd party interfaces I'll be able to browse and download.
Want and interface that's just command line. Somebody will make it.
What about an interface for Grandma that just has really big fonts in just a dialer, contacts and photo album.
I feel like I got burnt when I bought my 7" Samsung Tablet because Samsung is not supporting it anymore and it has some really clunky interfaces.
I would love to see and ecosystem where I have full and easy control to install and remove apps from my phone easily. Fingers crossed.
Is everything cached to the device? What are my limitations in "airplane mode"?
I don't mind the concept of making cross-platform apps. My limited knowledge of HTML/CSS has shown me that while it is extemely difficult to make robust content look good across multiple browsers/platforms, it IS possible... but will developers really have the access to multiple platforms to test their UI on?
This is awesome.. and it is the way forward if every device can just run a browser then what is the need for an OS, you can port anything straight to the browser.
With the likes of HTML5, jQuery, WebGL, AWS everyone could be making their own OS on the web.
It is really not that hard or revolutionary it's just using existing services effectively.. Let's carry on this way.
I love the mentality behind this effort. More stuff can and should be done in the browser on mobile devices. For this to succeed, the most important problem is not exposing mobile hardware (camera, gps, etc) - it's user input. The cornerstone of the web is typing a url into the address bar, and typing is still a miserable experience on phones. Clicking links on touchscreens isn't exactly stellar either (hence the new verb 'fat-fingering'). If someone can solve these problems, the browser stack is already powerful enough to do to phones what it already did to the desktop.
No, unfortunately. Most of the videos going around (read: all of them) are from MWC where B2G was demoed.
The development group is VERY active on IRC and there was some chatter at the time about that. Some of the slight lags in the demo were actually parts of the CSS transition they use (originally intended to avoid accidental swipes when they wanted taps) and was tweeked to be much better not long afterwards.
More recently there have been significant improvements in the actual CSS animation on the gecko side (improvements which will hit firefox in the future) which means everything feels even faster and more natural.
At this point B2G is making significant progress _every day_ so about the only real way to get an up to date idea of how it runs is to either read the github commit log frequently or put it on a device (and currently that means a GSII)
That would be awesome if it actually became a mainstream mobile OS.
Otoh, what about security here? Having JS from a web site dial the phone or taking pics? How will they make sure that lazy I-don't-read-popups-but-just-click-okay users will not get pwned?
Dialing the phone and taking a picture work no differently than they currently do on iOS/Android - your app simply calls the device's native functions and then the OS takes over the operation. And once the operation is complete/cancelled, focus can return to your app if you set the proper callbacks.
Potential security concerns would be akin to the Chrome-extension snoop and inject issue where a random app or web-page could potentially try to read/write the data of other apps if the security model isn't setup right. But these are problems fixable in the short-term. On the plus side, as the phone owner, I might be able to redesign the OS dialer by changing some CSS and finally have a phone pad that goes 7-8-9/4-5-6/1-2-3 like a num-pad instead of 1-2-3/4-5-6/7-8-9.
We already have a lot of miles on ChromeOS. Why isn't it more popular? Is there anything fundamentally inferior about a device that is all web browser? Will B2G have the same barriers?
It's 'the Web', i.e. a set of HTML pages with some CSS and JS, with access to a few newly developed APIs, like the one for dialing the phone, but running locally on the device, not remotely.
Does anyone know how the sandboxing works to allow a camera, gallery and dropbox app to access the same locally stored image files? Or for local contacts to be shared?
Mozilla should skip working with the carrier just go to the phone manufacturers and develop their own phone. Once they have their own phone it's only an matter of time before carrier jump on board with them.
This is actually a battle cry for Mozilla. The desktop GUI paradigm is done for, it's at the end of the line. Once desktops die off in popularity there will be no growth for web browsers like Firefox unless they own the whole stack like Apple and Google have successfully done, and Microsoft and RIM are attempting to do. Mozilla is developing Boot2Gecko because without expanding into a full mobile platform Mozilla is in a really tough spot in the smartphone/tablet markets. Predictions for the future put Apple/Safari at 45% marketshare, Google/Android at 54% marketshare, and the 1% scraps left over for RIM, Microsoft and now Mozilla.
Mozilla will to have sell an awful lot of these phones for their organization to be viable in the future.
Someone please notify my entire computer setup of its impending death. Also, my wife, my mother, my brother, my stepfather, my father, and everyone else I know.
Hey, everyone, your computers are dead! It's time to convert to WebSmartiPhonePadTablets running nothing but web-browsers! Sure, you don't want to because they run like crap compared to actually writing native programs, but they're a growth market for corporate behemoths!
Ah yeah I should have expected such pedantry on HackerNews. You know very well I didn't mean you were going to stop using Windows immediately. I said nothing of the sort. You didn't even have the respect to read anything else I said or even acknowledge that I said anything else. Instead you pointlessly nitpicked at a generalization and added nothing to this thread.
"This browser-based OS will revolutionize how users interact with their apps and how developers write their apps, allowing everyone to take their apps everywhere."
-Jon Rubinstein, January 2009, commenting on webOS
I had the original Palm Pre with WebOS. The OS itself was actually top notch. I absolutely loved it. I believe it failed because Palm just didn't have enough weight behind it (like Google or Apple have) to make it reach critical mass.
That said, this isn't the same as WebOS. WebOS ran javascript apps, but they ran on the device itself. From what I can gather, B2G is running everything on the actual web. It's very different.
--
Edit: I may have been wrong there. Apparently it is running locally. This quote from the web page through me off:
"You don't have to pay the penalty of a big smart phone operating system if you're running directly on the web"
B2G runs apps from the web and locally cached for offline use. B2G apps are not required to use some non-standard library to get at the phone hardware like WebOS did. APIs for camera and telephony and vibrator and accelerometer and all that in B2G are proper DOM APIs that will be web standards.
I'm not sure why WebOS failed. Probably just because they couldn't attract as many developers, so there was a lot less software available. I really liked my TouchPad. Ironically the biggest weakness for me was the web browser - it was buggy and had almost no features.
Just imagine ....
- writing just one app that runs on every desktop and mobile phone out there.
- apps which update entirely automatically, without any extra line of code, because they are basically just cached versions of a website.
- a designer, who just knows CSS & HTML, can make an entirely new GUI for your phone.
- an eco-system where the development of the interface (HTML) is completely separate from the kernel/browser and you can choose which kernels/rendering engine to run on your phone, independent of the user interface and vice versa.
- etc. etc.
Kudos to Mozilla for their vision and for not just developing the technology, but making a good looking prototype to demonstrate it.
However, I am a little bit skeptical that a web-based OS will perform the same as a native OS, especially in terms of battery consumption. But smartphones only get more powerful and html rendering engines only faster, so it can only be a matter of time. Also a little nitpick with respect to the title: the OS not entirely build using HTML, CSS and JS, it's just the user interface, which is just small part of the OS (compared to the kernel, etc.).
EDIT: I know most of this is already possible in principle, but the user / developer experience would be completely different.