Frameworks don't have to do everything and more
While the concept of Frameworks isn’t recent, the buzz surrounding frameworks has grown to a point where it’s nearly impossible to read news not mentioning a brand new XXX framework which will revolutionize the way we build web applications/sites.
Since this post is about frameworks in general, and not about specific ones, some statements may not be appropriate to all. This isn’t a feature by feature comparison of frameworks but some thoughts on what to avoid if you plan to build your own.
But What is a the point of using a framework ?
From wikipedia:
Frameworks are designed with the intent of facilitating software development, by allowing designers and programmers to spend more time on meeting software requirements rather than dealing with the more tedious low level details of providing a working system.
The motivation behind using a framework is to bring back the fun to programming. Even though you enjoy building websites, there are always some stuff that boring, and always the same. You can’t avoid it. By using a framework, you can make abstraction of all this stuff and focus on developing what makes your application/website unique/interesting.
How is a framework different from the collection of useful functions I have collected ?
There’s a name for a collection of functions and it’s called a library.
From wikipedia:
A library is a collection of subprograms used to develop software. Libraries contain “helper” code and data, which provide services to independent programs. This allows code and data to be shared and changed in a modular fashion.
See the difference ? A framework aims to provide a working system while a library aims to share code & data among different programs.
They both serve different purposes, and thus, should be used in a different manner. This doesn’t mean that they couldn’t be used together. Many back-end frameworks have native implementations of front-end libraries, generally in the form of helpers.
So what’s wrong with frameworks ?
There’s nothing inherently wrong in using a framework. It’s a time-saver and motivation keeper and I really encourage everyone to use a good framework for the next web application/site they’ll build. The subtle nuance is using a good framework.
After several iterations (from Alpha to version 8.5 …), most frameworks become bloated and reach a stellar level of complexity. As the framework gets used more and more by different people and for different applications, developers/maintainers can’t refrain from adding more functionalities to their framework in order to cover the new needs which arose during their most recent development.
While this might sound like a good idea, it definitely isn’t. It is really difficult to differentiate what’s specific and what’s generic about an application/website. This is the main reason why some frameworks are good and some just plainly suck. This is where the difficulty of building a framework resides. Being able to determine the tipping point between something that makes things easier for you and something that gets in your way is crucial to ensure the success/usefulness of the framework.
If framework developers fail to do this, they’ll reach the point where this unneeded complexity defeats the intent of the framework which is to facilitate software development.
The 80-20 rule
Beyond its technical marvels, the Ruby on Rails (RoR) framework popularized (or invented ?) the mantra of convention over configuration. It basically means that 80% of your application is similar to every other application out there. There’s no offense to be taken here, human beings and chimps have close to 100% similarity in their DNA, so 80% of similarity between applications should not be a hurdle to your imagination or creativity. The remaining 20% are your application specifique & unique DNA, what makes it stand out (and makes you proud!).
If we push this idea a tiny bit further, it wouldn’t be a non-sense to say that if less than 80% of the people using your framework will use the functionality you plan to add, then, you should reconsider adding it to the core of the framework.
This doesn’t mean that the functionality has no use, it simply means that since not all people will use it, there’s no point in adding complexity. It’s probably best suited for a plugin or an extension (because there’s no way your framework can be successful if it doesn’t provide this kind of functionality).
Here’s a smart quote from the Getting Real book by 37signals :
Each time you say yes to a feature, you’re adopting a child. You have to take your baby through a whole chain of events (e.g. design, implementation, testing, etc.). And once that feature’s out there, you’re stuck with it. Just try to take a released feature away from customers and see how pissed off they get.
What are the alternatives to frameworks ?
Since most frameworks are based on a handful of architectural patterns (MVC, Three-tier, SOA …) and since those patterns are well established and well-known by rigorous developers, frameworks may be overkill for some people, or not best suited to their specific needs. In this particular case, I’d recommend dropping the framework in favor of a development starting kit (SDK). I’m not talking about a full-featured SDK with IDE, debugging tools and the like, but something along the line of some files and directories to get you started. Duplicate & modify some, and you’re almost ready to go.
It has the merit of ditching the big black box approach that some frameworks have adopted, and let you fully grasp the concepts/patterns that your application will be built upon.
The concept of this Super-light SDK is easily transportable to a bunch of different back-end as well as front-end technologies. Of course the trade-off of such an option is that you’ll have more code to write which makes it more prone to errors and non-standard implementations/architectures, but it offers an unprecedented amount of freedom (only outplayed by the super-hero-100%-hand-code approach) and lets you get rid of some boring setups.
For the story, I recently had to get two frameworks (one front-end and one back-end) to talk to each other and I can’t recall one moment during which I was thankful to be using one of those frameworks, so both combined was just a nightmare.
Here is a list of frameworks I commonly use:
- Code Igniter for rapid PHP development
- Webpy the anti-framework written in Python
- ASP.NET MVC - can’t wait to use it in production.
and a short list of frameworks you really shouldn’t miss: