On 25/10/2013, at 08:17, Ilya Grigorik wrote:
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
On Fri Oct 25 11:48 PM, Ilya Grigorik wrote:
On Fri, Oct 25, 2013 at 6:24 AM, Jonathan Bond-Caron jbo...@gdesolutions.com
mailto:jbo...@gdesolutions.com wrote:
I disagree, if you want to treat this as an optimization problem,
let's look at it:
1. x number of resources/files
± How would you suggest to deliver an application over internet (e.g.
± myapp.zip)? Isn't that a bundle already?
This claim is bogus. In all the cases I know, the packages are unzipped by the
OS before running the application, and the application itself has no need to
know anything about the
On Sun Oct 27 09:35 AM, François REMY wrote:
± How would you suggest to deliver an application over internet (e.g.
± myapp.zip)? Isn't that a bundle already?
This claim is bogus. In all the cases I know, the packages are unzipped by
the OS
before running the application, and the
On Sun, Oct 27, 2013 at 6:22 AM, Jonathan Bond-Caron
jbo...@gdesolutions.com wrote:
You wouldn't get faster delivery with a P2P-like algorithm?
e.g.:
Server sends a header:
Cache-clients: my-neighbor.com:4000, my-other-neighor.com:6000
Some security considerations for sure but your claim
± Because using a ZIP file is a bad practice we certainly should not
± allow. As stated before, it will make the website slow [...]
±
± It seems what you're saying is that there are already superior ways to bundle
± JS modules and we don't need W3C to define another one.
± Perhaps—but this
On Sat, Oct 26, 2013 at 9:05 AM, François REMY
francois.remy@outlook.com wrote:
Bundling in general is not going to be a valid approach for any purpose
related to efficiency soon (except maybe archive-level compression where
grouping similar files may improve compression rate slightly).
... 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
?
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
connection ?
Thanks
On Fri, Oct 25, 2013 at 8:39 PM, Ilya Grigorik igrigo...@gmail.comwrote:
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
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
+ 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
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
On 24/10/2013, at 17:06, François REMY wrote:
HTTP 2.0 can send you multiple files in parallel on the same connection: that
way you don't pay (1) the TCP's Slow Start cost, (2) the HTTPS handshake and
(3) the cookie/useragent/... headers cost.
Doesn't connection:keep-alive deal with (1) and
no performance gain over HTTP2), and people will
certainly misuse it (at worse, the performance is much worse than even HTTP1).
As for the general use case of Web App packages (aka Generic Bundling not over
HTTP) - which is a great idea by the way, - this is called an App Package and
this mailing list
On Fri, Oct 25, 2013 at 3:53 AM, François REMY
francois.remy@outlook.com wrote:
± 4.- It's not http2.0 *or* .zip bundling. We could have both. Why not?
Because using a ZIP file is a bad practice we certainly should not allow. As
stated before, it will make the website slow [...]
It seems
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
On Fri, Oct 25, 2013 at 6:24 AM, Jonathan Bond-Caron
jbo...@gdesolutions.com wrote:
On Wed Oct 23 10:17 PM, Ilya Grigorik wrote:
In short, pitching zip bundling as a performance optimization is a
complete misnomer. If anything, it will only make things worse, even
for HTTP 1.x clients.
On 24/10/2013, at 04:17, Ilya Grigorik wrote:
Hey all. Late to the discussion here, but after scanning the thread, figured
it might be worth sharing a few observations...
The fact that we have to bundle files at the application layer is an
unfortunate limitation of HTTP 1.x protocol.
± You're not saying that gzipping and wise pre-fetching and parallel download
± of scripts don't improve page load times. Or are you?
All servers serve GZIPPED version of text files. You don't need a ZIP for that.
HTTP 2.0 can send you multiple files in parallel on the same connection: that
Hey all. Late to the discussion here, but after scanning the thread,
figured it might be worth sharing a few observations...
The fact that we have to bundle files at the application layer is an
unfortunate limitation of HTTP 1.x protocol. Specifically, because HTTP 1.x
forces us to serializes
Le 14/10/2013 23:25, Brendan Eich a écrit :
Jorge Chamorro wrote:
The only work around for that is making as few requests as possible.
+∞, +§, and beyond.
This is deeply true, and a hot topic with browser/network-stack
engineers right now.
It ought to be with software engineers as well and
Le 14/10/2013 23:20, Jorge Chamorro a écrit :
On 14/10/2013, at 22:11, David Bruant wrote:
You already can with inlining, can't you?
Yes and no:
-It's much more complicated than pre zipping a bunch of files and adding a ref
attribute.
-It requires additional logic at the server side, and
On Sun, Oct 13, 2013 at 8:30 PM, Brendan Eich bren...@mozilla.com wrote:
Anne van Kesteren mailto:ann...@annevk.nl
It would require each end point that wants to support this to have new
syntax. A solution from http://wiki.whatwg.org/wiki/Zip#URLs will not
require updating all the end points.
Anne van Kesteren mailto:ann...@annevk.nl
October 14, 2013 6:16 AM
The idea is to use a somewhat more unique separator, e.g. $sub/. Old
browsers would simply fetch the URL from the server and if the server
is written with legacy in mind would serve up the file from there. New
browsers would
On 13/10/2013, at 21:34, Brendan Eich wrote:
Jorge Chamorro wrote:
Are main.js and assets.zip two separate files, or is main.js expected to
come from into assets.zip?
The latter.
I think the latter would be best because it would guarantee that the assets
are there by the time
Le 14/10/2013 15:16, Anne van Kesteren a écrit :
The idea is to use a somewhat more unique separator, e.g. $sub/. Old
browsers would simply fetch the URL from the server and if the server
is written with legacy in mind would serve up the file from there. New
browsers would realize it's a
On 14/10/2013, at 17:20, David Bruant wrote:
How much are we trying to save with the bundling proposal? 200ms? 300ms? Is
it really worth it? I feels like we're trying to solve a first-world problem.
I think that the savings depend very much on the latency. For example from
where I am to
advantages. However, few adopted such
approach for some reason i dont know
Sent from my Windows Phone From: Jorge Chamorro
Sent: 10/14/2013 9:21 AM
To: David Bruant
Cc: Brendan Eich; es-discuss@mozilla.org
Subject: Re: Generic Bundling
On 14/10/2013, at 17:20, David Bruant wrote:
How much are we
Phone From: Jorge Chamorro
Sent: 10/14/2013 9:21 AM
To: David Bruant
Cc: Brendan Eich; es-discuss@mozilla.org
Subject: Re: Generic Bundling
On 14/10/2013, at 17:20, David Bruant wrote:
How much are we trying to save with the bundling proposal? 200ms? 300ms?
Is it really worth it? I feels like
On 14/10/2013, at 18:47, Andrea Giammarchi wrote:
IIRC roundtrip happens once per domain so your math is a bit off.
Can you elaborate? I don't quite understand...
Thank you,
--
( Jorge )();
___
es-discuss mailing list
es-discuss@mozilla.org
Le 14/10/2013 18:21, Jorge Chamorro a écrit :
On 14/10/2013, at 17:20, David Bruant wrote:
How much are we trying to save with the bundling proposal? 200ms? 300ms? Is it
really worth it? I feels like we're trying to solve a first-world problem.
I think that the savings depend very much on
On 14/10/2013, at 22:11, David Bruant wrote:
You already can with inlining, can't you?
Yes and no:
-It's much more complicated than pre zipping a bunch of files and adding a ref
attribute.
-It requires additional logic at the server side, and more programming.
-It's not trivial always: often
On 14/10/2013, at 22:27, Andrea Giammarchi wrote:
AFAIK you have those 500ms delay per roundtrip, as you said, but not per
domain.
I am talking about mobile and radio behavior where fetching from multiple
sources will result in a roundtrip mess/hell but fetching all resources from
a
Jorge Chamorro wrote:
The only work around for that is making as few requests as possible.
+∞, +§, and beyond.
This is deeply true, and a hot topic with browser/network-stack
engineers right now.
/be
___
es-discuss mailing list
This is probably the wrong place to ask the question, but I was just
thinking about the whole HTTP 2 server push thing. In a way, it surely wins
in the # of requests camp if it works as described - you request index.html
and the server intelligently starts pushing you not only index.html, but
also
On 14/10/2013, at 22:11, David Bruant wrote:
You already can with inlining, can't you?
It would also be very interesting to know if you had .zip packing, would you be
inlining?
--
( Jorge )();
___
es-discuss mailing list
es-discuss@mozilla.org
Inline, from the Moon
On Mon, Oct 14, 2013 at 2:22 PM, Jorge Chamorro jo...@jorgechamorro.comwrote:
What I meant with round-trip latency is: once the connection has been
established
I was talking about this latency, those 500ms in my example
, a network packet takes almost 250 ms to go
On Sat, Oct 12, 2013 at 12:07 PM, Brendan Eich bren...@mozilla.com wrote:
However, Russell's counter-argument that fallback in older browsers to
loading lots of little files, request by request, from the server directory
hierarchy, may be too painful, reducing the value as a migration
On Oct 13, 2013 4:40 AM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
On Sat, Oct 12, 2013 at 12:07 PM, Brendan Eich bren...@mozilla.com
wrote:
However, Russell's counter-argument that fallback in older browsers to
loading lots of little files, request by request, from the server
Anne van Kesteren mailto:ann...@annevk.nl
October 11, 2013 12:34 AM
On Fri, Oct 11, 2013 at 3:53 AM, Brendan Eichbren...@mozilla.com wrote:
On Thu, Oct 10, 2013 at 8:10 PM, Andrea Giammarchi
andrea.giammar...@gmail.commailto:andrea.giammar...@gmail.com wrote:
You are confining the
Jorge Chamorro wrote:
On 11/10/2013, at 03:53, Brendan Eich wrote:
On Thu, Oct 10, 2013 at 8:10 PM, Andrea Giammarchiandrea.giammar...@gmail.com
mailto:andrea.giammar...@gmail.com wrote:
You are confining the problem in HTTP only scenarios while the
solution provided by
my latest message was about this situation
www/
my-assets/
js/
my-bundle.js
css/
some.css
image/
some.png
assets.zip
where latter contains the equivalent of the my-assets folder.
The prefetching link won't do a thing in old browsers, might be a directive
for
Andrea Giammarchi wrote:
Agreed that this might be the wrong place but also it's surprising
that there was a W3C recommendation and Mozilla, the most standards
promoter I know, ignored it.
Yes, we went with JSON over XML. Sorry.
/be
___
es-discuss
@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Jorge Chamorro mailto:jo...@jorgechamorro.com
October 11, 2013 6:44 AM
On 11/10/2013, at 15:15, Russell Leggett wrote:
Just wanted to point out a couple of previous attempts at something similar to
generic bundling and the reactions it got
@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Jorge Chamorro mailto:jo...@jorgechamorro.com
October 11, 2013 6:44 AM
On 11/10/2013, at 15:15, Russell Leggett wrote:
Just wanted to point out a couple of previous attempts at something
similar to generic bundling and the reactions it got, because so
On 11/10/2013, at 03:10, Andrea Giammarchi wrote:
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.
Because all the
On 11/10/2013, at 03:53, Brendan Eich wrote:
On Thu, Oct 10, 2013 at 8:10 PM, Andrea Giammarchi
andrea.giammar...@gmail.com mailto:andrea.giammar...@gmail.com wrote:
You are confining the problem in HTTP only scenarios while the
solution provided by
script src=lib/main.js
Le 11/10/2013 03:10, Andrea Giammarchi a écrit :
You are confining the problem in HTTP only scenarios while the
solution provided by
script src=lib/main.js ref=”assets.zip”/script
can be handy/reused in offline packaged applications too so HTTP 2
might win on HTTP but it's not a general HTML
On 11/10/2013, at 12:02, David Bruant wrote:
Providing a zip in the manifest file could work, but I'm not sure I see the
benefit over individual files. Disk fragmentation issues maybe?
One benefit is that a single .zip can fetch a bunch of files in a single
network round trip.
Another is
Le 11/10/2013 12:46, Jorge Chamorro a écrit :
On 11/10/2013, at 12:02, David Bruant wrote:
Providing a zip in the manifest file could work, but I'm not sure I see the
benefit over individual files. Disk fragmentation issues maybe?
One benefit is that a single .zip can fetch a bunch of files
Just wanted to point out a couple of previous attempts at something similar
to generic bundling and the reactions it got, because so far it hasn't
panned out.
Way back in 2008, it was my one and only real contribution to the whatwg
list before getting a little frustrated and moving on:
http
On 11/10/2013, at 13:23, David Bruant wrote:
Le 11/10/2013 12:46, Jorge Chamorro a écrit :
On 11/10/2013, at 12:02, David Bruant wrote:
Providing a zip in the manifest file could work, but I'm not sure I see the
benefit over individual files. Disk fragmentation issues maybe?
One benefit is
Le 11/10/2013 15:15, Russell Leggett a écrit :
Just wanted to point out a couple of previous attempts at something
similar to generic bundling and the reactions it got, because so far
it hasn't panned out.
Way back in 2008, it was my one and only real contribution to the
whatwg list before
On 11/10/2013, at 15:15, Russell Leggett wrote:
Just wanted to point out a couple of previous attempts at something similar
to generic bundling and the reactions it got, because so far it hasn't panned
out.
Way back in 2008, it was my one and only real contribution to the whatwg list
Not sure if this changes anything, carry on.
Server push is happening as part of HTTP 2.0. Do you have a use case in
which it's insufficient?
Not sure if this was directed at me or Jorge, but in case it was directed
at me, I wasn't actually advocating for this anymore, simply acting as a
HTTP 2.0 will require changes to servers for it to work properly, it will
also require that developers learn a bit more about the pipeline or rely on
some vendor to implement the smarts for them.
Asset Bundling on the other hand will provide a quick and easy transition
for most development
As you can see the resource packages attempt got dropped. Perhaps this
proposal will go through because it is tied to the module loader?
It's sad. What happened? Why was it ditched? Was it, perhaps, too ahead of
its time?
Let's try again :-)
As you can see, it basically fell to the same
On Fri, Oct 11, 2013 at 9:57 AM, Jeremy Darling jeremy.darl...@gmail.comwrote:
HTTP 2.0 will require changes to servers for it to work properly, it will
also require that developers learn a bit more about the pipeline or rely on
some vendor to implement the smarts for them.
Asset Bundling on
The way I read the proposal (and I could be wrong here), you would have
copies on your server in the appropriate locations. So I may have a /js/
folder with all my core JS inside it, and a /vendor/*/ with each vendor
package inside of it. I could have multiple asset package's (one for my
core,
Le 11/10/2013 15:51, Russell Leggett a écrit :
Not sure if this changes anything, carry on.
Server push is happening as part of HTTP 2.0. Do you have a use
case in which it's insufficient?
Not sure if this was directed at me or Jorge
To anyone really, trying to understand if
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.
So HTTP 2 wins
Le 11/10/2013 19:01, Andrea Giammarchi a écrit :
As I've said, you keep confining the problem and the solution over
HTTP and servers while I see this approach, maybe slightly revisited,
a good **generic bundling** solution even without a server and easily
adoptable now plus this will not mean
On 11/10/2013, at 15:53, Russell Leggett wrote:
As you can see the resource packages attempt got dropped. Perhaps this
proposal will go through because it is tied to the module loader?
It's sad. What happened? Why was it ditched? Was it, perhaps, too ahead of
its time?
Let's try
About Generic Bundling in:
https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-09/modules.pdf
script src=assets.zip$/lib/main.js/script
It could be reworked as:
link rel=loader type=application/zip href=assets.zip
script src=lib/main.js/script
Simple pattern for packaging web apps
header to support everyone's flavor of compression.
- Jeremy
On Thu, Oct 10, 2013 at 12:30 PM, Jonathan Bond-Caron
jbo...@gdesolutions.com wrote:
About Generic Bundling in:
https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-09/modules.pdf
** **
script src=assets.zip$/lib
response
the |main.js| file is already in cache, and no extra network roundtrips
are incurred!
= Not even a need to load an additional asset.zip
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
Side note (sorry): I missed that PDF the first time around, but from what
I read it looks like good progress is being made. It feels like it's
coming together. : )
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
roundtrips are
incurred!
= Not even a need to load an additional asset.zip
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
response
the main.js file is already in cache, and no extra network roundtrips
are incurred!
= Not even a need to load an additional asset.zip
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
Jeremy Darling wrote:
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.
Oh, and I'll 2nd the way nicer than any AMD solution. This also
keeps readability in mind along with
71 matches
Mail list logo
