Creating software feels similar to cooking. You need to select recipes, ingredients, and sometimes tools. And, mastering your gut feeling for becoming a software hero or Michelin-star cook takes time. A lot.
On your path of learning what to do and don’t, you will need to make choices. Actually, a lot of choices. Cookbooks or frameworks help you choose to create menu’s or prepare a menu for a dinner party. In web development, Ruby-on-Rails, Twitter Bootstrap or Django help you to quickly satisfy a number of requirements, like dealing with dynamic content or mobile browsers.
But before you jump from cookbook to cookbook, or from framework to framework, you sometimes will be better off by studying single recipe for a salad or a Lasagne. Similarly, single recipes are far more useful in the long term. A dinner party is only 3-5 times a year, while I need to search for simple cooking solutions almost every day. These simple setups are what we talk about when looking at Sinatra, Rack, Compass or Backbone.js. Whereas Frameworks can bring high productivity, libraries give you tremendous levers in many different situations.
Like in cooking, frameworks or menu’s can grow out of libraries or single recipes. As Ruby-on-Rails creator David Heinemeier Hansson explains in this video: “Rails started as an application, it never started as [the framework] Rails. It started as me wanting to build Basecamp. … and I found a need to build a bunch of tools.”
Yet where to draw the line between a menu (framework) and some recipe (library)? Or, as Andrzej asks in the blog post: What is a framework? Menus (and framework) impress people, while endless practice with recipes (libraries) is the only way to become a star cook.
Besides, applying a framework sooner or later confronts you with constraints. For example, with Twitter Bootstrap, how would you use parts of the responsive grid layout without using ‘span’ tags all across the page? Or with Rails, how would you develop a Rails application where you need an advanced database stack or interactive features?
Although the choice of going for a framework or library can be vague, the end-goal for software is not. Software should be designed for others to use. As long as your users are facing standard problems, starting out with “frameworks” is fine.
But from business strategy, it might be important to look at non-standard problems that only can be addressed by using libraries. Instead of managing ever increasing toolsets, it can be very profitable to build new kinds of libraries. Ask 37signals.