...but are in a position to approve or reject a framework, I suggest that you don't do that. But if you really want to or even don't want get your hands on any code, you may do the following.
- Go to the frameworks' home page and find their success cases and count their number, for example Backbone.js's success cases, AnguarJs's success cases, Ember.js's success cases. If some of these success cases appeal to you, don't jump to the conclusion to use that framework, because very likely at the time you are reading the post, the company might have already switched to use another framework. People tend to brag about their success but not failures. If people are doing something that seems to be the right choice in the beginning, and they tell you immediately, but later when they found that it is a wrong choice, they will not tell you. Five years ago, I was asked to join a company to develop an Silverlight application. This year, I was asked by them to rewrite their app based on the web platform. Two years ago, a company asked me to join them develop their killer app using b.js, and this is the same company that asked me to them to migrate their app from b.js to a.js.
- Find out who are the people behind the framework. If you think the people behind a framework are better than the people of another one in terms of ability, then that framework may be better (not necessarily). Sometimes, the competition is not between frameworks, but the people behind. A few years ago, I liked more Steve Jobs more than Steve Ballmer, so I just bought Apple stock, but not Microsoft. Since Steve Jobs is gone, I don't buy Apple stocks anymore.
You should choose a framework purely based on the technical aspect. You should forget about everything from above, just like the judge tells jury that their decision should not be influenced by the media. You can do the following.
- Go to http://todomvc.com/, download their source code at https://github.com/tastejs/todomvc , read the source to see how they implemented the same use cases, and see if it makes sense to you. Narrow down at least three choices. Then use the three choices to you implement the the same todomvc application by yourself. You can of course refer to original source code.
- Go to their document website and read their documents.
- Implement several of the most important use cases of your project with your three shortlisted frameworks. Getting your hands dirty is very important, and your effort in evaluating the frameworks that you will end out not choosing will not be wasted. Instead, it will help your to understand your domain problem, and the technical advantage of chosen framework. Most of these frameworks or libraries require you to write your application by following a convention, which is understandable, because convention means reusability, readability, and maintainability. The framework calls your code instead of you calling the framework. While you are implementing, answer questions such as: Does the convention have a deep learning curve? Does the convention require me to write lots of boilerplate code?( You want to write code fast.) Does this convention provide extensibility and does it have too much encapsulation which prevents you from achieving some "special" but really important use case? Is it easy to test my application code? Does it provide unit test support, or am I on my own to create my test infrastructure.
After going through all the process above, and you feel that, let's say, a.js is your choice, it is important that you know how to take advantage the best feature of it. Equally important is to its problems, gotchas, inefficiencies and solutions to overcome them. If you know both sides of a framework, and you feel the benefits outweigh its costs to develop your application, then it is a good choice.
But this is not the end. You need to invest a significant amount of time to study your chosen framework. If you don't study enough, you might feel that framework was a wrong choice after some time down the road. The reason could be that you are not using it in its best practice. Be patient. Learn from their community, read their source code. Some frameworks are "long term efficient, short term inefficient."
If you still don't like the framework or maybe there are better frameworks coming up, you need to have the courage to admit it was your mistake and switch gears, as even Mark Zuckerberg can admit a mistake. But don't blame the frameworks. Their creators unselfishly provided them for free, and their work should be respected.