<div dir="ltr">I understand g(un)zip is the de-facto standard, I would just hate to see such a small detail overlooked at the end of the day when a one liner pretty much covers it.<div><br></div><div>Oh, and I'll 2nd the "way nicer than any AMD solution".  This also keeps readability in mind along with forcing declaration instead of allowing you to loose track of dependencies accidentally.  I prefer to have page bloat in dev form and compile down for production use only if necessary.</div>

<div><br></div><div>Course, that's two cents from a guy who usually hides in the corners on this type of discussion.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Oct 10, 2013 at 8:10 PM, Andrea Giammarchi <span dir="ltr"><<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@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 dir="ltr">You are confining the problem in HTTP only scenarios while the solution provided by<div class="im"><div>

<br></div><div><span style="font-family:Calibri,sans-serif;font-size:15px"><script </span><span style="font-family:Calibri,sans-serif;font-size:15px">src</span><span style="font-family:Calibri,sans-serif;font-size:15px">="lib/main.js" ref=”assets.zip”></script></span><br>


</div><div><br></div></div><div>can be handy/reused in offline packaged applications too so HTTP 2 might win on HTTP but it's not a general HTML App packaging option.</div><div><br></div><div>I think FirefoxOS Apps might have something similar without even bothering the network stack, but then there apps are already packaged in a similar way so here would be the common bundle/package within the bundled FFOS App but others might reuse same logic too.</div>


<div><br></div><div>@Jeremy, it does not matter much what browser prefers when the de-facto standard is to accept and support either deflate or g(un)zip so anything compatible with these two (basically same) algo woul dbe acceptable and easy to implement for everyone, am I correct?</div>


<div><br></div><div>Back to the HTTP support, I would go for the possibility to bundle through CDN too which might penalize minor used libraries (like few of mines) but boost up most common scenario across websites or apps (thinking about Angular bundle, Ember bundle, jQueryUI bundle or ExtJS bundle, etc)</div>


<div><br></div><div>Last personal thought: this is way nicer than any AMD solution I've seen, giving a real alternative to async modules too via script defer/async attributes without requiring boiler plates all over to include on demand.</div>


<div><br></div><div>+10000 for that -1000 is worth my opinion ^_^</div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Oct 10, 2013 at 11:22 AM, David Bruant <span dir="ltr"><<a href="mailto:bruant.d@gmail.com" target="_blank">bruant.d@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>HTTP 2 is coming with a feature called
      server-push [1] which seems more appropriate for this type of
      bundling.<br>
      In essence, when being asked for a webpage, the server sends the
      HTML page as well as a bunch of resources (CSS, JS, image,
      whatever) in the same HTTP response. These are individually
      decompressed and cached and available handy when the HTML parsing
      requires fetching resources (lots of that can happen in parallel I
      imagine, depending on the bundling).<br>
      Best of all, this is all seamless. Just keep writing HTML as
      you've always had, no need for new "assets.zip$/lib/main.js"
      syntax. It keeps the HTML decoupled from the "how" of resource
      delivery.<br>
      <br>
      Among other benefits [1]:<br>
      "pushed resources are cached individually by the browser and can
      be reused across many pages"<br>
      => It's not clear this can happen with an asset.zip<br>
      <br>
      "by the time the browser discovers the script tag in the HTML
      response the <code>main.js</code> file is already in cache, and
      no extra network roundtrips are incurred!"<br>
      => Not even a need to load an additional asset.zip<br>
      <br>
      We can discuss the deployment aspects of HTTP 2 and whether
      Generic Bundling as proposed can provide benefits before HTTP 2 is
      fully deployed, but I feel the bottleneck will be the server-side
      engineering to bundle the resources and this work is equivalent
      for both HTTP 2 and the proposed Generic Bundling.<br>
      So HTTP 2 wins?<br>
      <br>
      David<br>
      <br>
      [1]
      <a href="http://www.igvita.com/2013/06/12/innovating-with-http-2.0-server-push/" target="_blank">http://www.igvita.com/2013/06/12/innovating-with-http-2.0-server-push/</a><br>
      <br>
      Le 10/10/2013 19:30, Jonathan Bond-Caron a écrit :<br>
    </div>
    <blockquote type="cite"><div><div>
      
      
      
      
      
      
      
      
      
      
      <div>
        <p class="MsoNormal"><a name="141a510b97a7c113_141a39b66a6eeb8b__MailAutoSig"><span>About
              Generic Bundling in:<u></u><u></u></span></a></p>
        <p class="MsoNormal"><span></span><a href="https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-09/modules.pdf" target="_blank"><span>https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-09/modules.pdf</span><span></span></a><span><u></u><u></u></span></p>



        <p class="MsoNormal"><span><span><u></u> <u></u></span></span></p>
        <span></span>
        <p class="MsoNormal"><script <span>src</span>="assets.zip$/lib/main.js"></script><u></u><u></u></p>
        <p class="MsoNormal"><u></u> <u></u></p>
        <p class="MsoNormal">It could be reworked as:<u></u><u></u></p>
        <p class="MsoNormal"><u></u> <u></u></p>
        <p class="MsoNormal"><link <span>rel</span>="loader"
          type="application/zip"
          <span>href</span>="assets.zip"> <u></u><u></u></p>
        <p class="MsoNormal"><script <span>src</span>="lib/main.js"></script><u></u><u></u></p>
        <p class="MsoNormal"><u></u> <u></u></p>
        <p class="MsoNormal">Simple pattern for packaging web apps where
          ‘assets.zip’ might be already available.<u></u><u></u></p>
        <p class="MsoNormal"><u></u> <u></u></p>
        <p class="MsoNormal">For remote fetching, I imagine it would
          block waiting for assets.zip to be available. Could be solved
          with something like:<u></u><u></u></p>
        <p class="MsoNormal"><u></u> <u></u></p>
        <p class="MsoNormal"><script <span>src</span>="lib/main.js"
          ref=”assets.zip”></script><u></u><u></u></p>
        <p class="MsoNormal"><u></u> <u></u></p>
        <p class="MsoNormal">Which would lookup <link <span>rel</span>="loader"> and match
          ref=assets.zip to href=assets.zip<u></u><u></u></p>
        <p class="MsoNormal"><u></u> <u></u></p>
        <p class="MsoNormal">Either way, I’m curious where the
          discussion is taking place, w3c?
          <u></u><u></u></p>
        <p class="MsoNormal">How does this fit with <span>Ecmascript</span>,
          <span>System.loader</span>?<u></u><u></u></p>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><div><pre>_______________________________________________
es-discuss mailing list
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a>
</pre>
    </div></blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>