While in principle I agree with you, the article references an extremely simple application for the sake of example. In reality, you would never build an application this simple in this manner. An article showing how to do this with a real webapp from beginning to end would nearly be book-sized.

When building an actual webapp, the Backbone method is going to be much easier to extend, test, and understand versus jQuery spaghetti.

Precisely the point I was going to make. This is a condensed example of translating jQuery-like thinking to backbone-like thinking. To quote kjbekkelund:

> [The backbone] code is more maintainable, easier to reuse and extend, and easier to test.

> I don't know any common name for this, but let's call it mush coding.

"Ravioli Code"

Great observation, in particular the "mush coding" has gotten popular over the years, instead of getting shit done people build abstraction over abstraction and high-level frameworks detached from reality and full of crappy magic. Backbone is a very good example for this (shattering code it into tiny pieces).

I've heard it referred to as lasagne code, because of its many layers.

No, no, no, no. Did I mention no? I inherited a Javascript application that was maybe 1500 lines of code. Every function was 3-5 lines. Most were like this:

  process_foos = function(my_list) {
    for (i=0; i<my_list.lengh; i++) {
      process_foo(my_list[i]);
    }
  }
  process_foo = function(foo) {
    foo.some_method();
  }

And foo.some_method (in another file) was similar. What it meant was it was impossible to get a view of what was going on in the system. It took months to accomplish an understanding that should have taken weeks.

I really think the original authors heard your advice and decided comprehension didn't matter, only function length.

Function should accomplish a task. Sometimes (very rarely) a task may be two hundred lines; usually, it is much shorter. Sometimes three lines, but often 15-20.

I used to believe that, but after a while I realized that it's a heuristic derived from code that's already split up into clear responsibilities.

Large methods are only a symptom that this component of your system does too much and probably has too many dependencies. Small methods do nothing for you except add indirection if you've not solved the dependency problem, and adding indirection to an entangled system is even worse than having large methods.

In other words, somehow an aspect of the end result of clear code became common advice, probably because it's so obvious and replicable. "Write decoupled code with focused responsibilities" on the other hand is nebulous.

It's sort of like when dating advice is simplified into "be mean to girls".

>>Method length should be 1 to 3 lines.

I've read that claim. The only time I really had to work with code like that was horrible.

It was like a book where the sentences were in random order, with the next sentence number appended, so you would have to browse to another page every few words. :-(

The context switches didn't make me productive... Sometimes, I had to look 3-4 levels up or down in the hierarchy to find a parameter type (this was in a scripting language). If anyone talked to me, it took a looong time to rebuild the model in my head.

Edit: In short, grandparent++.

Lasagne is starting to sound a lot like Spaghetti, I guess that's the point.