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.
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).
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.
Unfortunately, though, this kind of goes against your argument which I understand to be "how dare Google release something that is not standards based". I agree principle with that, _but_ in this case a few posts did show example of technologies that all browser vendors introduces that were outside the spec.
> 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.
I don't follow, why does it go against that line of argument? If someone else did something bad in the past, it doesn't excuse doing something bad in the present.
(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.
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?
Which is... exactly the same situation JavaScript was in when Netscape introduced it.