The landscape of JavaScript MV* frameworks is complicated for anyone just tuning in; when I first tried to get caught up on everything, it was certainly confusing and I had no idea where to start. Once I had it all figured out, I then had the challenge of explaining it to everyone around me, which I couldn't articulate well until I saw this video of Tom Dale and Yehuda Katz. After I saw that, everything I was trying to explain finally clicked and it was just a matter of plotting all of the frameworks on a graph:

The graph is less about each framework's exact position and more about illustrating an idea. That idea is simple:

In order to build any large application you need to use a rigid, opinionated framework.

Now, I'm certainly not saying that if you want to build a large application you have to use something like Ember or Chaplin. What I'm saying is that you have the choice between using a framework that already exists or you'll have to write your own by using one of the low-level libraries and then build up your own opinions on top of that. However you slice it, you effectively end up at the same place before you're able to build a large-scale application.

I've read countless articles about developers using Backbone (or similar low-level library) and most of them sound like this:

"Backbone was rough at the start, but now it's the best! It took us about a year to figure out all of the patterns and structure we wanted, but now that all of the developers are on the same page it's going pretty well."

I'm sorry, but did you say a year? I'm not joking; I actually read an article where it took the team a full year before they didn't hate working with it. What took so long? That was how long it took them to figure out how to structure their code, and define their internal patterns and best practices in a way that made sense for all of the developers on the team.

Wow.

Sure that's Backbone though, and everyone knows that Backbone is only a library. Well, I know lots of people love Angular and believe it's the best thing out there, but I really think it is midway between a library and a framework. It gives you more tools and higher-level abstractions than something like Backbone or Knockout, but it completely abandons you on when it comes to application structure and best practices. After watching one of the teams at Google talk about their experiences building a large Angular application, it just reinforced my view; a lot of what they talk about is their struggle to find a structured way to build the application. That's right, Google is struggling to find structure with their own tool.

I'm not saying that any specific library or framework is good or bad. All I'm saying is that you should pick the right tool for the right job. You shouldn't waste your time figuring out best practices and code structure if there's already something out there that's close enough. Of course, if you're only building a small application or there's only one developer, the benefit of the larger frameworks isn't as clear and it's more likely to just get in your way. In the end, you should be spending your time solving problems unique to the application you're building and not fiddling around with the tooling underneath it.