design pattern for jQuery dom.ready snippets

cartergilchrist · Feb 26, 2008

Hi there,
I have tried posting this in the jQuery group with no response, and
since it addresses a global design pattern, I'm wondering if someone
can help me here. Thanks!!

-----

I am going to be implementing jQuery on a very large enterprise level
website, and have a few questions with regards to some best-practices
for managing scripts.

Where is the best place to include all of the initialization code for
plugins? I'd like to keep everything external, but since the site is
so large, I can't put all of the dom.ready initilizers inside of one
big .js file (like jquery.com). I need to keep things split up for
specific sections of the site, and if a plugin is only required for
one specific page, do I create a new .js file just to run that
specific initializer, or do I bite the bullet and stick it in the
<head> of the page itself? I am trying to take advantage of browser-
cache as much as possible, which also makes a global .js file
unappealing since adding a snippet for one page would make browsers
have to dump the cache across the board, even if they never visit that
one page.

Any suggestions or thoughts would be great, along with some examples
of other large sites that handle this problem well. Thanks very much!

Peter Michaux · Feb 26, 2008

Hi there,
I have tried posting this in the jQuery group with no response, and
since it addresses a global design pattern, I'm wondering if someone
can help me here. Thanks!!

The general feeling here is that jQuery is not up to snuff.

and have a few questions with regards to some best-practices
for managing scripts.

Where is the best place to include all of the initialization code for
plugins? I'd like to keep everything external, but since the site is
so large, I can't put all of the dom.ready initilizers inside of one
big .js file (like jquery.com). I need to keep things split up for
specific sections of the site, and if a plugin is only required for
one specific page, do I create a new .js file just to run that
specific initializer, or do I bite the bullet and stick it in the
<head> of the page itself? I am trying to take advantage of browser-
cache as much as possible, which also makes a global .js file
unappealing since adding a snippet for one page would make browsers
have to dump the cache across the board, even if they never visit that
one page.

Any suggestions or thoughts would be great, along with some examples
of other large sites that handle this problem well. Thanks very much!

I wrote a blog article about build process today. It might help.

<URL: http://peter.michaux.ca/article/7346>

Don't become obsessed with optimizing for the browser cache. It is
good to take advantage of the cache but becoming obsessed with it
could make the whole system difficult to maintain.

Peter

David Mark · Feb 26, 2008

Hi there,
I have tried posting this in the jQuery group with no response, and

And if you had received a response, it would likely not have been from
a JavaScript programmer, but from a Web developer who plays one on the
Internet.

since it addresses a global design pattern, I'm wondering if someone
can help me here. Thanks!!

You came to the right place!

Bad idea (to say the least.) Despite widespread use, jQuery is
completely inappropriate for use on the Web. Any script that treats
non-IE agents (e.g. mobile devices) as IE is a recipe for disaster.
Concerning this issue (and many similar ones), the jQuery community
has a "so what?" attitude, which is simply a front for a "what now?"
aptitude. Don't follow them into the abyss.

I wouldn't even recommend it for a private Intranet. The primary
author has been proven clueless about JavaScript and cross-browser
development. It makes no sense for an enterprise to rely on such a
person for JavaScript code.

for managing scripts.

Where is the best place to include all of the initialization code for
plugins? I'd like to keep everything external, but since the site is
so large, I can't put all of the dom.ready initilizers inside of one
big .js file (like jquery.com). I need to keep things split up for
specific sections of the site, and if a plugin is only required for
one specific page, do I create a new .js file just to run that
specific initializer, or do I bite the bullet and stick it in the
<head> of the page itself? I am trying to take advantage of browser-
cache as much as possible, which also makes a global .js file
unappealing since adding a snippet for one page would make browsers
have to dump the cache across the board, even if they never visit that
one page.

If functionality is specific to one page and you are fairly sure you
won't have to duplicate it for others in the future, then it makes
sense to put the initialization code in the head of the document.

For modules that are used for the majority of the pages, combine the
code in a single external file. Build additional files for section-
specific code.

