Board index » javascript » design pattern for jQuery dom.ready snippets

cartergilchrist@gmail.com

Registered User

design pattern for jQuery dom.ready snippets

2008-02-26 08:36:19 AM
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

Registered User

2008-02-26 09:02:00 AM

Re:design pattern for jQuery dom.ready snippets

On Feb 25, 4:36 pm, "cartergilchr...@gmail.com"
<cartergilchr...@gmail.com>wrote:
Quote
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,
The general feeling here is that jQuery is not up to snuff.
<URL: groups.google.com/group/comp.lang.javascript/browse_frm/thread/415949d1bcce6e6a/03c4d326340e7f7d>
Quote
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: 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

Registered User

2008-02-26 01:09:00 PM

Re:design pattern for jQuery dom.ready snippets

On Feb 25, 7:36 pm, "cartergilchr...@gmail.com"
<cartergilchr...@gmail.com>wrote:
Quote
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.
Quote
since it addresses a global design pattern, I'm wondering if someone
can help me here. Thanks!!
You came to the right place!
Quote

-----

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
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.
Quote
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.
Quote

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

Registered User

2008-02-26 01:26:00 PM

Re:design pattern for jQuery dom.ready snippets

On Feb 25, 9:09 pm, David Mark <dmark.cins...@gmail.com>wrote:
Quote
On Feb 25, 7:36 pm, "cartergilchr...@gmail.com"
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

Registered User

2008-02-26 03:46:00 PM

Re:design pattern for jQuery dom.ready snippets

On Feb 26, 12:26 am, Peter Michaux <petermich...@gmail.com>wrote:
Quote
On Feb 25, 9:09 pm, David Mark <dmark.cins...@gmail.com>wrote:

Quote
On Feb 25, 7:36 pm, "cartergilchr...@gmail.com"
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.

Quote
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.

Quote
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.
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).)
Quote

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

Registered User

2008-02-27 06:54:00 AM

Re:design pattern for jQuery dom.ready snippets

Peter Michaux wrote:
Quote
On Feb 25, 9:09 pm, David Mark <dmark.cins...@gmail.com>wrote:
Quote
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.
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
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
-
Peter Michaux

Registered User

2008-02-27 10:13:00 AM

Re:design pattern for jQuery dom.ready snippets

On Feb 26, 2:54 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
Quote
Peter Michaux wrote:
Quote
On Feb 25, 9:09 pm, David Mark <dmark.cins...@gmail.com>wrote:
>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.

Quote
>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.

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

Quote
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
*a* goal
Quote
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.
Quote
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.
Quote
If so, your argument is flawed,
No.
Quote
because you overlook
No.
Quote
the default of
It is not default in the Apache configuration of the Red Hat
distribution used in my work.
Quote
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

Registered User

2008-02-28 06:21:00 AM

Re:design pattern for jQuery dom.ready snippets

Peter Michaux wrote:
Quote
[...] Thomas 'PointedEars' Lahn [...] wrote:
Quote
If I understand you correctly, you argue that the goal

*a* goal

Quote
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.
Nonsense.
Quote
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.

Quote
If so, your argument is flawed,

No.
Yes, it is.
Quote
because you overlook

No.
Yes, you do.
Quote
the default of

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.
Quote
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.
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
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>
-
Peter Michaux

Registered User

2008-02-28 06:28:00 AM

Re:design pattern for jQuery dom.ready snippets

On Feb 27, 2:21 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
Quote
Peter Michaux wrote:
Quote
[...] Thomas 'PointedEars' Lahn [...] wrote:
>If I understand you correctly, you argue that the goal

Quote
*a* goal

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

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

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

Registered User

2008-02-28 06:51:00 AM

Re:design pattern for jQuery dom.ready snippets

Peter Michaux <petermichaux@gmail.com>writes:
Quote
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.
--
Joost Diepenmaat | blog: joost.zeekat.nl/ | work: zeekat.nl/
-
Peter Michaux

Registered User

2008-02-28 06:58:00 AM

Re:design pattern for jQuery dom.ready snippets

On Feb 27, 2:51 pm, Joost Diepenmaat <jo...@zeekat.nl>wrote:
Quote
Peter Michaux <petermich...@gmail.com>writes:
Quote
We should be striving to create more connections?!?

Quote
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.
True but when persistent connections are off then each request is a
connection.
We should strive to reduce connections.
Peter
-
Thomas 'PointedEars' Lahn

Registered User

2008-02-28 07:10:00 AM

Re:design pattern for jQuery dom.ready snippets

Peter Michaux wrote:
Quote
[...] Thomas 'PointedEars' Lahn [...] wrote:
Quote
Peter Michaux wrote:
>[...] 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.
Nonsense.

We should be striving to create more connections?!?
Going from one extreme to another, are you?
Quote
Of course we should be limiting the number of connections.
In total, one or two consecutive connections more or less hardly count.
Quote
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

Registered User

2008-02-28 07:12:00 AM

Re:design pattern for jQuery dom.ready snippets

Peter Michaux wrote:
Quote
[...]
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
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>
-