<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">What's the plan for #include, which is
implicated here?<br>
<br>
Aeons ago, I filed
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<a class="moz-txt-link-freetext" href="https://bugzilla.mozilla.org/show_bug.cgi?id=381210">https://bugzilla.mozilla.org/show_bug.cgi?id=381210</a> about the
ridonkulous size of browser.js (still pretty big, btw!) which much
later got duped to
<a class="moz-txt-link-freetext" href="https://bugzilla.mozilla.org/show_bug.cgi?id=758812">https://bugzilla.mozilla.org/show_bug.cgi?id=758812</a> where dolske
eventually did split up a lot using #include directives.<br>
<br>
While I recognize I have no veto rights or whatever, I would be...
seriously displeased if we went back to just using a single file.<br>
<br>
AIUI, jsms are our next-best alternative, but using a lot of them
has serious performance downsides (and will also require a bunch
of refactoring for the included scripts).<br>
<br>
Perhaps we can introduce a valid JS shorthand to include extra
files by simply loading them into the global scope with the
scriptloader, and then preprocess them for dist and/or pgo builds?<br>
<br>
For CSS (which has this problem but worse because no
scriptability) we can presumably do this with the pre-existing
@import , and change %defines to use CSS variables?<br>
<br>
~ Gijs<br>
<br>
On 03/04/2015 13:22, Mike de Boer wrote:<br>
</div>
<blockquote
cite="mid:0B4D7408-DF56-49BA-85D9-B0C2E24486F2@mozilla.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div class="">I filed <a moz-do-not-send="true"
href="https://bugzilla.mozilla.org/show_bug.cgi?id=1150859"
class="">https://bugzilla.mozilla.org/show_bug.cgi?id=1150859</a> -
'Remove preprocessor directives from browser code’ to track work
related to some of the things mentioned in this thread.</div>
<div class=""><br class="">
</div>
<div class="">Mike.</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 26 Feb 2015, at 00:02, Gregory Szorc <<a
moz-do-not-send="true" href="mailto:gps@mozilla.com"
class="">gps@mozilla.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class=""> I wanted to clarify what I meant by
"Gecko flavored JavaScript," since some of you pinged
me about it. As many of you know, Mozilla frequently
experiments with new JavaScript features before they
become standardized. This is done as part of evolving
the JavaScript language, which Mozilla plays an active
role in. This foraging into experimental language
features are what I mean by "Gecko flavored
JavaScript." I think this experimentation is healthy.
I just wanted to raise awareness of its potential
drawback of sacrificing the ability for us to use more
tools.<br class="">
<br class="">
</div>
These are my thoughts and I'm sure there will be others
who will want to chime in.<br class="">
<br class="">
</div>
Gregory<br class="">
</div>
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Mon, Feb 16, 2015 at 1:26 PM,
Gregory Szorc <span dir="ltr" class=""><<a
moz-do-not-send="true" href="mailto:gps@mozilla.com"
target="_blank" class="">gps@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">
<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?<span class="HOEnZb"><font
class="" color="#888888"><br class="">
<br class="">
</font></span></div>
<span class="HOEnZb"><font class="" color="#888888">
<div class="">Gregory<br class="">
</div>
</font></span></div>
</blockquote>
</div>
<br class="">
</div>
_______________________________________________<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 class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/firefox-dev">https://mail.mozilla.org/listinfo/firefox-dev</a><br class="">
</div>
</blockquote>
</div>
<br class="">
<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>