<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I’m really looking forward to having your awesomeness, gps, and that of others focussed on this! There’s some overlap here with ideas that exist within the Loop/ Hello team: we are trying to get NodeJS available on the build system so that we can run linters and other static analysis goodies on our infra per-push so that we can track the state of things over time and in the future backout changesets that yield errors from these tools.</div><div class="">Having NodeJS in our toolchain would greatly improve things, I believe, because there’s much good stuff that we can use on NPM.</div><div class=""><br class=""></div><div class="">And don’t forget about CSS! I’m one of those weirdos that think CSS is harder than JS ;-)</div><div class=""><br class=""></div><div class="">I also think that we need to be less strict about landing big search-and-replace patches to update our codebase in one go to, for example, remove our usage of deprecated Spidermonkey features. The only real reason to reject this practice I’ve heard is to preserve blame. I think that’s an outdated point of view and is holding us back unnecessarily.</div><div class=""><br class=""></div><div class="">Onward to something that has become more troubling over the course of my two years at Moz: printf-debugging.</div><div class="">I cheered out loud when the browser toolbox popped up last year, but now I’m just sad. It does not make me remove DOM Inspector. In fact, I still only use that piece of arcane software, because it _just works_. But that’s the least of my trouble (I still have a tool to use instead); the debugger is unusable. I’ve had crashes, missed breakpoints, hangs and more. So the reality is that dump() was, is and will be my best friend.</div><div class="">I’m getting more worried now though, because e10s introduces more message passing, indirect code flows that take more time to debug using this old tradition. We will be in need of a real debugger rather soon.</div><div class="">To be clear: I’m talking about the product, not the team. I know there’s a massive amount of technical debt they are working hard to resolve. I’m trying to say that the team needs more resources. A lot more.</div><div class=""><br class=""></div><div class="">Thanks for starting this thread!</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On 17 Feb 2015, at 11:51, Mike Ratcliffe <<a href="mailto:mratcliffe@mozilla.com" class="">mratcliffe@mozilla.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type" class="">
<div class="">
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 class="">
<br class="">
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 class="">
<br class="">
/Mike<br class="">
<br class="">
<div class="moz-cite-prefix">On 17/02/2015 07:46, Chris Peterson
wrote:<br class="">
</div>
<blockquote cite="mid:54E2F1C0.50407@mozilla.com" type="cite" class="">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type" class="">
<br class="">
<div class="moz-cite-prefix">On 2/16/15 1:55 PM, Bill McCloskey
wrote:<br class="">
</div>
<blockquote cite="mid:CAJ6cW=NFytHis977kGiHkpJqC8UHLqCk0yiL7mwUgu5wjUOTng@mail.gmail.com" type="cite" class="">
<div dir="ltr" class="">
<div class="">Use of the preprocessor would be pretty high on my list
of things to get rid of.<br class="">
<br class="">
</div>
<div class="">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 class="">
</div>
</div>
</blockquote>
<br class="">
Here is a longer list of deprecated SpiderMonkey features:<br class="">
<br class="">
<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 class="">
<br class="">
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 class="">
<br class="">
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://is.gd/VKxQkQ">http://is.gd/VKxQkQ</a><br class="">
<br class="">
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 class="">
<br class="">
<br class="">
chris<br class="">
<br class="">
<br class="">
<blockquote cite="mid:CAJ6cW=NFytHis977kGiHkpJqC8UHLqCk0yiL7mwUgu5wjUOTng@mail.gmail.com" type="cite" class="">
<div dir="ltr" class="">-Bill<br class="">
</div>
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Mon, Feb 16, 2015 at 1:47 PM, Dave
Townsend <span dir="ltr" class=""><<a moz-do-not-send="true" href="mailto:dtownsend@mozilla.com" target="_blank" class="">dtownsend@mozilla.com</a>></span>
wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr" class="">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" class="">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" class="">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 class="">
<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" class="">gps@mozilla.com</a>>
wrote:<br type="attribution" class="">
</div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
<div class="h5">
<div dir="ltr" class="">
<div class="">Firefox Developers,</div>
<div class=""><br class="">
</div>
<div class="">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 class="">
<br class="">
</div>
<div class="">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 class="">
<br class="">
</div>
<div class="">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 class="">
<br class="">
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 class="">
</div>
<div class=""><br class="">
I think it should be an organizational
priority to address the "JavaScript tooling
gap" for Firefox development.<br class="">
<br class="">
</div>
<div class="">Here is where I need your help.<br class="">
<br class="">
</div>
<div class="">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 class="">
<br class="">
</div>
<div class="">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 class="">
<br class="">
</div>
<div class="">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 class="">
<br class="">
</div>
<div class="">Gregory<br class="">
</div>
</div>
<br class="">
</div>
</div>
_______________________________________________<br class="">
firefox-dev mailing list<br class="">
<a moz-do-not-send="true" href="mailto:firefox-dev@mozilla.org" target="_blank" class="">firefox-dev@mozilla.org</a><br class="">
<a moz-do-not-send="true" href="https://mail.mozilla.org/listinfo/firefox-dev" target="_blank" class="">https://mail.mozilla.org/listinfo/firefox-dev</a><br class="">
<br class="">
</blockquote>
</div>
<br class="">
_______________________________________________<br class="">
firefox-dev mailing list<br class="">
<a moz-do-not-send="true" href="mailto:firefox-dev@mozilla.org" class="">firefox-dev@mozilla.org</a><br class="">
<a moz-do-not-send="true" href="https://mail.mozilla.org/listinfo/firefox-dev" target="_blank" class="">https://mail.mozilla.org/listinfo/firefox-dev</a><br class="">
<br class="">
</blockquote>
</div>
<br class="">
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">_______________________________________________
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 class="">
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">_______________________________________________
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 class="">
</div>
_______________________________________________<br class="">firefox-dev mailing list<br class=""><a href="mailto:firefox-dev@mozilla.org" class="">firefox-dev@mozilla.org</a><br class="">https://mail.mozilla.org/listinfo/firefox-dev<br class=""></div></blockquote></div><br class=""></body></html>