For the record, my only problem with certain practises is that they imply, “Do it this way all the time.” There are pros and cons when choosing a particular solution to a particular problem. Slavishly following a paradigm does not always result in an optimum solution.

What I said was that there was a way to make the chaining readable. I’d consider a jQuery call that contained 50 chained call to be a code smell. But if you are binding several events to the same set of elements defined by a single selector, chaining the calls is a valid choice.

IMO, once you’re inside of jQuery any kind of debugging increases in degree of difficulty.

First, I think his chosen example was just that, an example. Take some “real-world” examples, where one might use .css(), .click(), .show(), .hover(), etc. all on one chain.

That being said, I think I agree with the original author though, and not you. I would bet money that his method is less error-prone when maintained — that is, unless you all are elite coders whose code never needs to be maintained, (even after a change in requirements, refactoring, etc)?

So what you’re saying is, even if you have 50 calls, they should all be on the same “chain”? Have you ever written a chain longer than 3-4 calls? It gets even more fun when you try to inline anonymous functions and such.

Breaking up a chain lets you reorganize the chain easier. For example, say you have a long chain, and at several points you filter your collection by using .find(), do some operations, and then you return to your original collection by calling .end(). This is a maintainablity (and readability) nightmare! Sure, it may be easy for you, but reading code is like reading handwriting: its always so much easier when its your own. The poor sap who comes along after you isn’t going to have a very fun time.

Breaking chains is also easier to debug. How are you going to console.log that intermediate value? How are you going to add a debugger statement right before the ajax call?

Lastly, breaking up chains would also be wise in the name of safety. Whitespace can cause all sorts of very hard to diagnose issues, including the dubious semicolon insertion problems and minifier/packer compatibility issues.

The fluent interface design pattern if immensely powerful, however, it can also let you shoot yourself in the foot very fast.

I asked him whether he would assign to intermediate results to make his SQL ‘clearer’, or whether he would use the language to declaratively manipulate sets as intended.

And he blocks comments, most unsporting.

$(“div.highlight”).css({
color:yellow,
background-color:black,
width:50px
});

should be:

$(“div.highlight”).css({
color:”yellow”,
background-color:”black”,
width:”50px”
});

Especially when you have one guy doing the markup and another doing the scripting, rule #1 is really important. You can let someone simply change the view, without breaking the scripting (as long as you keep the same names/IDs of course).