<div dir="ltr">On Fri, Apr 3, 2015 at 8:02 AM, Gijs Kruitbosch <span dir="ltr"><<a href="mailto:gijskruitbosch@gmail.com" target="_blank">gijskruitbosch@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>What's the plan for #include, which is
      implicated here?<br></div></div></blockquote><div><br></div><div>Converting everything to JSMs seems like the best option.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
      
      Aeons ago, I filed
      
      <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=381210" target="_blank">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 href="https://bugzilla.mozilla.org/show_bug.cgi?id=758812" target="_blank">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></div></div></blockquote><div><br></div><div>I'm sure you wouldn't be the only person :-).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
      
      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></div></div></blockquote><div><br></div><div>We already import ~50 JSMs into browser.js. Converting 21 #include files to JSMs will be annoying, but I doubt it will have any significant effect on performance. We'll use a little more memory, but the code will be loaded more lazily in most cases. It's worth measuring though.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
      
      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></div></div></blockquote><div><br></div><div>Well, the point of removing the preprocessor is to use only standard JavaScript, so I don't think we should do that.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
      
      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?</div></div></blockquote><div><br></div><div>That would be cool. I'm also worried about .xul files. It would be great to get rid of the preprocessor in those, but I don't know of any replacement for #ifdef in XUL.<br></div><br></div><div class="gmail_quote">-Bill<br><br></div></div></div>