

Mozilla Gains Global Support For a Firefox Mobile OS - cheeaun
http://blog.mozilla.org/blog/2012/07/02/firefox-mobile-os/

======
cs702
Very exciting. In my view, Firefox Mobile OS has a much better chance of
gaining broad adoption than Windows Phone, Blackberry, Symbian, Tizen, and all
other non-Android, non-iOS platforms, because its native applications are
built with HTML5 and related technologies that have _already_ been embraced by
developers worldwide.

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.

~~~
shmerl
It's still using Android graphics stack, so it's not that exciting. Tizen at
least uses X.org with plans to use Wayland which is the way forward. I hope
Mozilla will find vendors to use Wayland for B2G as well. I.e. Android
graphics stack (when it's the only option) prevents device from being
hackable, i.e. for porting other distros on it (Mer/PlasmaActive, Nemo etc.).
Tizen devices with X.org/Wayland drivers will be better in that regard.

~~~
edderly
On the contrary this is the smartest thing they could have done. GPU h/w
acceleration on mobile devices isn't optional any more and rather than getting
mired in the 'real soon now' world of Linux graphics they can get on with the
job of producing real and usable devices.

~~~
shmerl
I'm not saying that what they did isn't useful at all. I said it's not
exciting, since these upcoming devices will be again Android (compatible)
only. Rather boring, but it's not Mozilla's fault, but manufacturers'. They
don't produce open specs for their hardware, and don't provide X.org/Wayland
drivers either.

------
nicpottier
To me this is one of the most exciting projects coming up. it is still in
early, early days, but it seems to pose the most realistic sane alternative to
Android and iOS.

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.

~~~
daleharvey
Right now the Samsung galaxy s2 is your best bet, the lack of hardware
keyboard hasn't been accounted for in b2g afaik

~~~
nicpottier
Really? The GN is listed as one of the supported devices on their page.

Would rather drop $350 than whatever an unlocked S2 would cost.

~~~
MatthewPhillips
I put B2G on my GN and he's right. Once you get into an app there is no way to
return to the home screen. You have to pull the battery out and reboot (which,
by the way, is the fastest boot I've seen on a smartphone).

Also there are viewport issues with GN. Everything looks zoomed out. Those 2
bugs makes it not really very usable at this point.

------
stevenwei
I've repeatedly seen HTML5+JS claimed as some kind of panacea for easy, cross-
platform application development, but don't really see how it is possible,
particularly on mobile devices.

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.)_

~~~
asolove
This scrolling trickery is absolutely doable in html/js. A friend of mine
wrote an infinite-scroll table that will handily display tables of tens of
thousands of rows. It carefully only requests the right data from the server
(with lots of cacheing and prefetching, of course) and only ever instantiates
2*n (n being the number of rows visible) dom elements and just pops them in
and out of view.

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.

~~~
asolove
So as one data point in this comparison, I have a pretty good version of a
scrolling grid plugin that swaps in and out existing row dom elements as
needed and loads that data dynamically from a backend. It's not totally done
and not ready to open-source, but it's generic enough that another day or so
of work will make it so.

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.

------
jan_g
I am worried by this:

>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?

~~~
forgotusername
Differentiation is a huge selling point for the operators, and will likely
remain so as the majority of regular users don't really care about the
branding (or, if anything, may feel more secure seeing the operator's logo).

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.

------
mrschwabe
This is the right strategical move for Mozilla.

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.

~~~
Yoric
_IMO, their first mistake was not-launching an open source search engine to
compete with Google (pre-Chrome era)._

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
:)

~~~
mrschwabe
It's true, but they above anyone else _were_ in the greatest position to do
it.

[http://nerdbusiness.com/blog/mozilla-launch-open-source-
sear...](http://nerdbusiness.com/blog/mozilla-launch-open-source-search-
engine)

Either way, the ship is sailed - DuckDuckGo is now leading the way in this
department.

~~~
hollerith
>they above anyone else were in the greatest position to do it.

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.

~~~
mrschwabe
Its true but back in 2008 the contract they had with Google was up for
renewal. This was a window of opportunity for Mozilla to make a 'clean break'
from Google.

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.

~~~
ngokevin
Google and Mozilla are not enemies. They are both allies towards an open web.
Sure there's the media-hyped browser wars, but Mozilla is about freedom of
choice on the web. They are a non-profit who uses Firefox as a playing card in
order to further the web. That's how it all started. Microsoft halted
development of IE because they saw the web as a threat and Mozilla stepped in.
It's never been about the money.

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.

~~~
bzbarsky
Mozilla and Google are allies towards an open web only insofar as Google has
that as a goal.

Unfortunately, they have it a lot less as a goal now than they did a few years
ago....

------
cpeterso
Building B2B on an Android kernel was clever. Mozilla can leverage all the
Android hardware support implemented by device OEMs and ongoing kernel
maintenance by Google.

------
reirob
While I am exited about this project, I wonder what are actually HTML5 apps?
Where will users get them (will there be some market and who will operate it),
will they work online? How are they installed?

~~~
Yoric
As far as I understand, any combination thereof:

\- 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.

------
bdg
Are we one step closer to the mozilla seabird?

[http://www.youtube.com/watch?v=oG3tLxEQEdg&feature=youtu...](http://www.youtube.com/watch?v=oG3tLxEQEdg&feature=youtube_gdata)

I wish, but realistically that phone would probably cost $6k today.

------
ozarius
This is exactly the kind of push that HTML5 needs to gain a solid footprint.,
and dev mindshare

~~~
flatline3
Disagree. What HTML5 needs is a common set of widgets, usability guidelines,
and artwork that make it easy to produce applications that users will enjoy
aesthetically and understand how to use implicitly.

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.

~~~
Yoric
_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._

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 :)

~~~
flatline3
I think there are at least two problems with using DOM/CSS/JS as building
blocks:

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.

~~~
Yoric
Well, your first point is again "let's not use assembly language, it lacks a
standard library". Yes, the remark is true, but this just means that we lack
higher-level tools above DOM/CSS/JS.

For your second point, I somewhat disagree. JS is now quite efficient. Not
CUDA fast yet, sure, but much faster than, say, Python, VB, and often much
more memory-efficient than Java. To the point that some video games have been
automatically recompiled from C/C++ to JavaScript (through Emscripten) and
work quite nicely. Similarly, DOM/CSS are inefficient for really low-level
stuff, but suddenly become pretty efficient for animations, for instance.

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.

------
lalmalang
It was kind of interesting comparing the quotes from the various network
operators. For instance, this management-speak gem could apply to any product
at all:

"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]

------
thechut
That digital mockup looks a lot like an iPhone...I'm sure it won't be long
before Apple claims that this free software is causing them irreparable harm
and moves for an injunction banning anyone from downloading the Mozilla OS or
purchasing devices from ZTE.

Sarcasm...but just barely

------
moondowner
An exciting development indeed, but I'm afraid what will happen if the phones
have bad build quality and how will that affect it's popularity.

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.

------
anuraj
HTML5 enthusiasts - this is your chance (and probably the only one) to prove
that it is suitable for mobile. iOS and Android are remaining native.

------
FlyingSnake
B2G looks like a viable alternative to Android/iOS.

Any information on how stable/usable the B2G project is for daily use?

~~~
daeken
I'm a B2G developer and while it's definitely getting close to being usable on
a daily basis, there are gaps. Due to the fast pace of development, it's not
uncommon that things like the camera or telephony stack will break in an
update; we're constantly putting in new optimizations and features, and
breaking stuff is okay for us in the short term. Overall, it's pretty damn
solid, but expect breakage frequently while things are moving this quick.

~~~
mikeevans
Which phone do you use?

~~~
daeken
I use quite a few, but my primary devices right now are the Galaxy S2 and the
Nexus S. I work primarily on the gfx side of things, so I try and test on as
many GPUs as I can get my hands on.

------
flocial
In this case global support means the multi-national mobile telecoms of
industrialized nations. In other words, all the mobile providers scared of a
world where Apple, Google, and Microsoft call the shots and squeeze the profit
margins that used to be protected by government bandwidth licensing.

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.

------
brackin
I think this is very exciting and I love that they're targeting the cheaper
market and also emerging markets where Android, iOS and Blackberry tend to
cost too much and Symbian is losing marketshare.

------
justauser
Will the Rust Language be a fundamental part of this project?

~~~
joshmoz
Not any time soon. However, presumably if/when our rust-based rendering engine
is ready we'll use it for the Firefox OS.

------
fauigerzigerk
I like the idea. I just hope they can get some more convincing hardware
partners on board.

~~~
gkanai
When you say "more convincing" who are you referring to? Remember, the goal
here is not a $500 smart phone. The goal is a smart phone that can sell in
emerging markets for a price a fraction of what a new iDevice or top-of-the-
line Android phone goes for.

~~~
wmf
It seems likely that an all-HTML OS will be slower than Android, so either
Mozilla phones will cost more than Androids or they'll just be slow. I don't
see any way to make B2G cheaper than Android, which is already free.

------
soapdog
OMG! Brazil is going to be first on something tech... so good that I live in
Rio!

------
aeurielesn
I hope the mobile OS doesn't blackout as the Firefox navigator tends to. I
lost all hope on Firefox because of this behavior.

I don't know if this has been fixed. But anyways, I won't go back to Firefox.

~~~
AndrewDucker
This is somewhat of a worry - I love Firefox and use it all the time, but it
does freeze up occasionally for a few seconds. Which is acceptable in a
browser, but completely useless when making phone calls.

~~~
daeken
So, one thing that myself and others on the team have been working on is
moving things out of the main thread/process. There's a big push by the whole
team to get everything working cross-process, so that we can start separate
processes for each application; that should let us mitigate the problem of GC
pauses and the like. One other big push is making everything off-main-thread
composited. That lets the graphics work happen more or less independent of the
main thread, and frees it up to do standard processing, in addition to letting
animations and the like run async (much smoother).

There's a lot of work still to be done, but those pauses should go away over
time.

~~~
AndrewDucker
That's fantastic news. I've been very impressed with the amount of
improvements Firefox has been undergoing recently.

~~~
daeken
I should point out that this work is mostly specific to Boot2Gecko. A lot of
it is shared with Mobile Firefox, though, and a good bit of it will probably
make its way to the desktop eventually as well, but I honestly have no idea on
that count (I don't work on Firefox proper).

~~~
AndrewDucker
I hadn't realised that the codebase was so different. How much code is
actually shared between B2G, Mobile and Desktop?

~~~
daeken
Quite a lot. I mean, it's the same Gecko core, but there are a _lot_ of pieces
to Gecko. Mobile and B2G both use the same EGL backend for gfx, but they use
different widgets and some different optimizations (e.g. we know that we have
permissions for gralloc on B2G, so we don't use a tiled backend). Desktop and
Mobile/B2G share the layout, JS, etc but you've got all sorts of different gfx
backends that could be used. Same code, just a lot of divergent pathways.

~~~
wodemaye__
Woah dude, that's gotta be damn exciting. Good job.

(It's me from freenode :b )

