On Mon, Sep 6, 2010 at 10:59 PM, Dmitriy Sintsov <questpc(a)rambler.ru> wrote:
Do browsers support streamed and combined
(archive-like) gz-encoded
content? Then probably minifying will not be neccessary.
Currently this is only readily obtainable by just concatenating the
files. HTTP pipelining would negate most of the point of resource
combining if it actually worked in practice, but it tends to break in
hard-to-catch ways due to transparent proxies that don't support it
correctly. Opera reportedly does pipelining with some sort of
heuristic or fallback behavior so it works reliably. Firefox supports
pipelining, but it's off by default because of the problems it causes:
https://bugzilla.mozilla.org/show_bug.cgi?id=264354
Another proposal in the making to allow this sort of combining more
easily is Resource Packages, a Mozilla proposal:
http://people.mozilla.com/~jlebar/respkg/
This is supposed to make it into the next Firefox after 4.0 last I
heard. Resource packages are easy to deploy (meaning no web server
changes required), but they have to be maintained manually, and have
other inherent limitations.
The medium-to-long-term development that's expected to address this
problem is SPDY, a proposal by Google:
http://www.chromium.org/spdy/spdy-whitepaper
The major drawback is that it not only requires considerable
server-side changes, it also doesn't work with HTTP proxies. In the
end, it will probably be usable only over SSL, but that might not be
such a big issue with DNSSEC finally becoming a reality -- the root
zone has been signed, .com and .net will be within a year, and people
are thinking about how to use DNSSEC to allow HTTPS without having to
pay a CA for a certificate:
http://www.imperialviolet.org/2010/08/16/dnssectls.html
But SPDY has major advantages, basically being a rewrite of the HTTP
wire format for performance, while preserving HTTP semantics (so
applications will still be given the same headers, etc.).
So, yes, this problem is being worked on. :) None of it will
obsolete minification, though, as Roan points out.
Also, it would
be great if these high-level JS-libraries like jQuery actually were
ported into DOM API level (native browser's implementation instead of
extra JS layer).
This is not going to happen. jQuery is way too complicated to be a
reasonable target for interoperable implementation. Furthermore, part
of the goal of jQuery is to be a compatibility layer so that all
browsers look the same even across many years of releases, and this
isn't possible if it's native, so some extra layer will always be
needed. Instead, implementers work on making popular libraries like
jQuery work faster and better, including moving select features to a
native implementation when that will improve performance a lot (e.g.,
querySelector()).
However, these questions are to FF/IE/Opera
developers...
Don't forget Chrome and Safari. I'm not a web browser developer, but
I work with web standards a lot, so I'm fairly informed on this sort
of thing.