The reasoning is that I’ve never really seen the point of them. To give an example, CakePHP has an HTML helper for creating links – and the code looks a little something like this:
<?php echo $html->link('link text description', '/path/to/link') ?>

Which isn’t really much more efficient than it’s HTML counterpart, written like this:
<a href="url">link text description</a>

In fact, the HTML is shorter to write out. So why even bother with HTML helpers?

I got into the habit of using them, mostly because when I got into the CakePHP framework, it just seemed like the thing to do. It made me feel all Cake-y, and yes, it does come in handy when you are using php variables in the link creation. However, it became abundantly clear to me the other day that it can really cripple regular website maintenance for developers who come into the project not knowing Cake.

One of my clients, who I had created a site for using Cake, needed to change a link in one of the page views, saw the $html->link() function, didn’t understand it, and thought that all links had to be created in this special way. Which is totally understandable – the client doesn’t know a lot about the Cake framework (or frameworks in general), and wasn’t aware that all the link function does is parse out an HTML link (and that he could have just used a normal HTML link and it would have been the same).

So, the question remains – are HTML helpers worth it?

As a Rails developer I’ve seen the limits of ActiveRecord, and the performance issues it gets when dealing with large, complex database types. But to be honest, I’ve never been a big fan of the Ruby language, and part of me assumed that was just Ruby being slow. I was convinced that with a good framework, ActiveRecord could be used (efficiently) in complex database environments.

Yesterday that blind faith was taken to the test as I attempted to optimize a CSV generator. The problem was simple: the query which collected a table’s information, was producing an array which was way too large – the database table had close to 60,000 records and at 9.something MB, was throwing PHP memory allocation errors left and right.

Right now it stands at Heavyweight SQL: 1 / CakePHP: 0. However, I am determined to find a way to make complex databases work well with Cake – I still have a lot to learn about this framework, and I have belief in it.

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.