4 ms·

If the non-Backbone version grows from 16 lines to 16000 lines, then the Backbone version will probably grow from 40 lines to 40000 lines, and will still be wor

If the non-Backbone version grows from 16 lines to 16000 lines, then the Backbone version will probably grow from 40 lines to 40000 lines, and will still be worse. I agree with everyone that it's necessary to structure your code, especially as it grows, I just don't think using a generic-structure-fits-all approach like Backbone is the way to do it. The structure should follow the business functionality, not an arbitrary abstraction that helps the developer talk to the computer. You may end up with 16000 lines of javascript, but if they're spread through 1000 modules that are each clearly related to specific business requirements and/or specific controls in the UI, then as a maintenance developer you'll be able to find the 16 lines you need to worry about for any given task quickly and easily, and then you'll be able to understand those lines once you get to them.

scott_w 14y ago
That's not necessarily true. You're not comparing Python to Java, where the verbosity differences are intrinsic to the languages. Programming in the large definitely requires different techniques that can bloat small code examples, but shrink larger code bases. Consider the example of a system that communicates with a server and modifies the layout based on signals and the data the server returns. Backbone can simplify your code by abstracting away some of the details of transferring the data into the rendering code.
pnmahoney 14y ago
Just a thought - 'help[] the developer talk to the computer' is pretty much the goal of most abstractions I've seen (not just javascript abstractions, but, y'know, languages and such). :) The point in Jeremy's post may not seem absolutely consequential in the case of 16 line marginalia; but a common frame of reference that ALSO satisfies 'business requirements' seems pretty desirable to me. That probably has something to do with pretty much all(?) client javascript being either (1) creating/reading some kind of local state Object, (2)updating by way of events you attach to the dom, and (3) the ajax endpoints which send 1 and 2 to the server. So - admittedly green, college senior - I'm not really sure how to elegantly get 1000 modules loosely coupled, or what looks like, but I'm genuinely curious how many (most?) of those wouldn't fall under the three types of abstractions that Backbone gives you. I am intrigued, and I have a feeling that someone's about to point me to some unifying abstraction which espouses this method and ISN'T just the dom?
- Chris_Newton 14y ago
  'help[] the developer talk to the computer' is pretty much the goal of most abstractions I've seen Here’s another thought for you: are those abstractions to help the developer talk to the computer, or to communicate better with other developers, perhaps including themselves a few months later? I'm not really sure how to elegantly get 1000 modules loosely coupled The trick is not to wind up with 1,000 modules that need to be coupled in the first place. Even in the largest systems, it’s rare for more than a few modules to need to communicate intimately at any given level of abstraction. Usually you can break a system down into a few top-level subsystems, maybe break those down into a few layers and divide up the major concepts within each layer, or otherwise decompose your overall system into smaller chunks. This way even if you have a lot of intricate dependencies within a certain part of the system, hopefully you can wrap them up in some sort of higher-level module and present a relatively simple interface to the rest of the system. Even then only certain other parts of the system would depend on that interface directly. This reduces the number of immediate dependencies in your system to some vaguely logarithm-like function of the number of modules in your system and the degree to which you decompose it, rather than something approximating the square of the number of modules if you have an everything-talks-to-everything design. (Edit: Removed any hint of mathematical notation since this is hardly a rigorous formal argument...)

scott_w 14y ago

That's not necessarily true. You're not comparing Python to Java, where the verbosity differences are intrinsic to the languages. Programming in the large definitely requires different techniques that can bloat small code examples, but shrink larger code bases. Consider the example of a system that communicates with a server and modifies the layout based on signals and the data the server returns. Backbone can simplify your code by abstracting away some of the details of transferring the data into the rendering code.

pnmahoney 14y ago

Just a thought - 'help[] the developer talk to the computer' is pretty much the goal of most abstractions I've seen (not just javascript abstractions, but, y'know, languages and such). :) The point in Jeremy's post may not seem absolutely consequential in the case of 16 line marginalia; but a common frame of reference that ALSO satisfies 'business requirements' seems pretty desirable to me. That probably has something to do with pretty much all(?) client javascript being either (1) creating/reading some kind of local state Object, (2)updating by way of events you attach to the dom, and (3) the ajax endpoints which send 1 and 2 to the server. So - admittedly green, college senior - I'm not really sure how to elegantly get 1000 modules loosely coupled, or what looks like, but I'm genuinely curious how many (most?) of those wouldn't fall under the three types of abstractions that Backbone gives you. I am intrigued, and I have a feeling that someone's about to point me to some unifying abstraction which espouses this method and ISN'T just the dom?

Chris_Newton 14y ago
'help[] the developer talk to the computer' is pretty much the goal of most abstractions I've seen Here’s another thought for you: are those abstractions to help the developer talk to the computer, or to communicate better with other developers, perhaps including themselves a few months later? I'm not really sure how to elegantly get 1000 modules loosely coupled The trick is not to wind up with 1,000 modules that need to be coupled in the first place. Even in the largest systems, it’s rare for more than a few modules to need to communicate intimately at any given level of abstraction. Usually you can break a system down into a few top-level subsystems, maybe break those down into a few layers and divide up the major concepts within each layer, or otherwise decompose your overall system into smaller chunks. This way even if you have a lot of intricate dependencies within a certain part of the system, hopefully you can wrap them up in some sort of higher-level module and present a relatively simple interface to the rest of the system. Even then only certain other parts of the system would depend on that interface directly. This reduces the number of immediate dependencies in your system to some vaguely logarithm-like function of the number of modules in your system and the degree to which you decompose it, rather than something approximating the square of the number of modules if you have an everything-talks-to-everything design. (Edit: Removed any hint of mathematical notation since this is hardly a rigorous formal argument...)