zahnster

Ever since discovering the Ruby on Rails craze last spring, I’ve been falling more and more interested in frameworks. It’s quite amazing how they help web developers not only develop applications faster, but create them with less code, cleaner code, and more maintainable code.

New frameworks are popping out all the time, and it’s really amazing that this is starting to catch on in the web industry. Ruby has Rails, PHP has Cake, Python has Django… and that’s just the top of the pile.

However, not all frameworks are created equal. In a world where everyone and their mother are getting on the framework bandwagon, one must be wary of what they put time into learning. All too often you find a framework which has become too bloated with features, backwards code, and crappy documentation. But when you can find a good framework and connect with it - well, it can be very empowering. A small development team can take on the world.

So this got me thinking - what makes a framework a great framework or a crap one? What are we, as developers, gaining from frameworks and how can we best utilize them without fattening them up like a Thanksgiving turkey?

The power behind a good framework is actually quite simple, and has been in process for eons. It’s really a method of standardization for programming. Back when we would judge distance by our hands and feet, everyones beds were different lengths. Just like now - we see a programmatical goal - we need to make a affect b. Without frameworks, chances are we’d all program it slightly different. What good frameworks do is set us up with conventions to program - a sub-language of sorts which unifies programmers.

But what kinds of conventions do we need? If we try to cover everything, we’ll end up with a big jumbled mess of 20 parameter functions and an API that scrolls for years. A framework which knows its limits is always going to win over a framework which tries to do everything for you. However, there are several standard conventions which greatly improve frameworks. At the most basic, some really important ones are:

• CRUD functionality
• MVC architecture
• Helpers, Components, and Partials
• Support of 3rd Party Libraries

Why these? Lets dig a bit deeper into the benefits of each:

CRUD FUNCTIONALITY
CRUD is one of the neatest things to come about in the in the web since the conception of standardization. If you’re not up on the buzzword, CRUD is an acronym for Create, Read, Update, Delete, and refers to the MySQL functions you find yourself using a hundred times a day. With a good framework, no longer will you have to connect to your database - it’s been done for you. Your table? Selected. How? Standardization of your code lets the framework do all the redundant work for you. CRUD functionality is now down to a one-line process, drastically boosting development speed and cleaning up code.

MVC ARCHITECTURE
The MVC Architecture, to me, is just beautiful. The ability to separate your database code from your processing code and presentation code is the best possible way to develop. Separating code always helps keep it maintainable - the less you have to echo out HTML statements with PHP, the better. Separating your code into database logic, the application layer, and presentation logic is a very well-organized and efficient logic when you get right down to it.

HELPERS, COMPONENTS, AND PARTIALS
In an MVC world, where code is separated by it’s software role, one might think that this isn’t very DRY. If every view requires a navigation bar, wouldn’t copying and pasting the bar through every view seem a bit redundant?

Well, this is where helpers, components, and partials come in.

These three types of files allow code to be reused through multiple areas of the project. Think of them like the guys at concerts with all-access passes - one partial can display code for every view file in your application. Helpers, components, and partials play a huge role in DRYing up your code, and all the while make it way more maintainable. That horrible nav with the overlays you programmed? It’s stored in it’s own partial - and calling it out on your view pages is reduced to a single line of code.

SUPPORT OF 3RD PARTY LIBRARIES
Since we’re not trying to have our framework do everything for us, there are times when we will need to do something that’s outside our framework’s scope. Cake, for instance, does not have built in support for RSS feeds, but does that mean that we could never tap into an RSS feed?

Not a chance. Just like frameworks, development libraries are popping up all around us. Javascript alone has dozens - from scriptaculous and prototype to jquery. Any good framework will allow you to be flexible with third party libraries - and a great framework will provide you the means to integrate these libraries into it. It shouldn’t be a surprise that most frameworks come with a Vendors folder, or something similar to place and hook up your third party applications.