On Tuesday, February 17, 2015 at 8:34:44 PM UTC+10, Fabrice Desré wrote:
> I agree with Dale here.
> 
> Also, we can't afford to wait for standardization to happen to move
> forward. 

Why? what do we win by creating a proprietary ecosystem whose apps don't work 
anywhere outside a relatively tiny set of devices? specially when the web at 
large (hell, even our own Firefox browser) doesn't benefit? Wouldn't improving 
the overall capabilities of the web be a much more worth while investment? If 
the web doesn't improve along side, then what do we gain by "moving forward" 
(what are we moving forward)? 

Put in perspective: there may be say, 10,000, hell even 100,000 proprietary 
apps in our market place one day - but there are 200,000,000+ active domains 
out there that can be accessed today because of cross-browser standardization. 

I'm not saying we shouldn't move forward on the OS: sure, do that, but not with 
an eye to creating yet another platform that competes with the Web for 
developers. 

> It took *many years* to come up with a solution to the offline
> issues with Service Workers. 

So? We are talking about solutions that need to work at "web scale". I.e., 
these are solutions that need to work well for 10-20+ years, across multiple 
browsers, touching billions of people - so it makes sense that these APIs are 
not gonna be slapped-dashed together in a couple of days. We don't have the 
luxury on the web of deprecating APIs at a rapid rate - that's a feature of the 
platform, not a bug. 

Besides, standards take time because implementers are slow at implementing. Not 
because standards processes are slow. There are more specs available than have 
been implemented. 

> It also took years to standardize the
> vibration api, which is pretty simple.

And which applications have really suffered because of it?

Also, if you compare the first proposal:
http://www.w3.org/TR/2011/WD-vibration-20111117/

And the final version:
http://www.w3.org/TR/vibration/

The API is virtually the same. 

>  I guess we should not have
> implemented anything before the whatwg gatekeeper gave their approval?

No, this is not about getting approval: it's about having cross-browser 
commitments for collaboration and implementation.  

What speeds up standardization is having agreement across browser vendors to 
implement something (and actually going through with it). A standard is marked 
by having 2 or more interoperable implementations of an API - and *not getting 
stamps of approval from the W3C or WHATWG*. So, if standards are slow, we have 
to take some blame for either being slow at implementing stuff or not 
collaborating better with other browser vendors. 

> Mozilla is the only significant browser vendor that doesn't have a
> 'native' OS. That means that all other players may have a vested
> interest in keeping the web a step behind.

Well, we can treat other vendors with suspicions (hell, we would be right to do 
so given past history [1]). However, I'm yet to meet a browser engineer who is 
actively trying to screw over the Web, or actively neglecting it. Even 
Microsoft have come around - the IE Team is doing phenomenal work, the Google 
folks are amazing and driving large parts, the Apple/WebKit folks are a little 
shy, sure - but they deliver (e.g., WebGL on iOS) - and of course, we, Moz, are 
all over this Web platform thing: from installable web apps, the DOM, web 
audio, to ECMAScript, etc. I might be blind, but I don't see much evidence of 
anyone acting to keep the web behind (or they are just doing a really bad job 
at driving the web forward, 'cause all I see is awesome browsers everywhere 
that are all implementing web standards). 

We even trust Apple so much to do the right thing that we are going to build a 
Firefox browser version using WebKit. That says something! Now, imagine how sad 
it's going to be when FxOS apps don't work in Firefox for iOS.   

> Do we want to play this game by abiding to consensus?

I hope so. The network effect (i.e., massive reach) of cross-browser web 
applications is the main competitive advantage we have on the Web. If we throw 
that away... :(

[1] http://en.wikipedia.org/wiki/United_States_v._Microsoft_Corp.
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g

Reply via email to