Initial thoughts on Yii..

My initial thoughts on the Yii PHP framework can be summed up in one word:  Hell yeah!  Okay, it was more like two words, but it doesn't change the fact that I am very impressed so far with Yii.  Admittedly I have not done any extensive work with the framework as of yet.  The majority of my experience with Yii to date has been reading the (very good) documentation, playing around with its code generation utilities, and looking at how the demo applications were built.

So far the aspect of the framework I am most impressed with is how it is integrated with JQuery.  CakePHP injects javascript code throughout the page, a practice that most Jquery developers cringe at the thought of.  This is also why most Cake developers have abandoned the use of the JS helpers in favor of writing their own code.  This is why I like how Yii integrates JQuery so much: for the most part it separates the JQuery code into separate files and includes them at the top of the script.  This makes me happy.  This will also reduce the amount of time I spend creating my own custom JQuery scripts, since I will actually be using the helpful functions that are included with Yii.

Another aspect of Yii that I am impressed with is its documentation.  Cake has some good documentation, but often key elements are outdated or missing. What is also frustrating is the lack of documented best practices to use with the framework. I often found my answers from blog posts or forums, and wondered why such simple answers weren't included in the documentation to begin with.  This is not the case with Yii.  The documentation itself is very thorough, updated constantly, and very clearly defines best practices. What's more is the generated code as well as the demos it ships with show the majority of the functionality shipped with Yii in use.  This is great because if I want to see how to create a form in Yii I can either consult the documentation or pull up any of the demos that came with the framework. Handy!

Finally, the code generation utility shipped with yii is excellent.  In just a matter of minutes, Yii can generate a fully-functioning skeleton application complete with a login/logout system, contact form, CRUD, database access, etc.. all integrated with JQuery.  This has been a great skeleton to start with, and has managed to save me loads of setup time integrating basic components into the application.  (I can't say the same for Cake's skeleton application that is generated).

When I began playing around with Yii, I fully expected to find parts of the framework where I would sit back and reminisce of my days in the Cake world.  To my surprise, the more I learn about Yii the happier I am to embrace it.  Nothing against Cake, but I would recommend Yii to any developer looking for a powerful MVC PHP framework.

Switching PHP Framework from CakePHP to Yii

After about a year of developing with CakePHP, I have decided to make the switch to Yii.  There are several reasons I decided to make this switch, but the biggest one was performance related.  Don't get me wrong, I think CakePHP is a great development framework.  There were enough things that I personally did not like about Cakephp to justify my switch to learning a new MVC framework.  Here are a few of the reasons I decided to make the switch:

1) Yii is PHP 5 only.

      I really like PHP 5.  While CakePHP supports PHP 5, it also has to support PHP 4, and thus does some things under the hood which hinders its performance a little in order to support legacy PHP code.

2) Yii supports composite primary keys.

      One problem I had with CakePHP was how it did not support composite primary keys.  While this wasn't a huge deal breaker for me in Cake, it was definitely annoying.  Instead, every table had to have a unique ID as the sole primary key and your "composite" keys basically just had to be maintained through your own code.  Not terrible, but still rather annoying.  One thing I really did not like was how CakePHP thought that a "Has One" relationship should work in a database.  Take the example of Apple has one Banana.  Every textbook will tell you that to be in a proper normalized state, the Apple table will contain a field called 'banana_id', which will contain the ID of the corresponding Banana row.  This ensures that the Apple field can only contain one banana reference.  This is easily verified since Apple.banana_id holds one and only one value at a time.  Straight out of the CakePHP hasOne relationship documentation, it clearly states quite the opposite.  Does this produce a hasOne relationship?  Well, when you access models via Cake's API then sure it will hand you back one row, but your database is not in a normalized form.  There's technically nothing stopping you from firing up PhpMyAdmin and adding a few rows with the same Banana.apple_id.  This also means that if you are not careful with your queries or the way you access your data in Cake, you may end up with data redundancy.  This is why putting your databases in a normalized form is so important. There are ways around this in Cake but they require quite a bit of extra work, which of course defeats the purpose of its advertised "magic" in the first place.

3) CakePHP is too slow for my needs.

      If you search google for "CakePHP" and "Slow," you'll see many, many posts from developers wondering why they're application is responding so slowly.  You'll also notice that there are no real good answers as well.  Is CakePHP really that slow?

The quick answer:  No actually, it isn't slow.

Let me explain myself.  CakePHP can be fast.  By default however, it is very, very slow.  When you develop your application you will need to keep caching and performance in mind, something that most developers new to PHP frameworks don't do.  The problem is that in order to develop a fast CakePHP application, you cannot use the majority of the magic that Cake provides.  For example, Cake's documentation and tutorials will lead you to use mod_rewrite for pretty URLs (using .htaccess) and $this->link() to create formatted html links quick and easily.  This creates a lot of easily maintainable functionality quickly, but your performance will suffer greatly down the road.  Even an application relying heavily on XCache and Memcached still needs lots of customized work tailored specifically to your application in order to speed it up.  While this will be true with an application developed in Yii as well, its default performance is significantly greater than Cake's.  So while people complaining that Cake is slow are not necessarily right, you will have to work hard to get it speedy.

This post isn't meant to bash Cake.  I really do like the framework.  As I have gotten more used to developing in the MVC architecture I realize that Cake provided a great learning experience for me and worked as a great stepping stone in creating an MVC application.  I think that Yii will be the next step forward for my project, and future posts in this blog will hilight my experiences using Yii.

Are you currently using CakePHP?  Did you end up switching to Yii, or another framework?  I'd love to hear your thoughts!