> As a side-note, why don't people ever talk about testing? And not just linking to some tools, but actually talking about how you figure out what things are worth testing, and how you test em.

I have a screencast on this subject at http://www.letscodejavascript.com . It's been going for three years and has tons of content on this subject.

  > So their "best practices" end up being questionable at 
  > best. Basically, who are you to claim that whatever 
  > you're doing is a "best practice"? It seems like a pretty 
  > bold claim, so I'd argue that it's not unreasonable to 
  > expect someone to back up their claims.

This is why IMHO the best advice comes with a list of pros and cons. It tells me that the author has thought deeply enough about the subject to understand not only the solution, but the contexts where the solution isn't a good fit. (Two books that spring to mind that do this: Patterns of Enterprise Applications by Fowler, and Design Patterns by Gemma et al.)

On the subject of testing, I think it's important that people don't follow testing methodologies blindly.

In the 1960s, Djikstra said "Testing shows the presence, not the absence of bugs", which is true.

Testing is a good tool to prevent regressions. A form of testing that I find quite interesting - and wish more people would look into - is property based testing. A good example of this can be found here http://fsharpforfunandprofit.com/pbt/. Scott Wlaschin is also quite good at teaching across coding paradigms, not just functional.

> and how templates and code should be kept separate... But then I tried it, and I realized just how wrong I was.

Indeed. In fact, experiments with different configurations have led me to start developing large React applications using a system that organizes applications by components like this:

    src/index.js
    src/ButtonThing/index.js
    src/ButtonThing/view.js
    src/ButtonThing/controller.js
    src/ButtonThing/model.js
    src/FormThing/index.js
    src/FormThing/view.js
    src/FormThing/controller.js
    src/FormThing/model.js

Then, you can simply import these components using something like:

    var FormThing = require('../FormThing');

And you can compose them, with one large component consisting of multiple small ones. For this reason, I've found it useful with large applications to create a separate library of smaller components that are used in multiple larger components, so I don't end up having to hard-code multi-level imports (ie, '../../../MyUsefulComponent').

You'd need to use a slightly different structure with ES6 modules, but the main idea is the same.

If you're using something like Flux to manage data, you can probably skip using the `model.js` modules and simply stick with a `view.js` and `controller.js` (or however you wish to name it).

The way I've done this, all CSS goes into the view.js modules, but you could use a separate style.css in each component.

I've found that this organizational approach works great for large JavaScript applications.

Finally, regarding testing, with React I've finally been able to consistently apply easy command-line unit testing to DOM code without worrying about setting up PhantomJS or JSDom and struggling to get initial tests working. It's made unit testing much, much easier, and I find I'm much more inclined to keep a high level of test coverage maintained with React applications than with previous JS applications I've created. React makes testing very easy (I know AngularJS also is said to offer easy testing, but I've not used it outside of a few small JS applications).

Testing requires a certain level of experience that most JS developers just don't possess yet. My hope is over time a few good talks on the subject bubble up to expose more people to the how/when/why

Here is one such example that shows how to build a kanban board from the ground up (test-first). It's from EmberConf back in March but a lot of the concepts are truly framework agnostic

http://youtu.be/2b1vcg_XSR8