Your goal should be to minimize the downloading of unused code.
Strategies to accomplish this are at odds with the concept of general
purpose do-everything JavaScript libraries.

Any suggestions or thoughts would be great, along with some examples
of other large sites that handle this problem well. Thanks very much!

When it comes to issues like this, it is hard to find good examples on
the Web. Most large sites are using large, monolithic libraries like
Prototype and jQuery and include the code in every page, whether they
need it or not.

Peter Michaux · Feb 26, 2008

On Feb 25, 7:36 pm, "(e-mail address removed)"

If functionality is specific to one page and you are fairly sure you
won't have to duplicate it for others in the future, then it makes
sense to put the initialization code in the head of the document.

For modules that are used for the majority of the pages, combine the
code in a single external file. Build additional files for section-
specific code.

Your goal should be to minimize the downloading of unused code.

And the number of connections during page load which is why the
question comes up at all. This is all balancing tradoffs. In
production I think three JavaScript files in a page would be a common
maximum: one for site wide code, one for section code and one for page
specific code. If the page specific code is really small it could go
directly in the HTML of the page to save a connection.

I haven't studied it but I would be interested to know how many bytes
of file is equivalent to making an extra connection. I know there are
*many* variables involved but ultimately this is a major factor in
making the decisions about modularity. If making a connection is very
expensive then having just one JavaScript file per page that includes
the site-wide, section-specific and page-specific code may make sense.
Yes the site-wide code would be re-downloaded for every page but the
net time could be less.

Peter

David Mark · Feb 26, 2008

And the number of connections during page load which is why the
question comes up at all. This is all balancing tradoffs. In
production I think three JavaScript files in a page would be a common
maximum: one for site wide code, one for section code and one for page
specific code. If the page specific code is really small it could go
directly in the HTML of the page to save a connection.

Absolutely. Three at a maximum and put as many as you can at the end
of the body, rather than in the head (to allow the page to render
before the browser has to stop and download/evaluate the script(s).)

I haven't studied it but I would be interested to know how many bytes
of file is equivalent to making an extra connection. I know there are
*many* variables involved but ultimately this is a major factor in
making the decisions about modularity. If making a connection is very
expensive then having just one JavaScript file per page that includes
the site-wide, section-specific and page-specific code may make sense.
Yes the site-wide code would be re-downloaded for every page but the
net time could be less.

Too many variables to figure I think. Another concern, as the OP
noted, is how often the files may be updated. This is another
variable that may be hard to quantify during the design phase.

Thomas 'PointedEars' Lahn · Feb 26, 2008

Peter said:
And the number of connections during page load which is why the
question comes up at all. This is all balancing tradoffs. In
production I think three JavaScript files in a page would be a common
maximum: one for site wide code, one for section code and one for page
specific code. If the page specific code is really small it could go
directly in the HTML of the page to save a connection.

If I understand you correctly, you argue that the goal of the Web developer
should be to limit the number of HTTP connections made when accessing a Web
document in order not to slow down other HTTP clients or other data exchange
over HTTP data in the same user agent.

If so, your argument is flawed, because you overlook the default of
persistent connections since HTTP/1.1 and that one of a HTTP/1.0 connection
being closed before another one is opened by default. That includes
included script resources that are loaded one after the other.

PointedEars

Peter Michaux · Feb 27, 2008

If I understand you correctly, you argue that the goal

*a* goal

of the Web developer
should be to limit the number of HTTP connections

It should be a goal to limit the number of connections. Making
connections is expensive.

made when accessing a Web
document in order not to slow down other HTTP clients or other data exchange
over HTTP data in the same user agent.
Correct.

If so, your argument is flawed,
No.

because you overlook
No.

the default of

It is not default in the Apache configuration of the Red Hat
distribution used in my work.

persistent connections since HTTP/1.1 and that one of a HTTP/1.0 connection
being closed before another one is opened by default. That includes
included script resources that are loaded one after the other.

