<div dir="ltr"><div><div>While preprocessed code could likely ultimately be tolerated, it is my preference to see it go away *unless* we adopt preprocessing conventions utilized by the larger JavaScript community and are well supported by 3rd party JavaScript tools. (Currently, the preprocessor is part of the build system and I'm pretty sure any overlap with existing JS preprocessors is coincidental.) Much like the larger Java world doesn't preprocess Java (like we do on Fennec, unfortunately), we shouldn't be doing it in Firefox JavaScript unless we have a very good reason. And if we must preprocess code, I think we should take steps to limit its impact (e.g. isolate all preprocessed code to standalone files so its effects don't creep into most code).<br><br></div>Preprocessing is an additional step to statically analyze JavaScript code. With our current preprocessor, we must have a build system context (i.e. run configure) in order to preprocess. And this means potentially different output on Windows, Linux, Mac, etc. This means you have to perform static analysis on different platforms. Or, it involves low-level workarounds to trick the build system. This raises the barrier to writing and deploying new tools, which undermines developer productivity efforts. (We ideally want to deploy once and run everywhere.)<br><br></div>I think eliminating or marginalizing preprocessing of JavaScript code would be a noble goal.<br><div><div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 16, 2015 at 2:03 PM, Gijs Kruitbosch <span dir="ltr"><<a href="mailto:gijskruitbosch@gmail.com" target="_blank">gijskruitbosch@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>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!<span class="HOEnZb"><font color="#888888"><br>
<br>
~ Gijs</font></span><div><div class="h5"><br>
<br>
On 16/02/2015 21:55, Bill McCloskey wrote:<br>
</div></div></div><div><div class="h5">
<blockquote 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 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>On Feb 16, 2015 1:26 PM, "Gregory Szorc"
<<a 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>
<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 href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a 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 href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a 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></fieldset>
<br>
<pre>_______________________________________________
firefox-dev mailing list
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
<br></blockquote></div><br></div>