Shift8 Creative Graphic Design and Website Development

Been a while since I wrote a post, I've just been swamped. I've been working on a new (big) project at my day job and was away in NYC for a week and just crazy busy. This new project got me to thinking though. I really would like to compare frameworks. Ok ok that's a dead horse but I don't mean in terms of performance. I don't want to go download a bunch and say "see! see! that one is better! because it's faster on my inaccurate benchmark test!" No, instead I really want to outline how things are built using these frameworks. I've made the decision to kinda stick in one camp of thinking. I've chosen CakePHP and Lithium for very particular reasons... I like how these frameworks work and the direction they are going.

Is it better? I think so, but I can't say it will make your app any faster. Again, I'm not looking at performance. What am I looking at? Things like how easy it is to learn the framework, how many features it has ready to go out of the box, how fast you can build things, how easy is it to work with a team using these frameworks, and so on. This is very important and people always skip it. Honestly, it's saved the company I work for literally thousands and thousands of dollars in man hours and helped the developers there greatly in terms of their stress level and skill level. 

That said. What am I comparing? Well right now I can only really compare Lithium, CakePHP, and Symfony. I haven't really used any other frameworks in enough depth to compare. I understand some of their fundamentals and I know they exist, but without actually doing a project, it's hard to compare. That's what I also don't like about other comparisons you'll find out there. They just simply don't know how to use (or optimize) the framework so of course their benchmarks and opinions are going to be skewed!

CakePHP
CakePHP is perhaps the fastest framework I've seen (or heard of) to build web sites/apps with. You simply can't compete with it's "bake" feature and how much it provides for you out of the box and how many snippets and addons (helpers/components/behaviors) that you'll find for it.

Can it scale? Yes. Does it have the smallest "footprint" out there? No. I don't care about how it performs though because it can be used on large scale sites and it's very fast to develop with. It gets stuff done. Period. That's the basis of the entire PHP language. If we want to work toward some super efficient and fast performing application, we probably aren't going to use PHP. While PHP is become better and faster, it has always been the "get stuff done" language.

CakePHP has been the primary tool that I've used for several years now. The Croogo CMS (that I use on this site) is built on CakePHP and it's a very good CMS. It's flexible and since it's built on CakePHP, I immediately understand how to build plugins and work with the CMS. The idea of these "standards" and "convention" is what makes CakePHP a very solid framework. It also makes it easy to learn. The documentation for CakePHP has become very good. There were some somewhat valid arguments against the quality of documentation back in the CakePHP 1.1 days, but since 1.2 everything has blossomed. 

CakePHP's approach is to "hide" things from the developer. You are presented with many helpers and classes to help you get stuff done as well. There is also convention and by following it, you can build web apps extremely fast. You might call it a "black box" you just put stuff in and voila. However, you can override everything and expand upon things. You can extend classes and add (nearly) anything you need to. Learning more of the advanced practices with CakePHP will take time, but because it's a friendly framework you can start simple and overtime get more advanced. Perfect.

Symfony
Symfony on the other hand is what you might call a "white box" framework. Everything is there and you have to do everything. Doctrine really helps automate things and the framework's use of YAML also automates things, but you still must configure it. So yes, some classes are generated for you automatically, but "how" you work with the framework is very much a known and open process. Making queries is only slightly different than CakePHP, but you have to type more. In general, there is a lot more actual coding that needs to be done with Symfony. 

So it's a configuration monster and there's a million classes, files, and folders all over. It's extremely hard to follow (thank God for "Go To Definition") and the API documentation is terrible. So don't expect any help there. It does have a few decent "books" to follow for learning the basics of the framework. 

This framework is very "exploded" for lack of better words. It starts you off with and kinda forces you to extend and abstract nearly everything. This is very good for very complex applications. This makes working in teams great because you probably won't bump heads often and it gives you a lot of flexibility. However, like I said that isn't to say you don't have the same flexibility with CakePHP...It just means you are starting off in a different direction.

