<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">The preprocessor shouldn't be an issue;
we should just run whatever tooling we have on preprocessed source
code. There are standardized things for this type of stuff, like
source maps, and we can use them.<br>
<br>
Ditching the preprocessor would also mean ungodly-long in-tree JS
files because extra script references add overhead. It's no
coincidence web devs unify their JS into only a few files, too.
Obviously we could replace it with other magical "put the things
together" solutions, but that's unlikely to solve the same tooling
problem, ie, multiple files that apply to a single global. If
anything, I wish we split up browser.js even more ways.<br>
<br>
Depending on the kind of analysis, like Dave I would expect that
our modules not having window globals, and both them and the
window globals having "odd" APIs (document.getBindingParent,
document.getAnonymousElementByAttribute, XUL/XBL elements +
syntax, ...) is more problematic. I'd also loathe to give up any
kind of useful syntactic sugar that's on a standards-track just
because the tools aren't there yet, and write more verbose and
error-prone code instead.<br>
<br>
I would settle for our internal tools actually working, like the
browser debugger which is too unreliable to use (with XBL, with
content scripts, ...) without debugger; statements... don't think
we need any syntax changes for that!<br>
<br>
~ Gijs<br>
<br>
On 16/02/2015 21:55, 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><br>
</div>
-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>