Live data from Hacker News

Don’t let jQuery’s $(document).ready() slow you down

encosia.com

21–25 of 25 posts

Re: Don’t let jQuery’s $(document).ready() slow you down

#21
post #17

Seems to me that AJAX before document-ready could get complicated once you want to actually do something with the response. Normally one would do something like this: $(document).ready(function(){ $.getJSON(my_url, function(data) { $(' ').text(data.some_text).appendTo('#some_container); }); }); But if we call getJSON before document-ready, the node $('#some_container') may not yet exist! Now we need some way to wait…

The way browsers implement both JavaScript and document rendering via a single-threaded execution queue, that isn't an issue. Once the page begins rendering, callbacks won't have a chance to execute until after the document is rendered and ready. That's the same mechanism that makes the setTimeout(fn, 0) trick work, for example.

It feels a bit like driving fast with no seat belt on, but it's safe.

If you do want to be extra cautious, MBlume's suggestion to wrap the success handler in $(document).ready() works fine too. That's effectively the same as not wrapping it.

Re: Don’t let jQuery’s $(document).ready() slow you down

#22
post #9

Earlier quoted context omitted.

For devs not familiar with jQuery (and on the off-chance that you'll need no-conflicts mode at some point), you might even avoid the dollar sign. jQuery(document).ready(function(){});

On the other hand, if a dev is that unfamiliar with jQuery code, they shouldn't maintaining jQuery code. Using $(function(){}); serves as a nice warning to this effect.

That is an awful argument. Can you imagine what software would look like if people took that approach with everything? Development would have ground to a halt decades ago.

Re: Don’t let jQuery’s $(document).ready() slow you down

#23

Important takeaway: Use Firebug's network monitoring to find out what actually happens when your page loads.

Don't just base your conclusions on one page load, though, as this article seems to do. I wish there was a tool for Web Inspector/Firebug to select various elements over a series of page loads and give me statistics after e.g. 100 refreshes. Page load is highly variable and dependent on things like caching server-side, client-side, within the database, etc. as well as network conditions so repeating the tests is important.

Re: Don’t let jQuery’s $(document).ready() slow you down

#24
post #23

Important takeaway: Use Firebug's network monitoring to find out what actually happens when your page loads.

Don't just base your conclusions on one page load, though, as this article seems to do. I wish there was a tool for Web Inspector/Firebug to select various elements over a series of page loads and give me statistics after e.g. 100 refreshes. Page load is highly variable and dependent on things like caching server-side, client-side, within the database, etc. as well as network conditions so repeating the tests is impo…

None of those conclusions are based on the two screenshots shown in the article. I just set those up and included them for illustrative purposes. The article's points themselves are based on my experience routinely using those optimizations in production.

Sorry if that wasn't very clear in the article.

Re: Don’t let jQuery’s $(document).ready() slow you down

#25
post #22

Earlier quoted context omitted.

On the other hand, if a dev is that unfamiliar with jQuery code, they shouldn't maintaining jQuery code. Using $(function(){}); serves as a nice warning to this effect.

That is an awful argument. Can you imagine what software would look like if people took that approach with everything? Development would have ground to a halt decades ago.

I think the point is that they should learn enough jQuery before maintaining jQuery code.
Post reply on HN