Hacker News Reader

Comment by mmaunder | Hacker News Reader

jQuery 1.7.0 is 94K.

jQuery 1.7.0 gzipped is 33K.

I'm performance obsessed since if our biz serves an additional 2K on our widgets it's an extra 1.86TB of transfer/month.

However for most on-site content, 33K is the size of a large image. Most delay loading a web page is caused by latency. Latency in the three way handshake to establish TCP connections and latency for each additional HTTP request even with keepalive enabled. Payload is not as big an issue because it needs fast throughput, not fast round-trip times which are impossible to achieve if you're far away from the server.

Smaller and faster are always good and always worth striving for (in coding). So I don't want to take away from this, especially since it means more eyes on jQuery. I think it's great work. But keep in mind that the speed increase is not going to be enormous and the cost is running a non-standard jQuery that lacks .css(), .ajax() and $(function()).

View on HN

It's not just code-base size that affects performance. There's the latency of the extra network hit, parse js time, etc.

$(function()) isn't included because it's generally bad practice over having javascript run immediately at the bottom before the </body> tag.

If you're site doesn't use $.ajax() why include it? many sites don't use ajax.

$.css() isn't included by default because it's implementation is huge. I prefer to addClass/removeClass (which only causes 1 reflow) or set element styles directly.

> $(function()) isn't included because it's generally bad practice over having javascript run immediately at the bottom before the </body> tag.

Really? I'm not a Javascript expert but I play one on TV and I always thought $(function()) was the standard way of bootstrapping everything safely.

Is the new standard really just Javascript blocks at the bottom? Would love to read more on the pros and cons, got any links?

Yes, Unfortunately this is a common misconception, and is why the Google closure library intentionally leaves this feature out (so people don't use it):

>>The short story is that we don't want to wait for DOMContentReady (or worse the load event) since it leads to bad user experience. The UI is not responsive until all the DOM has been loaded from the network. So the preferred way is to use inline scripts as soon as possible.

>>By intentionally leaving out DOMContentReady wrappers we have been able to prevent Google Apps to use on this anti pattern. -- https://groups.google.com/forum/#!topic/closure-library-disc...

Also see:

http://encosia.com/dont-let-jquerys-document-ready-slow-you-...

http://stackoverflow.com/questions/6026645/document-readyfun...

Just for clarification,

I was looking through Mozilla Developer network. There is no documented DOMContentReady event. There is a DOMContentLoaded [1] event which is target at the document object. There is also a load [2] event fired at the window object. This is fired when the document is completely loaded.

jQuery.ready will use DOMContentLoaded and load as a backup. [3]

It is common for jQuery developers to shove their whole code base into the ready callback, which I imagine would slow a page down.

[1] https://developer.mozilla.org/en/Gecko-Specific_DOM_Events

[2] https://developer.mozilla.org/en/DOM/window.onload

[3] https://github.com/jquery/jquery/blob/master/src/core.js

It's worth remembering that 33K gzipped is still 94K in the browser and memory footprint is still an issue for mobile platforms.

Don't forget the time to ungzip, the time for the js VM to parse etc.

Reply on news.ycombinator.com