On Mon, Sep 6, 2010 at 10:59 PM, Dmitriy Sintsov questpc@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.