Which is exactly the same situation that Javascript is in now. The Javascript VM in Firefox has features that are not part of any web standard, nor part of a spec that has interest from multiple vendors.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_...
Firefox 3.0+ added support for expression closures and generator expressions:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_...
Firefox 22+ supports fat arrow functions. Just open the console and try it yourself:
>>> let z = x => x * x;
undefined
>>> z(5);
25
>>> let y = (a, b) => a * b;
undefined
>>> y(2, 3)
6
http://wiki.ecmascript.org/doku.php?id=harmony:let
Arrow functions are being standardized as well,
http://wiki.ecmascript.org/doku.php?id=harmony:arrow_functio...
and for generators, the standards discussion led to a change in the spec, with the new version replacing the old implementation in SpiderMonkey (v8 recently implemented the new one as well).
In general see
http://kangax.github.io/es5-compat-table/es6/
where it lists compatibility for various new JS features. As it says there, let is supported not just in Firefox but also IE11 and Chrome 30.
It is true that Firefox shipped some of these several years back. I am not sure of the best way to find out exactly what the standards-track status was at those times.
But in general: Talking about the far past is counterproductive. We can probably find stuff that wasn't done properly by any browser if we look back far enough. But in recent years, there is growing consensus on the importance of not shipping non-standard things. That is the important thing I think.
> But in recent years, there is growing consensus on the importance of not shipping non-standard things.
Others might read that as no new and meaningful technologies will be seen implemented in the browsers soon. I can't think of too many thing designed and build by an intercompany commetee.
(And as mentioned above, I'm not sure about those examples - while it's very possible some were released before being standardized, I didn't see a link showing that, and they are all being standardized now. Need more info.)
Fair point about the limits of things designed by committees. But it isn't always true, just mostly true ;) For example, WebGL was designed through a standards process, and it is great.
Earlier you mentioned "far past", but this stuff is fairly recent:
Firefox 2 - October 24, 2006
Firefox 3 - June 17, 2008
Firefox 22 - June 25, 2013
> while it's very possible some were released before being standardized
Nothing of this is in ES5.1.
> they are all being standardized now
Yes, just like Dart.
> For example, WebGL was designed through a standards process, and it is great.
No, that's not how it happened. [1]
Experiment by Mozilla - 2006
Implementations by Mozilla and Opera - 2007
WebGL Working Group - 2009
1.0 spec - 2011
And all of this is based on Canvas which is something Apple made up.
Anyhow, you seem to think that this kind of thing is a problem. It's not. This is how the web works. This is how progress is made.
Regarding Firefox 22, that is recent, but I don't see a link showing it shipped something nonstandard and that was not being standardized? In fact I showed a link for the standardization process for arrows? Revision history for that page seems to show that it predates Firefox 22.
> Nothing of this is in ES5.1.
They are in ES6, which is being standardized, has interest from multiple vendors, is heavily discussed by multiple vendors, and has implementations by multiple vendors.
I never said everyone should wait until a standard is 100% final. Just like the Blink principles say, it can be perfectly valid to ship something that is being standardized, so long as there is interest from multiple vendors and work on standardization.
The risk is of one vendor shipping something entirely unilaterally, with no respect for any standards process. That's not what happened with arrows.
> > they are all being standardized now
> Yes, just like Dart.
AFAIK no other vendor has expressed any interest in Dart. The opposite in fact, Apple opposed including bindings to WebKit that would allow additional languages to JS. Please correct me if I am wrong?
> Anyhow, you seem to think that this kind of thing is a problem. It's not. This is how the web works. This is how progress is made.
I disagree. Why then do you think Google wrote the Blink principles about avoiding shipping something before it is standardized or has multiple vendor interest? Why did Google stop shipping vendor-specific WebGL extensions? In both cases Google is showing what most vendors consider proper behavior today, and I think Google is doing the right thing. Do you think Google is wrong in both cases?