Step One: Watch Writing Testable JavaScript - Rebecca Murphey from Full Frontal 2012 (award for worst conference name ever?)
Step Two: Fork this gist.
Step Three: Respond to this question in your fork: Consider the four responsibilities that Rebecca lists for client side code (hint: they're color coded). Respond below with your thoughts. Did any of the responsibilities that she lists surprise you? Do you feel like you mentally split your client side code in IdeaBox and other past projects into these responsibilities?
Step Four: Totally Optional: take a look at some of the other forks and comment if the spirit moves you.
Before talking about those 4, I think what she was talking about with "disentangling" is very important. If you want to test huge, complex functions, its going to be hard but will hopefully result in elastic, reusable, readable, refactored code. Conversely, if you are ('ideally') actually performing TDD, it will help you build more granular code.
Presentation & (User)Interaction:
Data/Server Communication:
Application State:
Setup:
I think Rails kind of corners you into separating out these responsibilities. Convention refines this (keeping business logic in models HTTP stuff (Data/Server Communication) in controllers, Presentation & (User)Interaction in views etc. etc.) I feel comfortable with this structure. In a structureless environment, I find I am more and more influenced by my time in Rails. It starts becomming more and more divided up instead of a mashing of everything together. Even though it is all client side, currently, we have a separate file for each kind of our objects (similar to a model).
I disagree with her view that "You can't write terrible code if you write tests first." That is assuming you write good tests and you are familiar with the syntax you are using to resolve your tests!