mratcliffe at mozilla.com
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:
> 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:
> feature] usage as of Firefox N.
> experimental, non-critical usage - it's API will likely change.
> Firefox M: use X instead.
> 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.
> 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?
> firefox-dev mailing list
> firefox-dev at mozilla.org
More information about the firefox-dev