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
Envoyé : samedi 26 octobre 2013 22:15
À : 'Ilya Grigorik'
Cc : es-discuss
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 <igrigo...@gmail.com> wrote:
On Fri, Oct 25, 2013 at 12:17 AM, Andrea Giammarchi
<andrea.giammar...@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 <igrigo...@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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
