Assessing stability of new JavaScript features

Mike Ratcliffe mratcliffe at
Thu Jun 20 22:02:02 UTC 2013

Sometimes a new feature gives you exactly what you need to get the job 
done. Having to check the features we are using against an ever 
changing list would be frustrating.

My point of view is that using these methods in chrome code quickly 
reveals bugs and, ultimately, results in a more stable experience.


On 20 June 2013 21:26:22, Gregory Szorc wrote:
> The JavaScript language and SpiderMonkey are rapidly evolving. As new
> features are added to the language and SM, I keep finding myself
> asking "is this feature stable enough to be used in production code
> (Firefox/Toolkit/etc)?" (To be clear, I'm talking about
> Firefox/chrome-privileged JS - not JS on the web.)
> AFAIK, the best way to currently answer that question is 1) ask a
> SpiderMonkey dev 2) look through the code and see what others are
> doing. You could arguably add 3) look at docs on MDN. But the
> "experimental" warning is on features that have been used in Firefox
> for over a year or skew towards suitability for the feature on the
> web, so I don't trust it.
> These options aren't satisfactory. #1 is dependent on asking the right
> person and hoping there isn't bias towards "using." #2 relies on #1
> first being followed and second being accurate and thus is not robust.
> Since using "alpha" JS features can undermine the quality and
> stability of Firefox, can increase development time (refactoring code
> as the feature implementation changes from under you), and since
> people are generally in the dark over the "stability" of new JS
> features, I think something needs to be done.
> What I'm personally looking for is an authoritative document that says
> things like:
> * JavaScript feature X has been blessed for stable [internal Firefox
> feature] usage as of Firefox N.
> * JavaScript feature Y is available in Firefox X but only for
> experimental, non-critical usage - it's API will likely change.
> * JavaScript feature Z should not be used for new development after
> Firefox M: use X instead.
> I want this both as someone who writes a lot of JavaScript (I want to
> make my life easier by using new, more powerful language constructs)
> and as a reviewer (I don't want to allow unstable features to leak
> into the tree).
> Where this would live, I don't know. It sounds a lot like code style
> guidelines to me. It would need periodic input from the JS team to vet
> the stability assurances. And, maybe we want module owners to perform
> a secondary sign-off on new feature usage.
> For reference, some of the new JavaScript features that still have a
> cloud over (in my mind at least) are generators, fat arrow functions,
> set, map, ParallelArray, Proxy, ... From my casual following of JS
> language development, this list will only grow longer over time, so
> this problem is only going to get worse.
> If others feel the same, what can we do about this?
> Gregory
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at

More information about the firefox-dev mailing list