No matter how many libraries are out there, we need to have standards. We may be able to survive without them but that is a rough road to proving a point. Business is not just about survival, but also about prospering. Standards are the road map to uniform pragmatic progress and sustainable solutions.
It should be a careful consideration to choose a library.
The lighter a library, the more chance you can manage the code if you need to make changes. This is a truth on its own merit; however, it fails a number of critical aspects of pragmatic thinking. If we modify the core library, will it break us from working with any updates of the core library provider? Do we have the skills to productively manage our own variation? If these are not issues, then a light library could be a great solution.
While we may choose small librarries in some cases, there are other cases where small means it just doesn't do enough. Some evangelists run about singing about everything they don't do. We acquire products for what they do far more than what they do not do. It would be far better to make sure the solution was unobtrusive than light in features. Consider light solutions even if they market them inside out, but make the decision based on implementation.
We also need to consider that a light library may make us provide a lower grade end product. If we hope to hit the end goals, we need to realize that limited manpower, time, and resources will always be factors. Libraries are community or commercial solutions that maximize our chance of success. Evaluate these carefully and council with other experts. Council is perhaps one of the greatest assets to put in our toolkits.
Don't count on being smart enough. Pragmatic experience won't make us smarter, but it will make us wiser. Getting advice and looking at implementations is very prudent. There are many great tools like Google to find information. There are blogs, user group meetings, seminars, and more. When we gather this information, we can also go on forums for advice and store links in tools such as delicious (http://delicious.com/). These tools provide both private and public links.
Frameworks are libraries with an API. Frameworks go beyond two boards being nailed together to concepts you can expect when writing software with them. We build walls with frames that have the boards at every 16 inches in the US. Imagine having someone pre-build all the wall frames and deliver them as a standard package. This is sort of the concept of a framework.
There are light and full-featured frameworks out there. The one that works best for you is the one you should use. It's a choice between building the features yourself, doing without features, or dealing with the features as they exist. Of course, if you are fortunate you will get an unobtrusive framework that provides a method of doing things but doesn't prevent you from doing things a different way.
Most frameworks are designed to code by a single methodology. Some frameworks are designed to work with other frameworks hand-in-hand. This is a particular passion with me. Methodologies are how you write your applications. It could be said they are how you arrange your code.
If we decouple or more loosely couple our methodology from our framework, then more users can build applications according to their personality and use applications we wrote to run side-by-side in the same framework. One advantage of this is, if you become an advanced developer and a client wants you to build a complex application, you can build it in a methodology of your choice. Then the customer can build simpler applications that run side-by-side in a simpler methodology for the same site. This also makes it easier to distribute and reuse applications.
Tip
Invitation
Please note that this book is only one part of what I am doing to share with the community. You will soon see training videos online with screen recordings and more. Visit my blog and website for details, http://www.sosensible.com.