<div dir="ltr">On Fri, Oct 25, 2013 at 12:17 AM, Andrea Giammarchi <span dir="ltr"><<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>></span> wrote:<br><div class="gmail_extra">

<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Ilya ... just to re-clarify what was the discussion about: Generic Bundling ... not HTTP Bundling.<div>

I don't know why many keep coupling and confining HTML5 over HTTP and nothing else.</div><div>Bundling as you do with executables or apps, bundling as you send a single file update for your customer to replace instead of unzipping, overwriting each file, etcetera.</div>

<div>Why is in your opinion bundling bad for non HTTP, offline, apps created using these technologies ?</div><div>Every programming language I know have some bundle support that works as single package/file ... C has the executable, then we have phar, war, jar, python has many ... what about JS ? Won't work without HTTP ? Why ?</div>

</div></blockquote><div><br></div><div>I'm not saying it won't work. I'm saying there are many downsides to distributing large blobs of data. Case in point, once you start distributing large blobs, you'll soon realize that it sucks that you have to download the entire blob every time a single byte has changed. As a result, you end up developing binary-diff formats.. like Courgette [1] that we use to update Chrome. A much simpler solution for web apps is to do exactly what AppCache did, create a manifest which lists all the resources, and let HTTP do the rest: each file can be downloaded and updated individually, etc. </div>

<div><br></div><div>ig</div><div><br></div><div>[1] <a href="http://www.chromium.org/developers/design-documents/software-updates-courgette">http://www.chromium.org/developers/design-documents/software-updates-courgette</a><br>

</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_extra">

<div class="gmail_quote"><div><div class="h5">On Thu, Oct 24, 2013 at 11:17 PM, Ilya Grigorik <span dir="ltr"><<a href="mailto:igrigorik@gmail.com" target="_blank">igrigorik@gmail.com</a>></span> wrote:<br></div></div>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div class="h5">
<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">+ 1 to François's comments.</span><br><div class="gmail_extra"><br><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">





You're not saying that gzipping and wise pre-fetching and parallel download of scripts don't improve page load times. Or are you?<br></blockquote><div><br></div></div><div><span style="font-family:arial,sans-serif;font-size:13px">- We already have transfer-encoding in HTTP, and yes, you should definitely use it!</span></div>




<div><span style="font-family:arial,sans-serif;font-size:13px">- Prefetching is also an important optimization, but in the context of this discussion (bundling), it's an orthogonal concern.</span></div><div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


In the equation you paint above something important is missing: the fact that there's a round-trip delay per request (even with http2.0), and that the only way to avoid it is to bundle things, as in .zip bundling, to minimize the (number of requests and thus the) impact of latencies.<br>




</blockquote><div><br></div></div><div>With HTTP 1.x (and without sharding) you can fetch up to six resources in parallel. With HTTP 2.0, you can fetch as many resources as you wish in parallel. The only reason bundling exists as an "optimization" is to work around the limit of six parallel requests. The moment you remove that limitation, bundling is unnecessary and only hurts performance. </div>


<div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
And there's something else I think .zip bundling can provide that http2.0 can't: the guarantee that a set of files are cached by the time your script runs: with such a guarantee you could do synchronous module require()s, à la node.js.<br>




</blockquote><div> </div></div><div><span style="font-family:arial,sans-serif;font-size:13px">This is completely orthogonal... if you need to express dependencies between multiple resources, use a loader script, or better.. look into using upcoming promise API's. As I mentioned previously, bundling breaks streaming / incremental execution / prioritization. </span></div>


<span><font color="#888888">

<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">ig</span></div><div><br></div></font></span></div></div></div>
<br></div></div>_______________________________________________<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>
</blockquote></div><br></div></div>