Where I work the Apache administrator does not allow persistent
connections (also known as pipelining) because it adds load to the
server enough to cause a problem and that ultimately slows down user
experience for all users.

Peter

Thomas 'PointedEars' Lahn · Feb 27, 2008

Peter said:
*a* goal

It should be a goal to limit the number of connections. Making
connections is expensive.
Nonsense.

No.

Yes, it is.

No.

Yes, you do.

It is not default in the Apache configuration of the Red Hat
distribution used in my work.

Then you have a much greater problem than I thought. The default is there
for a reason.

Where I work the Apache administrator does not allow persistent
connections (also known as pipelining) because it adds load to the
server enough to cause a problem and that ultimately slows down user
experience for all users.

I daresay your company employs an incompetent Apache administrator, for
Apache allows a very fine tuning of persistent connections.

Nevertheless, so in your case the connection is closed before another one
is opened, and there is no jamming. q.e.d.

PointedEars

Peter Michaux · Feb 27, 2008

Nonsense.

We should be striving to create more connections?!?

Of course we should be limiting the number of connections. Making a
connection is expensive and why persistent connections were invented
in the first place. There are various ways to limit the number of
connections. Persistent connections are one way.

Peter

Joost Diepenmaat · Feb 27, 2008

Peter Michaux said:
We should be striving to create more connections?!?

Of course we should be limiting the number of connections. Making a
connection is expensive and why persistent connections were invented
in the first place. There are various ways to limit the number of
connections. Persistent connections are one way.

Most browsers have a hard limit on the number of connections (IIRC
firefox limits to 2 connections). There isn't really anything you can do
to increase or decrease them.

Reducing the number of requests is not the same thing.

Peter Michaux · Feb 27, 2008

Most browsers have a hard limit on the number of connections (IIRC
firefox limits to 2 connections). There isn't really anything you can do
to increase or decrease them.

Reducing the number of requests is not the same thing.

True but when persistent connections are off then each request is a
connection.

We should strive to reduce connections.

Peter

Thomas 'PointedEars' Lahn · Feb 27, 2008

Peter said:
Peter said:

[...] Thomas 'PointedEars' Lahn [...] wrote:
If I understand you correctly, you argue that the goal
*a* goal
of the Web developer should be to limit the number of HTTP
connections
It should be a goal to limit the number of connections. Making
connections is expensive.

Click to expand...

Nonsense.

Click to expand...

We should be striving to create more connections?!?

Going from one extreme to another, are you?

Of course we should be limiting the number of connections.

In total, one or two consecutive connections more or less hardly count.

Making a connection is expensive and why persistent connections were
invented in the first place. There are various ways to limit the number
of connections. Persistent connections are one way.

You and your company's Apache administrator should read RFC 2616,
section 8.1 in order to understand what you are talking about.

PointedEars

Thomas 'PointedEars' Lahn · Feb 27, 2008

Peter said:
[...]
We should strive to reduce connections.

Tell that to your company's Apache administrator who deliberately breaks the
good default introduced with HTTP/1.1.

PointedEars

JQuery add shadow error	4	Sep 1, 2023
Jquery not triggering / acting as expected.	0	Mar 6, 2022
jQuery Scrapping & Formatting Inputted Paste	2	Sep 30, 2020
jQuery 3 part slider	0	Apr 20, 2016
A Brief Review of jQuery 1.5	13	Feb 13, 2011
jQuery vs. My Library	155	Jan 22, 2010
JQuery Ajax	3	Jul 24, 2010
More attribute-related jQuery futility	1	May 15, 2010

design pattern for jQuery dom.ready snippets

cartergilchrist

Peter Michaux

David Mark

Peter Michaux

David Mark

Thomas 'PointedEars' Lahn

Peter Michaux

Thomas 'PointedEars' Lahn

Peter Michaux

Joost Diepenmaat

Peter Michaux

Thomas 'PointedEars' Lahn

Thomas 'PointedEars' Lahn

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads