I seem to be writing a lot of “first impressions” posts lately, and I’ve definitely been using several new tools recently. Its fun and strange at the same time; I am doing a lot of learning, which is fun and horizon expanding, but I am also coding less as a result, and because my knowledge of these new tools is necessarily superficial as a newbie, I know that the code I am writing is probably not very good. This week, I started gathering requirements on a project that I initially expected to be coding in JRuby on Rails, only to find out that eventually, I would be handing off the application to a development group that only wanted to support PHP. OK, I thought, I’ll just use CakePHP, which is a Rails clone and one of the best PHP MVC frameworks offered. I know PHP, and I know Rails, so the transition should be smooth. and overall, it has been so far.
This is now the third major framework I have learned and used in just over a year, having done some work in Django, then adopting Rails, and now turning to CakePHP, and as I have moved from one to the other, learning the core MVC framework has typically been the easy part. I have been using MVC frameworks for some years now, and I feel comfortable with Rails’ conventions, which are basically just best practices that a lot of Web developers already use anyway–Rails just takes advantage of those conventions to automatically tie the layers together. The hard part–or I should say, the part that takes slightly more time–when moving from one framework to the other, is figuring out how to fit it into my particular set of development philosophies and techniques. For example, what tools exist in the framework that support unit and functional tests, AJAX effects and RESTful development? What plugins are available to support the functionality I typically use in the applications I develop?
Because Rails really started and continues to drive the latest generation of Web frameworks, it has the best testing, AJAX and RESTful Web design integration. It also has the most plugins with the most maturity. CakePHP and Django are necessarily still more focussed on perfecting the core MVC framework and less actively working on the next tier of integrating support for these techniques. Not that you can’t do these things in CakePHP and Django, in fact, with a framework in place, these things tend to be much easier to accomplish than they might be in a system you’ve built from scratch. Yet, because these techniques aren’t deeply integrated with the core MVC framework, you have to figure out how to do it yourself, in a way that makes sense for that framework, which takes time to figure out when you are new to the framework itself.
For example, when I do a search to get a sense of the best way to approach RESTful development in CakePHP, I tend to find tutorials on consuming RESTful services within CakePHP, or how to create RESTful Web Services (that is, responding in XML for programmatic processing) within CakePHP, but not so much about how best to design a RESTful public facing application in the framework. Again Rails has taken the lead here, and even though that community is still very much figuring out best practices for RESTful development, they have come a long way and through their example, they are again defining the best practices and shaping the discussion of how this should be done.
Overall, I have to say that I am impressed with CakePHP in a number of ways. I think a mistake that developers often make when “porting” a proven solution from one language to another is that they try to implement the solution in exactly the same way instead of recognizing both the strengths and weaknesses of the environment they are porting to, as well as its unique idioms, and recreating the application in a way that makes sense for that environment. Although RoR’s influence on CakePHP is obvious throughout, you can also find many examples where the Cake developers have adjusted the Rails approach in a way that makes sense for PHP and those who develop in it. From my perspective, CakePHP has remained true to both Rails and PHP.
Now there are RoR developers out there who say that PHP could never possibly hope to have a framework like Rails, and that of course, is just plain silly. As I say, an attempt to directly port RoR may not work, but CakePHP has proven that indeed you can have a Rails like framework in PHP. Those that claim that PHP is “too ugly” to support a framework like Rails are probably inexperienced developers who have not yet learned another language besides Ruby. They are probably just a vocal minority of the Ruby/RoR developers out there, but they have succeeded in branding the Ruby/RoR community as myopic and immature.
I agree that Ruby is a much more elegant language than PHP, and I’m sure that certain characteristics of Ruby allowed DHH to think in certain ways that led to RoR’s elegant design. Our tools certainly influence how we think about systems. But as CakePHP has shown, this doesn’t mean that you can’t replicate RoR’s conventions in other languages. So what if underneath, CakePHP is not as elegantly coded as RoR? It will have other advantages, such as most likely performing better. I think if you are really going to try to compare the two frameworks (which I don’t think is very meaningful in most cases anyway, you’re going to use what makes sense for your background and environment), I think the biggest advantage Rails has is its maturity because it has existed longer, whereas CakePHP obviously has Rails beat in simplicity of deployment. Either of these factors might influence an adoption decision.
Although, I was a little put off by the fact that the CakePHP documentation (specifically, the manual) doesn’t explicitly acknowledge the influence of RoR very often. Aside from appearing not to give credit where it is due, I personally would have found it helpful for them to say things like, “this is exactly how such-and-such is done in Rails”, or “this is how such-and-such differs from Rails” so I would know when I could skim sections I could easily figure out on my own and when I should pay closer attention. Maybe this would clutter the documentation, and maybe they weren’t expecting many people to come to CakePHP from an RoR background, but then again, is there anyone out there who doesn’t have some sense of how Rails works at this point? I suspect others might benefit from such explicitness.