[sanderjd]

The reason frameworks exist and are often very useful is that if a set of problems is common enough, it is more efficient to do your first few steps once and wrap the outcome up in commonly usable components. "Web application with good UX" is a very common set of problems, so it is sensible to wonder if the leg work has already been done.

[acemarke]

That's pretty much the argument I had to make on my current project. We've got an internal smart client app-in-a-browser that we built last year after throwing away a legacy system. Unfortunately, we were on a tight deadline, and most of the team had little serious JS experience. The client codebase just grew grew randomly, with no real architecture or design, and turned into a giant maze of nested jQuery callbacks and 2000-3000 line JS files. I'd suggested we look into some MVC frameworks before we started development, but then I wound up working on a separate task and no one had time to actually go research, select, and train everyone on a new framework. During the development process, one dev in particular was busy building his own little framework from scratch. Looking at it later, he was basically reinventing Backbone.View, including templating and saving a jQuery reference.

After we hit our initial development deadline, we had time to actually research Angular, Ember, and Backbone. We settled on Backbone on the grounds that we could refactor our codebase incrementally, and it seemed to fit our use case best. Unfortunately, this later led to clashes with the "write it myself" dev, as he didn't want to use any outside frameworks beyond jQuery.

Anyway, having used Backbone for the last year, it definitely has a lot of limitations, but it also provides a very definite set of well-tested pieces that clearly help solve common development use cases. So yeah, very much in agreement with you there. Why try to totally build something from scratch if someone else has already done it for you, and it's been battle-tested by other developers?

[jamesbrewer]

I agree, but I stand by my statement. Asking "What framework should I use?" is not a good sign. Using the process I outlined could easily answer this question.

[sanderjd]

If you start with "how common is my problem?" and the answer is "extremely", then it is reasonable for the next question to be "should I use a framework that solves this common problem?", and you should have very good reasons if you want to answer "no" to that. If you answer "yes", then you have quickly arrived at "what framework should I use?". I guess perhaps we agree that "what framework should I use?" should not be the first question, but I don't think it takes long to get there.

I personally prefer (and find it more fun and a better learning experience) to build things from scratch with no frameworks at all, but I don't think it's a very savvy business decision unless you're doing something very novel.