bruant.d at gmail.com
Fri Oct 11 07:13:39 PDT 2013
Le 11/10/2013 15:39, Jorge Chamorro a écrit :
> 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 that a single .zip can fetch a bunch of files in a single network round trip.
>> The manifest file was in response to Andrea's point about packaged app (where he pointed that network requests aren't the only use case), so network round trips don't apply.
>>> Another is than once the .zip has been unzipped, its files can be accessed synchronously.
>> If we're back on the network use case, server push has the same benefits (resource bundling and in-memory availability)... and saves a network round-trip since the resources come along!
> I've read/seen the links you've posted now, thank you.
> HTTP2.0 is awesome, but it requires resource planning a priori, and the cooperation of the server
So does assets.zip. The 2 approaches are equivalent in that regard.
> and a server HTTP2.0 capable. Not sure if the client's http stack does need to be updated too, does it?
It appears so. I don't know how much work that it, though.
But open source is happening. For Node, there is
https://github.com/molnarg/node-http2 (both decently mature from what I see)
People have other incentives to move to HTTP 2.0 (multiplexing by
default, header compression, encryption by default for instance). Every
major websites (Google, Facebook, Twitter, etc.) already support SPDY
and it's been some time now.
The good news is that there is a good fallback strategy for those who're
not ready to upgrade their server.
I'm not too worried about that aspect.
> OTOH the <script src='main.js' ref='assets.zip'> is a 100% client-side solution
Besides deciding which resources should go in assets.zip ;-)
> so it would be compatible with any server of any http version. It requires a browser that implements it though, and preferably a way to feature-detect the capability, of course, so it's not perfect either.
> But the ability to use synchronous require()s, á la node, in a browser would be a big big big win. imho.
Not sure why if we have the import syntax from modules.
The import syntax allows to fetch dependencies while keep parsing. This
is not possible with require(). What's the benefit of require() over
Once we have ES6 modules, not sure we'll need commonJS or AMD anymore
(except for backward compat for some time).
It's time to throw away what we built to work around the language
When HTTP2.0 is deployed, we can also throw away our "concatenation" and
"sprite" so called "good practices" (which existed only for the purpose
of working around HTTP 1.1 limitations).
... it'll be soon time to move on and laugh of how hard front-end
engineering used to be.
More information about the es-discuss