My analogy is like both CakePHP and Symfony are PHP frameworks. Ok, so say a deck of cards. 52. CakePHP is that deck of cards in a box stacked and in order. Symfony is the same exact 52 cards in a bag scattered. You can play a game of cards or you can build a card house with both. The difference is if you want to easily find a single card, you're going to have an easier time with CakePHP. 

That isn't to say Symfony is disorganized, but it's just this giant piece of IKEA furniture that you need to put together. That's another great analogy. You look at the exploded view and you're like WTF? Then at the end of it, you have a ton of left over screws, but perhaps an awesome looking piece of furniture.

Configuration is nice but my personal feeling is that Symfony is overkill. Oh and using YAML when you can just use PHP arrays/objects is just silly.

Lithium
Lithium, the new kid on the block. It's almost unfair to compare since it's built on PHP 5.3 and as a result can use namespaces. Namespaces are critical to a framework for organization and integration with other classes (and frameworks). However, Lithium has many of the same fundamentals that CakePHP has. Obviously no surprise if you know the people involved.

Again, I like this way of working. I like the way classes are named and how the code looks. I feel it's comfortable and efficient. However, Lithium is still young and there aren't nearly as many classes for it as there are for CakePHP. I wouldn't expect that to change too much either though because the goal of that framework is to not add a lot of bulk. It's also designed to work well with other frameworks. So you can use libraries from other frameworks...And this is where the "speed" comes back in. Since you will have more options of "what" you can use, the byproduct will be speed in terms of how quickly you can build something.

Lithium's documentation isn't the greatest of course because it's a young framework. However, it does have a very unique feature and that's the li3_docs plugin...That will basically go through your code and parse your comments to create API style documentation for you! Along with embedding code snippets. This is extremely important for working with a team of people. Also great for your own personal reference.

Lithium also has its own test suite built in. Another killer feature. It makes testing much easier because you don't have to setup a bunch of stuff. You're just immediately ready to go.

Lithium is very well organized, easy to follow it's classes and the API documentation is actually already good. It's far better than Symfony's API documentation. What Lithium doesn't have is a nice "book" that CakePHP and Symfony has...But give it time.

Perhaps the most unique feature Lithium has though that the other frameworks (and any that  are not PHP 5.3) won't have is the filter system. I've written a blog post about it before, but essentially it's the idea of "aspect oriented" programming. It allows you to "tap into" the chain of events from other areas of your application. Used responsibly, this helps you overcome some of the problems that come up when developing applications using these frameworks. We've all been there...You know, when you say, "Oh I wish I could just do this here, but I can't get at this or that" ... or the best one, "I could...but I don't want to 'hack' the core." 

Conclusion
So the winner in this round up? There is no winner. It's your preference. Again, I'm not trying to say which framework is better. My personal preference is Lithium right now because of the listed reasons above. It's also fast. Mad fast. That's important to me, but it's not important to a small site. You may want to use CakePHP to build a simple blog (or use Croogo which gives you most of what you need in 5 minutes) because it's simply faster to do the work and at the end of the day, you'll be able to keep up with traffic demands. 

If you were to benchmark the frameworks, of course Lithium will blow the others out of the water, but again it's unfair to perform that benchmark when Lithium runs on PHP 5.3. 

Symfony, ah...Symfony. I hate it. I'll be honest. However, it does have it's merits and value in a team environment. Is it better for working in teams than the other frameworks? No. We have revision control. Even without revision control (which you need regardless), it's still not "better." It's just different. If you prefer to work with a million little pieces and configure every tiny detail, then you will probably like Symfony. That doesn't make it "wrong" to use. It can scale and be used to do the same things that other frameworks do.

So at the end of the day, you have to look at it as a personal preference. However, I think there are definitely distinct "camps" for "how" we build things and my preference is in the CakePHP and Lithium camp. Obviously I'm busy, I'd love to learn different frameworks to compare those...But I won't have the time. So feel free to leave some comments on your experiences and preferences!