From users' perspective, virtually the entire universe of existing HTML5 applications that work on small screens will be native apps for the platform -- from day one.
And if you are interesting in writing web apps specifically for the B2G platform, check out the new web APIs being proposed and implemented in B2G, and give us feedback on any that you use in your app: https://wiki.mozilla.org/WebAPI
Edit: if you're going to down vote please explain why
The patches have already landed in B2G: http://bugzil.la/714408
Edit: originally I listed the wrong nexus model
If this has changed, I'm really, really excited. :)
(I work on the gfx pipeline for B2G)
Edit: Oh yea, and we use Android's libegl wrapper stuff. Not that it matters, but just in the interest of correctness.
On the other hand, if X.org/Wayland based devices will appear (like upcoming Mer/Vivaldi tablet), Mozilla can enable B2G to run on them as well, since they'll provide sufficient support for OpenGL ES.
Parenthetically, Google Chrome already has an alpha-quality port to Wayland whereas to my knowledge Mozilla has made no commitment to support Wayland, and no one has started porting Firefox to Wayland.
Just instead of any Android layers, it'll use OpenGL ES provided with Wayland stack.
Hopefully vendors will care enough about Wayland to start making their drivers compatible with it.
By opposition, every application on Firefox OS is based on either standard HTML5 or currently-being-standardized extensions. This means that Firefox OS apps should be cross-platforms.
Edit: see also http://news.ycombinator.com/item?id=4189634
In effect, this means that webOS has almost all the drawbacks of working with HTML5 (no static analysis, performance often difficult to predict, etc.) but none of the benefits (cross-platform, ability to use CoffeeScript or GWT or OCaml or any other language that compiles to JS).
By opposition, Firefox OS apps are cross-platform, can be developed with any tool, etc.
edit Yes, it is possible to write apps using standard HTML5 for WebOS. What is impossible is to write apps using standard HTML5 for WebOS that take any advantage of WebOS (sending SMS, receiving phone calls, etc.). By opposition to Firefox OS, in which even SMS, phone calls, etc. are based on open standards.
Now available for desktop and cross-browser development
- Enyo 2.0 now runs across mobile environments and desktop browsers including Chrome, Firefox, and Internet Explorer
IIRC, WebOS also had APIs for, say, sending or receiving SMS, vibrating the device, etc – and none of these were (or are) standardized.
I mean, if they are unique to devices for which they make sense (i.e. phones) than webOS' APIs seem to be just as standard.
What I was pointing out is that EnyoJS or WebOS or Tizen (afaik) do not make any effort at such portability. Sending a SMS makes as much sense on a WebOS-based device as on an iPhone, an Android smartphone or any other platform. This is one of the key differences between initiatives such as WebOS, Windows 8 or, to a lesser extent, Chrome OS on one side and Firefox OS on the other side. While these OSes offer the features of HTML 5 and some proprietary, non-standardized, non-portable extensions APIs for taking advantage of platform-specific capabilities, Firefox + Firefox OS push to make these capabilities
1/ accessible on all platforms where they makes sense;
2/ standardized so that other browser or os vendors can implement them as they see fit.
The difference is subtle but meaningful. This is the difference between "come and program for my silo platform" and "come and program on everybody's web platform".
That is incorrect. Apps written for webOS that use the EnyoJS framework are currently seen running on iOS, RIM (Playbook), Android, and even in the Chrome web browser.
In other words, while EnyoJS may be cross-platform, it represents only a small fraction of the features of WebOS.
Android is great in that they are open, but their UI library is really just a mess, anybody who uses it for any amount of time yearns for the days of laying things out using HTML. iOS is much better in this respect but has the problem of limited devices and of being a closed platform.
I have no idea how they B2G (Boot2Gecko) will navigate the patent minefield, but I hope they do. I'm picking up another Galaxy Nexus just so I can have a phone dedicated to hacking on it.
Historically, HTML has hardly been much better in enforcing UI consistency. Mozilla may have some tricks up their sleeve, I don't know.
While a specific framework enforcing consistency might eventually appear, I do not think that this is the purpose of Mozilla or Firefox OS itself. Probably more the purpose of the companion marketplace.
In other words, I hope Mozilla can strong-arm the hardware partners into actual community-minded open source, rather than whatever the hell Android is doing. (I don't doubt Mozilla here, but their partners.)
And maybe for manufacturers too. Some manufacturers are concerned that Android and Windows Phone are becoming more siloed, given the Motorola deal and the MS-manufactured Surface. So the timing might work well for Moz, but like you say, there are patent questions.
Would rather drop $350 than whatever an unlocked S2 would cost.
Also there are viewport issues with GN. Everything looks zoomed out. Those 2 bugs makes it not really very usable at this point.
Both the Android and iOS SDKs are pretty specifically optimized for performance on their respective devices, and I don't see the need for those types of optimizations going away anytime soon. As an example, take a UITableView (iOS) or ListView (Android), backed by a SQLite data store that has returned 2000 rows to display.
It's not actually feasible (for performance & memory reasons) to simply render all 2000 rows and allow the user to scroll through them. Instead, both the UITableView & ListView recognize that on a phone, there's only really enough room to display 5-6 rows anyway. So they instantiate those 5-6 rows and populate them with the first few rows from the result set. Then, as the user scrolls down, additional rows can be loaded in, and the previously used rows (that have now been scrolled off-screen) get recycled to represent new rows at the bottom of the table view. Additionally, the data for each row can be loaded on-demand as the user scrolls the row into view, and then be freed once that row has scrolled off screen.
It's a nice and tidy optimization that is absolutely necessary on both platforms (failure to implement the recycling mechanism can basically kill your scrolling performance). That is just one example, there are many more optimizations developers make to keep their apps smooth and responsive on iOS/Android, and a lot of those optimizations involve relatively low-level interaction with the underlying GUI toolkit.
I don't think these types of optimizations are feasible when writing HTML+JS apps, they're simply abstracted too far away from the underlying GUI toolkit. (Some might even say that layer of abstraction is the entire point of using HTML+JS in the first place.) Regardless, I think it severely limits the scope of the types of apps you can create using HTML+JS.
And I haven't even mentioned games, or apps that do any sort of audio/image/video processing. (Even on the web these are often relegated to Flash.)
I think what you are saying that is correct is: UI developers as a general rule do not go to this level of detail, either on web or on native.
But on native, the frameworks have already done these kinds of optimizations for us. I think that's just a matter of the SDKs having more manpower and motivation for making it easy to build apps on their platform.
I actually have a semi-related project right now, so I'm going to go write a Backbone collection smart-scroll plugin that deals with the smart data loading and clever element rejiggering. Thanks for the suggestion.
HN records that my original comment was posted 21 hours ago, and I assure you I spent a good deal of time sleeping and eating inbetween, so this is definitely doable in html/js.
Now, as to the bigger point, that most developers don't know that they should do this to get performance, or that we shouldn't have to write it ourselves, those still stand.
>Due to the optimization of the platform for entry-level smartphones and the removal of unnecessary middleware layers, mobile operators will have the ability to offer richer experiences ...
So, can we expect that mobile operators and/or manufacturers will yet again put junk on the phones?
What counts as junk is in the eye of the beholder; the stock ROM that shipped with my Nexus One came with Facebook pre-installed, something that 18 months ago would probably have been seen as a benefit for the average techie nerd type. Thankfully I uninstalled it via Titanium Backup before they rewrote my address book.
I don't see any reason to worry about this, or why it might differ from the Android experience any. If anything, Mozilla is more of a purist company and rules around what may be shipped on a co-branded handset should be a little stricter than what Android had.
However since they are the new entrant, I wouldn't be surprised if they bend over backwards to whore the new platform to the carriers until such times as they have an established market segment with which to negotiate better terms. If this is the case, and the platform is a success, I would count on Mozilla to deliver a purer experience in the long term.
By putting gecko directly on top of a linux kernel, mobile operators can deliver great performance on lower hardware specs.
I think they made a mistake to wait this long to do something new and bold, but at least now they are on a solid path.
IMO, their first mistake was not-launching an open source search engine to compete with Google (pre-Chrome era). Second mistake was waiting too long to get this Mobile OS out the door (which is still a ways off it seems).
But this is definitely promising. However, I can't help but wonder about the missed opportunity for collaboration with Canonical. Its clear that Canonical is on a similar mobile trajectory for Ubuntu. An Ubuntu / Firefox Mobile OS would have been cool; and arguably a stronger force to compete against Android/Chrome and iOS.
Do you have any idea how much it costs to run a search engine? Well, to be true, neither do I, but I am sure that this is a scary amount of money.
Plus Mozilla does not have to be (and is not) the only herald of open-source :)
Either way, the ship is sailed - DuckDuckGo is now leading the way in this department.
Huh? They have been getting most of their revenue from Google. Seems to me they have been among the least able to start a competitor to Google Search because Google can respond by cutting off most of their revenue.
Instead, Mozilla took the money again. And within only a few weeks Google announced Chrome. Convenient timing for Google since the multi-year deal with Firefox was already in place.
So my argument was that back in 2008 Mozilla should have NOT signed any further deals with Google, who was ironically about to become their biggest competitor. Instead, they could have taken the offensive and focused on rolling out a search engine of their own to go toe-to-toe with Google. Of course, its all hindsight now. But at least they're stepping up to the plate now with the HTML5 mobile OS.
Besides, taking on Google, who accounts for over 90% of Mozilla's cash flow is foolish, especially when Mozilla is a team of 650 and Google is a giant of 30,000 (not to mention in a totally different product). But that's besides the point.
Unfortunately, they have it a lot less as a goal now than they did a few years ago....
- Mozilla has an (open-source, open-standards-based) market technology, that can be deployed both by Mozilla, by operators and by whoever wants to;
- any web site could come with the option to install itself as an application, this only requires a few additional files and/or metadata.
The DOM/CSS/JS is a crappy, low-level, do-everything-yourself model for creating applications when compared to the state of the art in native UI/application frameworks. The result is a hodgepodge mishmash of broken, inconsistent application UIs.
Couple that with the inability for any existing browsers' JS runtime to make use of SMP in a single app (despite devices adopting multicore ARM), limited uptake of WebGL, no support for dropping to NEON or even just C (you pay for inefficiency with battery life and poor user experience), etc.
I'd rather see Google produce a NaCL-based set of application libraries that can run on both their Android phones, ChromeOS devices, and our existing desktops. Mozilla's insistence in continuing to invest in pure HTML/JS/CSS is myopic.
Well, yes and no. This is a bit like saying that assembly language is a crappy, low-level, do-everything yourself model for creating applications, so that we should not use any language that compiles to assembly language. DOM/CSS/JS are just the brick-and-mortar, there. People are smart enough to build great stuff with them.
Awful stuff, too, of course, but we can just throw it away :)
1) It discards the network effects/value of having a common, regularly updated platform, shared across all applications.
2) DOM/CSS/JS are terribly inefficient building blocks in terms of processor, memory, graphics. Why waste resources on overly high-level building blocks that we just plan to abstract away.
If those building blocks are going to be abstracted anyway, then maybe we should just skip them. Should we build on top of canvas or WebGL instead?
Apple's accessibility work demonstrates that it is still possible to make native UIs be text-navigable/indexable/structured, which seems to be one of the biggest arguments for keeping the DOM.
And, really, the biggest argument for keeping the DOM is not technology, but community: many people know how to use it to do cool stuff.
But yes, canvas + JS or WebGL + JS are also available, for applications that require them.
As for working with designers, no, I'm not a designer, but I find that implementing designs in iOS and Android native tools is far easier than attempting to jimmy HTML+CSS into implementing the behavior and layout as provided by a designer.
In the world of views, I can simply position them where I want and apply arbitrary logic to how they move, scale, etc. This makes it tremendously easier to implement complex designs than straight HTML/CSS.
eg, this would be equivalent to:
tableCell.textField.font = [UIFont ...]
I wish, but realistically that phone would probably cost $6k today.
"Etisalat aim to enrich the user experience and improve the life of its customers by providing enhanced services across a complete portfolio of devices and operating systems. Firefox OS will provide an open source platform to our customers and various ecosystem players, such as application developers, to experience innovative services. Thanks to this strategic initiative, the industry will benefit from a sustained growth in mobile data and the development of cutting edge applications, as well as the promise of affordable smartphone devices that provide an enriched customer experience."
[edit: off-topic, i know]
Sarcasm...but just barely
I've had an Alcatel phone and it's.. I don't know how to say, but Huawei is a better manufacturer than them now, so get the picture.
On the other hand, I have a hard time comprehending how a platform like Mozilla that's slow enough on desktops can make headway in the mobile space. Clearly WebKit is ahead of the game and is open source as well. I'm reluctantly using Mozilla on the desktop.
HTML5 technology is the future of browsing for sure but lets not turn it into the Java of mobile technology. Native apps have a proper place just by virtue of the performance gains. Putting everything on HTML5 is not only expensive in terms of bandwidth but also processing power, therefore a battery drain. The bandwidth and more importantly the battery are the Achilles heel of mobile.
Also, where does this leave developing countries that are far behind and mainly surviving on WAP phones?
I just find the framing of this press release as nothing but unwarranted hyperbole that is more an corporate alliance where your enemy's enemy is your friend.
Any information on how stable/usable the B2G project is for daily use?
I don't know if this has been fixed. But anyways, I won't go back to Firefox.
There's a lot of work still to be done, but those pauses should go away over time.
(It's me from freenode :b )
I haven't recreated my profile in a while, possibly time to give that a go.
A quick verification can be to start Firefox with the -profilemanager flag and create a new profile, and verify if it does or does not occur in a completely fresh profile.
In my case, pauses came from FoxyProxy regular expression pattern matching on urls where I was using:
This mostly applies to the Marketplace in how it offers paid apps; we have a decentralized receipt format to let the paid app run on any platform. Unlike any other mobile player, Mozilla is truly making the web the platform. Our platform is not Firefox OS. That's just one device to support open web apps.
"Gecko on top of it. The same version you'll find on a regular Firefox;"
Maybe we're confusing web standards with rendering engines, but this is a product with only one rendering engine.
- Gaia, the top layer, is meant to be engine-agnostic;
- Boot-to-Gecko / Firefox OS, the complete project, is not.