Frameworks (Part 1)

What’s necessary? What’s optional? And how much, anyway?

The fundamental question when choosing a framework. Do I want a complex framework that offers many features—including some I might not even need? Or would I rather choose a more modest framework that’s easier to grasp and write the missing features myself?

How widely used is the framework?

The simple logic behind this: Quality prevails. Or, if many others are using it, it can’t be that bad. This works especially well in reverse. A lack of search engine results or other indications suggesting the framework’s popularity tends to argue against using it. 

How good and comprehensive is the documentation?

Does the framework provide the components I need for my application? Is it what I’m looking for? Anyone who’s ever struggled through an incomplete or flawed framework description knows this: good documentation saves time. And it saves you frustration. After all, the more comprehensive the documentation, the easier and faster the decision becomes.

What do colleagues say?

A helpful—and sometimes time-saving—supplement to the documentation. What have others already used—and for what? What went well—and where did things get stuck? It takes relatively little time (since others have already invested that time) and provides conversation topics for the next coffee break.