unscriptable/bwb18i

## bwb18i
My comment on nettuts+ that didn't get approved (I wonder why) http://bit.ly/bwb18i

It seems that this post started out with good intentions: How to show junior javascript programmers how to use the Firebug profiling commands. However, due to crappy jQuery advice, turned into an illustration of web programming anti-patterns (aka “Programming No-nos”).
I have to agree with James (of course), and would add the following:

———-

Premature optimization.

Do not try to second-guess the framework (jQuery, prototype, dojo, etc.) unless you’ve already got a performance problem. The people who build those frameworks have done an excellent job and have designed them to work well in most situations.

———-

“Try to use an ID instead of passing a class.”

Do NOT use IDs! Use classes! Modern browsers optimize quite well when using classes. There might be a slight performance decline when using classes, but it’s worth it. Even on old browsers that don’t optimize class lookups, it’s still important to use them. Here’s why/how:

Any non-trivial web page can be split into functional areas / modules. Let’s take a chat application that allows multiple chats arranged in tabs. Each tab has a chat stream (with several chat messages in it each with bits of info about author, time stamp, text message, etc), a textarea for text entry, an emoticon selector, and a Send button.

Now let’s say you take Siddharth’s advice and use IDs on all of those elements (let’s focus on the chat stream, textArea, and/or Send button). Well, the first problem is that you need to make each ID unique. “Hm. Ok, we’ll just add a number at the end of each like this: sendButton_1, sendButton_2, sendButton_3…”

So now your server code (or templating engine) just got more complex. It needs to generate unique IDs. Your javascript just got more complex, too. It needs to also generate IDs and IT MUST GENERATE THEM USING THE SAME EXACT ALGORITHM AS THE SERVER.

I’ve seen people do this for several levels of modules. For example, if you wished to place a Like button on each chat message, its id might look like this: id="tab_3_chatMsg_32421_likeButton"

Not only is this ugly, but it also complicates the code, makes it slower (generating unique IDs), and — most importantly — creates an implicit (and likely undocumented) dependency between the server code and client code. This makes it harder to maintain.

[I deleted a long example of how to use the context parameter of the jQuery selector, but decided it was way off topic and probably not fit for the intended audience.  ]

In short, use the context parameter (the second one in the jQuery function): jQuery( selector, [ context ] )

Example:
$(‘.someClass’, contextNode)

You should almost always have this context available. Use it.

———-

“If you’re using jQuery as a replacement for getElementById, but never utilize any of its provided methods, then you’re doing it wrong.”

No. You are doing it wrong, Siddharth. The reason the industry has embraced these frameworks is to ride on the shoulders of giants. What if the geniuses behind jQuery (or dojo or prototype or mootools…) figure out a way to lookup elements even faster than document.getElementById? Or what if a new W3C-approved browser API is added that works better? Furthermore, what if a new feature request is added to the project that requires more than just looking up the element by ID (e.g. add a class or attr to the node)???

Again, premature optimization ruins some perfectly good code. If you are a junior web developer, choose a framework and just use it until/unless there is a performance problem. (Developers should obviously learn techniques to avoid performance pitfalls as you show in the first half of #5.)

———-

OK. Calming down now….

It’s good to illustrate the tools we have in Firebug. I applaud you for that, but please, please, PLEASE don’t preach bad practices to junior developers or you’ll just get flamed by James (and myself).

– John
	My comment on nettuts+ that didn't get approved (I wonder why) http://bit.ly/bwb18i

	It seems that this post started out with good intentions: How to show junior javascript programmers how to use the Firebug profiling commands. However, due to crappy jQuery advice, turned into an illustration of web programming anti-patterns (aka “Programming No-nos”).
	I have to agree with James (of course), and would add the following:

	———-

	Premature optimization.

	Do not try to second-guess the framework (jQuery, prototype, dojo, etc.) unless you’ve already got a performance problem. The people who build those frameworks have done an excellent job and have designed them to work well in most situations.

	———-

	“Try to use an ID instead of passing a class.”

	Do NOT use IDs! Use classes! Modern browsers optimize quite well when using classes. There might be a slight performance decline when using classes, but it’s worth it. Even on old browsers that don’t optimize class lookups, it’s still important to use them. Here’s why/how:

	Any non-trivial web page can be split into functional areas / modules. Let’s take a chat application that allows multiple chats arranged in tabs. Each tab has a chat stream (with several chat messages in it each with bits of info about author, time stamp, text message, etc), a textarea for text entry, an emoticon selector, and a Send button.

	Now let’s say you take Siddharth’s advice and use IDs on all of those elements (let’s focus on the chat stream, textArea, and/or Send button). Well, the first problem is that you need to make each ID unique. “Hm. Ok, we’ll just add a number at the end of each like this: sendButton_1, sendButton_2, sendButton_3…”

	So now your server code (or templating engine) just got more complex. It needs to generate unique IDs. Your javascript just got more complex, too. It needs to also generate IDs and IT MUST GENERATE THEM USING THE SAME EXACT ALGORITHM AS THE SERVER.

	I’ve seen people do this for several levels of modules. For example, if you wished to place a Like button on each chat message, its id might look like this: id="tab_3_chatMsg_32421_likeButton"

	Not only is this ugly, but it also complicates the code, makes it slower (generating unique IDs), and — most importantly — creates an implicit (and likely undocumented) dependency between the server code and client code. This makes it harder to maintain.

	[I deleted a long example of how to use the context parameter of the jQuery selector, but decided it was way off topic and probably not fit for the intended audience. ]

	In short, use the context parameter (the second one in the jQuery function): jQuery( selector, [ context ] )

	Example:
	$(‘.someClass’, contextNode)

	You should almost always have this context available. Use it.

	———-

	“If you’re using jQuery as a replacement for getElementById, but never utilize any of its provided methods, then you’re doing it wrong.”

	No. You are doing it wrong, Siddharth. The reason the industry has embraced these frameworks is to ride on the shoulders of giants. What if the geniuses behind jQuery (or dojo or prototype or mootools…) figure out a way to lookup elements even faster than document.getElementById? Or what if a new W3C-approved browser API is added that works better? Furthermore, what if a new feature request is added to the project that requires more than just looking up the element by ID (e.g. add a class or attr to the node)???

	Again, premature optimization ruins some perfectly good code. If you are a junior web developer, choose a framework and just use it until/unless there is a performance problem. (Developers should obviously learn techniques to avoid performance pitfalls as you show in the first half of #5.)

	———-

	OK. Calming down now….

	It’s good to illustrate the tools we have in Firebug. I applaud you for that, but please, please, PLEASE don’t preach bad practices to junior developers or you’ll just get flamed by James (and myself).

	– John