dtownsend at mozilla.com
Mon Feb 16 21:47:06 UTC 2015
Can you actually enumerate the things we are using that aren't standard (or
soon to be standard) ES6? I can't think of many. My experience is that
generally when a nice new ES6 feature comes along we rush excitedly to
start using it, sometimes before the JS team think is is ready to ship
I know we have old-style generator functions that we can and should just
switch to function*. For...each can probably be ditched in favour of
for...of easily too.
Cu.import will be harder to remove but I don't understand what the cost of
that is there, it's certainly a well-formed ES6 statement and until modules
become a real thing there isn't really a replacement.
On Feb 16, 2015 1:26 PM, "Gregory Szorc" <gps at mozilla.com> wrote:
> Firefox Developers,
> non-standard, SpiderMonkey/Gecko-only extensions like
> problem to the productivity of Firefox developers and hinders the ability
> to more quickly ship high quality features, which undermines the ability
> for Mozilla to achieve its Mission.
> In my capacity as a Developer Productivity Engineer, I'd love to build and
> deploy tools for you so you can do your job better and more efficiently.
> makes that significantly more difficult than it could be. This is because
> years. Unfortunately, many of them can't be leveraged by Firefox
> developers. The rest of the world is reaping the rewards of better tooling.
> But for Firefox development at Mozilla, we're still stuck in the past.
> Others have increased their development velocity while we have stayed the
> same. We're losing ground. And the gap is only getting wider. We're already
> playing around with automatic linting and code rewriting for Python and C++
> developers at Mozilla. Unfortunately, those advancements can't easily come
> tooling gap" for Firefox development.
> Here is where I need your help.
> I'd like to start a dialog within the Firefox team about 1) adopting
> coding standards that facilitate tool usage 2) adopting a plan to convert
> existing source code to be "standards compliant" so tools can be deployed
> with reasonable success.
> I understand there are valid reasons for diverging from specified language
> behavior from time to time. However, the tooling gap is widening and the
> drawbacks from deviating from what tools support are increasing, and this
> only hurts Firefox and Mozilla more as time goes by. Yes, it might be
> possible to patch 3rd party tools and teach them about SpiderMonkey
> extensions. It has been done before. But, I don't think we want to be in
> the position of maintaining 3rd party tools if it can be avoided. And, we
> can't expect tools to accept these changes in the first place (this would
> be like asking Gecko to implement a non-standard, Chrome-only feature -
> it's definitely not very Mozilla-y if nothing else).
> conforming to the specified ECMAScript language and what can we do to
> minimize that gap going forward so productivity and quality enhancing tools
> and services may be utilized?
> firefox-dev mailing list
> firefox-dev at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the firefox-dev