Wow, what a thing to wake up to! At the heart of the Open Web Device is Mozilla's Boot2Gecko project. I just joined up with Mozilla on B2G a couple weeks ago and it's been an honor to work alongside so many amazing people, with a great goal: building a truly open mobile ecosystem. If you guys have any questions about B2G itself, feel free to ask and I'll do my best to answer.
I had a couple of questions on how you'd implement things like Spotify or Dropbox (i.e. apps that download a bunch of files, or upload existing ones).
And also about how apps would interact with each other (so that I can change out one SMS app for another, but have everything else continue to work).
Oh, and will it support things like different keyboards? I love that on Android I'm not using the home screen, keyboard, email, SMS, or calendar apps, and it all just works fine.
So, in terms of an app like Spotify, you'll build it based on common web standards, e.g. offline storage APIs for caching. Dropbox is a more interesting case, as the basic use case of things like photo uploads from the app use the standard media APIs, but integrating it into the rest of the system requires a lot more work.
The answer for integration is more a global one, and honestly I don't have a good answer yet. I could see something like Web Intents/Web Activities enabling replacement of the homescreen or keyboard and perhaps eventually integration with the likes of Dropbox, but there's still a lot of work to do before that point.
To me, these sorts of important, unanswered questions are where B2G wins the most. Rather than coming up with the answers in isolation and then pushing the result on the world, we encourage everyone to get involved in the process, and we will make it into another web standard that benefits everyone, not just Mozilla or B2G users/developers.
note: I don't work for Mozilla but follow B2G closely. All of this stuff is possible. Everything in B2G is a web app, including the keyboard IME (and the browser, and the window manager itself). You can definitely swap that out. The only thing that's not swappable, to my knowledge, is the phone app.
It's super easy to swap out any piece (or replace the whole UI) if you're willing to mess around on the device, but there's no way to do this from the UI as it stands, like you can with Android. I'm excited to see the solution to that problem.
It's not possible to truly implement Spotify as there is no P2P in HTML5 yet - but see Chromium's efforts with WebRTC.
It's also not possible to implement Dropbox. When last I checked, IDB in Firefox is at least an order of magnitude slower than a KV implementation with direct posix access. Most importantly, there's no proper native crypto api, and no way to let a user open a file from within a web application, and have it open in a native application, polling the file for changes to sync the different chunks when the user hits CMD+S.
Sort of. The key difference is that B2G is aiming to allow web apps to do absolutely anything a native app can do, whereas on the iPhone it was just intended to augment the native experience. That's how I see it, at least.
More similar to the (initially announced) Palm Pre. It was supposed to be a device which runs Web Apps natively, and you write your applications in HTML + JS, using their "Mojo". Well, developers weren't having it, so they eventually allowed C / C++ as well. I'd predict the same with this device. Since it's running Linux kernel, I can pretty much guarantee that you will be able to run C / C++ apps on the device, and developers will choose that more often than not.
You didnt have to write them with Mojo, you could write them with any HTML/JS framework, or just roll you own. Mojo was just the one the Palm apps (Email, Web, Phone, ..) used.
And a vast majority of the apps for the platform used it for UI. C/C++ was generally only used for games ported from iOS to webOS, or when writing a custom plugin for some capability not provided by the service architecture.
C/C++ was allowed, but definitely not chosen "more often than not" on webOS. The UI for a vast majority of the apps was HTML/JS and using Mojo.
There are probably millions of soon to be unsupported devices, N900 (already left behind), N9 and N950 that could conceivably run this. After all, N900 can run open office and it is the oldest of these devices.
It would be much easier to test and contribute if one had a device already to properly experiment with. My N900 is gathering dust and there is no good replacements for its OS.
In terms of getting 'official' support (meaning Mozilla employees working on it for real, I guess), I don't know how likely that is. But that said, it's all actually open, and porting it to other devices is not just ok, but encouraged -- I don't know about anyone else, but I'd love to see this running on other devices, and have some plans for some personal projects along those lines myself, when I have some spare time.
web standards is greate but what if I want to port my multiplayer game that uses bluetooth for the communication between devices. How will B2G handle bluetooth and can my B2G app use it?
This is where we're gathering the tasks for the project. It's still hardly implemented right now, and our main focus is headsets first. I'd like to get rfcomm going pretty quickly too so we can do fun hardware experiments. :)
In general, if you're interested in the progress of something on B2G currently, just plug "b2g [word of interest]" into http://bugzilla.mozilla.org. That's where we're keeping tasks/bugs related to gecko internals.
WebBluetooth is being worked on based on the WebAPI spec. https://bugzilla.mozilla.org/show_bug.cgi?id=674737 It's fairly early still, but the goal is that you'll be able to (given permission) use Bluetooth from your apps just like if you wrote them natively.
I'm curious about b2g's security model but I haven't been able to find much of substance about it. Currently I'm pretty sure if you beat gecko you own any firefox tab that's open. Does that mean if you beat it on the phone you own the whole thing?
Until I use this, I'm going to hold off on the excitement everyone seems to have for it.
The tagline is "The Device the developer community is waiting for." That's great for the developer community. Unfortunately, the developer community is a small minority of people and honestly, people don't really care if their device is easy to develop for. People care how good their device is. If a device is easy to develop for, but it's slow, or clunky or crashes all the time or doesn't have features that people expect out of a mobile device, what's the point?
> That's great for the developer community. Unfortunately, the developer community is a small minority of people
I think you underestimate the amount of influence developers have on the rest of the population. If you get developers to love you by making their jobs that much easier, they will go out of their way to promote your product and get other people to start using it. It's in their profit-minded interests to see to it that your product succeeds, because if it doesn't, then they have to bear the costs of doing things the old way.
The quality of the product matters, too, and we'll have to see if this will be a high-quality product. But there's something to be said about getting developers on your side.
I understand your point but I don't think it's as influential as you make out.
First, you're assuming that developers have (sufficient) influence over swathes of non-developers. I'm not sure that's true, especially in the case of hardware.
Second, it's in developers' "profit-minded interest" to get their stuff on every relevant platform. It's where the customers are that matters.
Finally, no matter how good the product is, I doubt any technically capable folks (not just devs) want to end up as the de-facto 'tech-support guy' for all the people they convinced to sign-up.
Personally, I have not been waiting for another Html driven platform. I don't like Html/Css as a UI framework, I just think it's highly overrated.
Things I like better: Qt/Qml, Wpf because they are much more precise (meaning, I don't have to use an opaque type like "DIV" as a placeholder for a list-view or something else that I really wanted).
I don't necessarily think HTML and CSS make for good languages to design UIs with, but it beats the hell out of learning a new language, stack, and tools. I can use mostly the same tools and workflow to create apps as I would for making sites. That's one reason I can't wait for Windows 8. The promise of HTML5 apps, even if they're using IE as the runtime, is friggin sweet.
I'm amazed how quickly they seem to be moving this. It wasn't that long ago that I first heard about Boot2Gecko (the wiki page is from last July), and now they already have some hardware partners and operators lined up. Quite a difference to the momentum behind MeeGo and Tizen...
I guess a big difference is that the driver here is Mozilla, a foundation that most players in the field don't see as a direct competitor, and which already has a very good name in the web space.
This is actually a big deal. It is a step in the right direction to take care of the missing pieces of mobile app development. I really believe that in 5 years time, "application development" will be just assumed to be web app development and not desktop application development.
Yep, it may not be in 5 years but it's only a matter of time, no matter what native app developers would like you to believe. If we learned one thing from desktops, it was don't underestimate the web. Good to see things start coming back full circle with the mobile web.
I disagree. The thought of maintaining an app with a large code base written in JavaScript doesn't seem like a "step forward" to me. I'd much rather stick with my Android apps object oriented code base and associated tools.
I've been rewriting my latest released Android game in Html5 and Coffeescript for PhoneGap, which lets me deploy on iOS and Android, plus Blackberry and other platforms, but I'm focusing on iOS and Android for now. I'm doing that because I need to make an iOS version, and would rather spend my dev time adding more features or developing more products rather than redeveloping the same product on multiple platforms. This approach also opens me up to the possibility of having a web version, perhaps a Facebook and/or Google+ module. I'm astounded on how much smaller my code is in Coffeescript than Java. It's about 1/2 the size of its Java counterpart.
Many people will of course not move on to HTML5 app development. Every time technology changes, lots of people don't migrate. But it really is an amazing way to go. Coffeescript solves a lot of problems and makes the code very small. Jasmine unit testing helps with the scary feeling of not having type safety. PhoneGap lets you deploy it as a native app. Chrome has a surprisingly awesome stepping debugger built right in. Vim + the cofeescript plugin automatically compile the Coffeescript every time you save. The difficulties of debugging in Coffeescript are mostly overstated in my experience, and countered by the feeling that I'm developing code faster than I ever have before in any other language.
It's not all cake and ponies, and I've had to figure out a number of things. But it's a really fantastic way to develop apps. Try it.
I for one am very excited to see B2G finally ship. I'm anxious to see how well this OS performs and how well thought out is user experience is. I trust Mozilla, they build quality products. The competition is fierce though and the carriers ultimately have too much power here in the US. I really hope B2G is committed to competing in the mobile arena.
"Qualcomm currently delivers the chipset for a large volume of Android based smartphones, which is the DNA of the device. By tightly integrating the Open Web Device with the chipset we will guarantee that any OEM will be able to manufacture a device with very little effort: it will be almost a plug & play procedure."
I think this is a bad idea. Why would you want to lock down the hardware at such an early stage?
Maybe it's prejudice, but I feel uneasy with their connection with Telefonica, after seeing so many Spanish users (including some family members) complain about them
Same can be said about AT&T, Verizon, O2, DTAG/T-Mobile, Rogers, etc. There's no universally good telecom, and someone is always going to be complaining about them.
WebOS also has its own framework. As far as I understand this is about standard web applications (i.e. framework agnostic). F.e. you could build your app in jquery-mobile and make your app communicate with the device through a JavaScript API.
This seems a lot like a webOS with Gecko instead of webkit. This seems interessting as I hope the projects open webOS are building are going to be on which both plattforms can build on.
Doesn't support + signs in email addresses. Awesome. Does not inspire confidence in a platform that is based on internet standards, where email is an important part of communication.
You're right, if they left out the + sign on the beta keyboard UI they probably forgot all the calls to free(), WebSockets, and maybe CSS. Outlook is bleak.
I've always seen mobile web apps winning over native mobile apps in the long term. Jacob Nielsen described as much last week as well but was careful not to put a timeline on it.[1]
Hopefully this project helps make it happen sooner than later.
I hope that some sort of support for inter-app linking is supported.
One of the biggest problems with native apps on iOS and Android is support for moving from one app to another, but still allowing the user to easily return to the originating app.
At the moment, the only native support for this kind of feature that I can think of is maps support. For example, if you click on a Google Maps directions link on OS X, the Google Maps application is opened automatically instead of maps.google.com in the web browser.
Dunno if this would require a dedicated link button that remembers the app you came from to take you back there or not. Perhaps there is a more elegant solution. It's possible that Hypermedia JSON APIs could play a role in helping people move between apps.
Whatever solution is adopted, making it easy for the user to return to the originating app with ease is of utmost important, because this will create an environment where app developers will fill comfortable partnering with other app developers by including inter-app links.
This is about creating an open standard for APIs a phone OS would need to implement so that pretty much any app people have on phones right now can be implemented with web technologies (HTML, CSS, JavaScript). Essentially, any web page can be an app; apps that need access to some sort of hardware capabilities that web pages don't normally have access to would need to have a permissions system of some sort, of course.
It's also about then shipping actual phones with an OS implementing these APIs installed, creating an "app store" to aid in app discovery and whatnot and whatever other pieces of infrastructure are needed to actually get this open standard used.
One long-term goal, of course, is being able to switch phones (or carriers, or phone OSes; whatever choice the consumer wants to make) without losing all your apps; hence the need for an open standard.
Isn't this exactly the same as Google Chromium[1]? Boot a minimal OS and load a web browser to do all the heavy lifting. Don't get me wrong, I think doing it in the open is much better than behind closed doors, I just want to make sure that I'm not missing something.
It looks like all "apps" are web pages. I'm looking forward to seeing how well they can make it run things like Angry Birds.
And how well they deal with background tasks. On Android I can upload my photos in the background, or play music through Spotify (or my MP3 app) while I'm doing other things. Will I be able to do similar things here?
And how well they deal with security. I look forward to the day when a malware-distributing webpage can pwn millions of phones without being detected...
> And how well they deal with security. I look forward to the day when a malware-distributing webpage can pwn millions of phones without being detected...
Exploits are always possible on any platform, of course, but the web is sandboxed by design and has been hardened against attacks for many years. It's as secure or more than other platforms like Java or the iOS app model.
MY first reaction was about security as well. This change of paradigm is a recipe for disaster if security is not considered from the beginning because most of the assumptions change. If it's not done carefully (things like segregation between apps, access control to privileged JavaScript, etc)... it is going to pretty painful.
Firefox already has all that. A good part of the browser is written in JS which runs with high privileges (full filesystem access, full network access, etc) while the code on websites doesn't. It already has systems for unprivileged JS to request access to certain privileged APIs (location, localStorage, etc). "Apps" - websites - are already segregated and run in their own sandbox.
I know, and we have constantly lived along the edge of the cliff because of that. From a perspective of security it was a very poor design decision. By making those decisions you create a big security burden, the attack surface is very large, the impact of bugs is very large. These are the types of security consideration that have to happen at design time. In this case I would like to know more about, maybe it's being considered but not being discussed.
How is this any different than a popular app on the Android Market or an exploit in the same webpage affecting Mobile Webkit. This seems like a really random absurd scenario.
I guess the question is how they highlight things so I can easily switch back to the app that's playing the music, so I can pause it when necessary, how much space they make available to individual apps (I have about 5GB of music on my phone at the moment for Spotify), and what the model is for apps sharing data (so I can download a photo in one app, change it in a second one, and upload it with a third one).
I'm looking forward to seeing what their equivalent of "intents" is.
"HTML 5" has the web workers API for background tasks. They don't work while you visit other pages, though. I guess they'll have to introduce a new API for that.
How is this going to handle updates? Obviously the UI/html5 portion will be trivial to update, but Firefox gets updated every six weeks. Is the system core going to lag behind the rest of the Firefox ecosystem, or ami I going to have to rely on my carrier or manufacturer to push out system updates every six weeks?
I see updates as being crucially important as all the system functionality is exposed as html/css/javascript.
I'm also curious how/if they sandbox the device's browser and still keep within their proposed paradigms. Is a malicious website going to be able to exploit my system using XSS?
I'm curious about this too. The FAQ mentions they will update the core browser like Firefox normally does, but I wonder if that means they also need to update the web browser frontend (written in HTML/JS) at those times as well.
I would also like to find out how this is planned. Ideally a Chrome-style auto-update would be great. The bane of mobile web application development is dealing with the lowest common denominator - developing for multiple Android versions is especially painful. Anything to prevent fragmentation will be a good thing, as we all know carriers won't bother updating very often, unless they have a good reason to do so!
Last time I checked, Gecko and all the other browsers still had a long way to go before being fully HTML5 compliant. Chunks of the File API, postMessage, and a variety of other specs are incomplete and underdocumented.
Sites like caniuse.com vastly overestimate what has been sufficiently implemented.
Chrome Apps can use non-standard technologies (WebSQL, for example; and soon Dart), so they won't work in other browsers. In fact, some of those nonstandard technologies won't even work on Chrome when running on another type of device (NaCl apps will not run on ARM).
Though, to be clear, it should be easy to write a single app that works as both a Chrome app and a B2G/Firefox app, as long as you use APIs that work across both environments. (Chrome apps can access non-web-accessible APIs, but they don't have to.)
Wow. Judging by the number of nay-say commenters, it's obvious they should have included a hands on video. Sadly each one I've found seems to be a fairly different build. The one The Verge has is decent.
While I think the idea is interesting, I will say what I always say in these situations:
Talk is cheap.
I wish people would announce projects when there is actually something to look at rather than just having a vague list of goals. It's like the "I have a great idea for an app and just need somebody to do the software development". I always like to think of products consisting of 15% Idea and 85% implementation.
