<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body>
When something is not possible using our current JS implementation
we tend to implement it in e.g. nsIDOMUtils.cpp and use it in our
code. If we had to wait for every command to be standardized there
would be very significant roadblocks to innovation.<br>
<br>
At the same time, of course, if something can be done with our
current JS implementation without too much extra overhead and
complexity then it should be.<br>
<br>
/Mike<br>
<br>
<div class="moz-cite-prefix">On 17/02/2015 07:46, Chris Peterson
wrote:<br>
</div>
<blockquote cite="mid:54E2F1C0.50407@mozilla.com" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<br>
<div class="moz-cite-prefix">On 2/16/15 1:55 PM, Bill McCloskey
wrote:<br>
</div>
<blockquote
cite="mid:CAJ6cW=NFytHis977kGiHkpJqC8UHLqCk0yiL7mwUgu5wjUOTng@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Use of the preprocessor would be pretty high on my list
of things to get rid of.<br>
<br>
</div>
<div>I suspect that a lot of the older non-ES6 JS features
probably don't get used much in new code (old-style
generators, for each, braceless functions), so a style guide
won't help much. We just need to remove them from old code.<br>
</div>
</div>
</blockquote>
<br>
Here is a longer list of deprecated SpiderMonkey features:<br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Deprecated_and_obsolete_features">https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Deprecated_and_obsolete_features</a><br>
<br>
I added telemetry probes for some of SpiderMonkey's nonstandard
language extensions in web content (not add-on or chrome JS). It
looks like for-each, legacy generators, and let blocks/expressions
are rarely used in web content:<br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://is.gd/VKxQkQ">http://is.gd/VKxQkQ</a><br>
<br>
In my spare time, I have been slowly removing their use in chrome
JS. I would like to hide some of these language extensions from
web content in Firefox 39 and then finish removing them from
chrome JS. Firefox 38 will be the next ESR, so it would be nice to
keep these language extensions there in case some ESR users'
add-ons or intranet sites rely on them. :)<br>
<br>
<br>
chris<br>
<br>
<br>
<blockquote
cite="mid:CAJ6cW=NFytHis977kGiHkpJqC8UHLqCk0yiL7mwUgu5wjUOTng@mail.gmail.com"
type="cite">
<div dir="ltr">-Bill<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Feb 16, 2015 at 1:47 PM, Dave
Townsend <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:dtownsend@mozilla.com" target="_blank">dtownsend@mozilla.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">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 unfortunately.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<div class="gmail_quote">
<div>
<div class="h5">On Feb 16, 2015 1:26 PM, "Gregory
Szorc" <<a moz-do-not-send="true"
href="mailto:gps@mozilla.com" target="_blank">gps@mozilla.com</a>>
wrote:<br type="attribution">
</div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div class="h5">
<div dir="ltr">
<div>Firefox Developers,</div>
<div><br>
</div>
<div>You write a lot of JavaScript. (I know - I
was on your team once.) Unfortunately, a lot
of the JavaScript going into Firefox is what I
call "Gecko flavored JavaScript." This is
JavaScript that doesn't conform to any
standard (like ES6). Instead, it's JavaScript
that takes advantage of non-standard,
SpiderMonkey/Gecko-only extensions like
Components.utils.import().<br>
<br>
</div>
<div>I think the prevalence of all this
"non-standard" JavaScript poses a major
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.<br>
<br>
</div>
<div>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. Unfortunately, the lack of
standard JavaScript in the Firefox code base
makes that significantly more difficult than
it could be. This is because pretty much all
the existing JavaScript tools out there barf
when processing Firefox source code because it
contains non-standard JavaScript.<br>
<br>
There has been a wave of advancements in
JavaScript tools these past few 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 to JavaScript until the
tools can understand the Firefox code.<br>
</div>
<div><br>
I think it should be an organizational
priority to address the "JavaScript tooling
gap" for Firefox development.<br>
<br>
</div>
<div>Here is where I need your help.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>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).<br>
<br>
</div>
<div>So, I ask a question: what today is
preventing JavaScript in Firefox from
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?<br>
<br>
</div>
<div>Gregory<br>
</div>
</div>
<br>
</div>
</div>
_______________________________________________<br>
firefox-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:firefox-dev@mozilla.org"
target="_blank">firefox-dev@mozilla.org</a><br>
<a moz-do-not-send="true"
href="https://mail.mozilla.org/listinfo/firefox-dev"
target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
<br>
</blockquote>
</div>
<br>
_______________________________________________<br>
firefox-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
<a moz-do-not-send="true"
href="https://mail.mozilla.org/listinfo/firefox-dev"
target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
firefox-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/firefox-dev">https://mail.mozilla.org/listinfo/firefox-dev</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
firefox-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/firefox-dev">https://mail.mozilla.org/listinfo/firefox-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>