In Spring Time, A Not-so-young PHP Programmer's Mind Turns To Frameworks post

March 23rd, 2007

It's my 36th birthday tomorrow (if you really love me, you'll send money to my PayPal account) and as I get older, I get lazier as a programmer. I'm interested in getting the most amount of work done with the least amount of work. So, as someone who fetishizes new web technologies (yes, I can finally admit it) I latched onto web frameworks as a potential solution to my problem. So, I've tried a lot of them: Zend Framework, CakePHP, Symfony, Mojavi (back in the day), and Ruby on Rails (not PHP, but the inspiration for a lot of frameworks).

So, what is it that I expect a framework to do? I expect it to help me build something faster *and* with less hassle. The less hassle part is really important to me. Remember the lazy part above? If it's a hassle, I'm less likely to want to use it beyond my first tutorial. So, if a framework helps me to easily and quickly build a web application, I'm all for it.

Now, at my current job I lobbied to use CakePHP instead of Zend Framework...and lost that fight. Existing apps were build in Zend Framework, and with an ex-Zend guy as a boss, well, it seems like it's going to be Zend Framework all the time. Don't get me wrong, I don't mind Zend Framework (shameless self-promotion: my component for using the webservice that powers Last.fm is in the core for the upcoming Zend 1.0 release) but I just prefer CakePHP. No rational reason, just my fetishizing of the new and shiny. I'm finding myself attracted to lightweight solutions as well.

I wouldn't call Zend Framework lightweight, *but* I can use components of the framework as if they are libraries, instead of only being able to use it as part of an MVC framework. CakePHP isn't there yet, but they are striving for that ability. That turns a framework from being strictly for web applications only from being usable for all sorts of other applications.

Although I can't talk in detail about the project I'm working on (NDA, competitive advantage for our company) I can say that I've been writing PHP scripts that will be run as cron jobs, and using Zend_Config and Zend_Log. Now, I could write my own code to do those things (and have done so in the past) but, again, people smarter than me have put the effort into writing components that work really well without me having to worry about it. That's the less hassle thing I mentioned above.

Where frameworks shine is in their ability to provide helpers for output. CakePHP has some great helpers for doing work with Prototaculous (or is it Scritacutype?) and adding in hooks to allow you build helpers for other Javascript libraries. This is the stuff that can help a programmer who has only a little bit of UI experience create something more interesting. Maybe Terry Chay was right about frameworks. His claim is that frameworks are really good for helping you generate fairly complex output dynamically, but using it for anything else is unnecessary. I don't know if I share that opinion, because not everyone is an ace level programmer who can create well-thought-out architectures, and create elegant modular code that can easily be extended later. Hell, I'm not one of those (yet) but I'm trying.

So, the argument about frameworks will continue on well past the spring. In fact, it will never stop. But people will continue to build frameworks in PHP in order to satisfy egos, not for reasons related to productivity. I guess the fact that something you write will make other people productive seems to be a big bonus. But why are people so zealous about frameworks? I might ramble a bit here, so please be patient.

People want other people to write code for them that they can basically dump into place, tweak like one or two things, and then the app of their dreams will be realized. If the framework doesn't instantly meet their needs, they flame the mailing list about how the framework doesn't meet their needs (which turns out to be so incorrect, either due to their solution to the problem or due to the fact that they can't be bothered to read the existing documentation.)

So developers jump from framework to framework, never settling on one long enough to figure out if one is a solution for them. Applied effort is what really separates programmers, and to use a framework properly you are going to have to not only read the documentation (several times in fact), but probably ask a bunch of questions too. Failure to do this always leads to abandonment of a tool, no matter what it is. So people proclaim that framework X sucks, and go onto something else. And the cycle begins again. All you can do is roll your eyes, make sarcastic comments about these people to your friends on IM and get back to working on stuff with tools you trust.

Ultimately, every developer finds a set of tools that they like to use. Despite almost 10 years of programming experience, I have yet to settle on a common set of tools. Well, the only tool I use quite a bit is PHP for web applications. Yes, I dabble in other things (Ruby via the Ruby on Rails framework) but I keep coming back to PHP. I don't have a common set of libraries I use, instead choosing to use whatever components come with the framework I'm using at the time. Very different from how a lot of developers work, as far as I can tell.

Maybe I'm a nomad programmer. Not in the sense that I wander around from place to place programming, but I wander from component to component, library to library as I program. I wonder how unique this is? Is it an essential skill if you are the type who likes to pick up new technologies and figure out how to use them? Hrm, certainly something for me to dwell upon as I'm having my birthday dinner with my long-suffering wife tomorrow night.

It's clear to me that all my future web applications will involve a framework of some sort, the question becomes will I settle on one now that the "modern web development framework" seems to have stabilized around a common set of mechanics and concepts. Right now it's CakePHP vs. Zend Framework. Sadly, my Rails work has fallen off to the side because I'm not getting paid to build in it, so I don't get to explore concepts that would allow me to rapidly push my Rails skills forward. I'm getting into web services in a big way, and those are totally language agnostic. I'm actually going to try and see if I can create an API for the code I'm using to update the IBL web site. My ability to harness the power of a framework seems to be key to me in order to make these sort of things happen.

Get out there and put the required effort into figuring out if a particular framework suits your need. Get rid of the juvenile "Framework X sucks, Framework Y rocks!" attitude. That's okay in grade school, not amongst even remotely serious developers. Try and be objective and put the goddamned effort into figuring out how to make your particular problem solvable in the confines of a framework. You'll be a better programmers for it.