Generic Bundling

Andrea Giammarchi andrea.giammarchi at gmail.com
Sat Oct 26 14:29:43 PDT 2013


Apologies, I just answered what Ilya answered but I'd like to see this
discussion ... where is this happening? Thanks a lot and send even off
thread if you can.


On Sat, Oct 26, 2013 at 2:10 PM, François REMY <
francois.remy.dev at outlook.com> wrote:

>  I can’t help but repeat, what you describe is called an app package
> format. Windows 8 has one, Chrome has one, Firefox OS has one; others may
> have one, too. There are discussions about a standardized app package
> format going on, but they are not happening on es-discuss.
>
> Why do you think this discussion belongs to es-discuss? Did I miss
> something?
>
>
>
> *De :* Andrea Giammarchi <andrea.giammarchi at gmail.com>
> *Envoyé :* samedi 26 octobre 2013 22:15
> *À :* 'Ilya Grigorik' <igrigorik at gmail.com>
> *Cc :* es-discuss <es-discuss at mozilla.org>
>
> Is it possible to not put HTTP in the middle of your thoughts?
>
> Why is **non HTTP** bundling a no go?
>
> Don't you donwload a single blob to install chrome and then eventually
> have incremental updates?
>
> Why that single blob at the beginning should not be possible only in JS
> since every other programming langauge has one and working without HTTP in
> the middle? Without servers? Without an internet connection ?
>
> Thanks
>
>
> On Fri, Oct 25, 2013 at 8:39 PM, Ilya Grigorik <igrigorik at gmail.com>wrote:
>
>> On Fri, Oct 25, 2013 at 12:17 AM, Andrea Giammarchi <
>> andrea.giammarchi at gmail.com> wrote:
>>
>>> Ilya ... just to re-clarify what was the discussion about: Generic
>>> Bundling ... not HTTP Bundling.
>>> I don't know why many keep coupling and confining HTML5 over HTTP and
>>> nothing else.
>>> 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.
>>> Why is in your opinion bundling bad for non HTTP, offline, apps created
>>> using these technologies ?
>>> 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 ?
>>>
>>
>> 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.
>>
>> ig
>>
>> [1]
>> http://www.chromium.org/developers/design-documents/software-updates-courgette
>>
>>
>>
>>> On Thu, Oct 24, 2013 at 11:17 PM, Ilya Grigorik <igrigorik at gmail.com>wrote:
>>>
>>>> + 1 to François's comments.
>>>>
>>>> You're not saying that gzipping and wise pre-fetching and parallel
>>>>> download of scripts don't improve page load times. Or are you?
>>>>>
>>>>
>>>> - We already have transfer-encoding in HTTP, and yes, you should
>>>> definitely use it!
>>>> - Prefetching is also an important optimization, but in the context of
>>>> this discussion (bundling), it's an orthogonal concern.
>>>>
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> 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.
>>>>
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> 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.
>>>>
>>>> ig
>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131026/d7712b20/attachment.html>


More information about the es-discuss mailing list