Assessing stability of new JavaScript features

Gavin Sharp gavin at
Thu Jun 20 22:13:01 UTC 2013

I don't think it's realistic to expect that an authoritative document
like what you propose would be kept up to date and complete, and so
we're always going to have to rely on some form of #1 and #2 (i.e.
individual engineers "doing the right thing"). It's probably better to
focus on making it easier/more likely that that will happen - for
example, trying to ensure that JS feature landings have accompanying
blog/mailing list posts that detail the state of the feature, the
people to contact for more information, etc.


On Thu, Jun 20, 2013 at 4:26 PM, Gregory Szorc <gps at> 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