<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<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 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 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 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>