Don't make them compete, make them work together!
Over the past weeks while I was trying to find a new job, I've made an interesting observation. Well, I made the observation before already, but my interviews over the past weeks have confirmed it: Most developers seem to limit themselves to a single framework. Be it Zend Framework (more popular than I even thought), be it symfony, there's even still a huge amount of custom "we built it because we have our own needs" frameworks out there, even in companies doing things similar to any other web development company out there.
Most people know me for my strong tie with the symfony project. Granted, when I was first looking into frameworks, symfony was by far the best and most mature PHP5 MVC framework out there. And at this point in time, I still think symfony is the best solution for the types of websites and web applications I usually create. However, that does not mean that I limit myself to writing everything with symfony.
Looking for functionalityWhen I want to implement a certain functionality, my first stop is usually symfony itself. If symfony does not support it, I go to the symfony plugins repository. If even that does not have it, then I look around at other frameworks. Zend Framework is a first stop usually, but also
ezComponents and
Solar are good places to start looking, is my experience. After Googling for individual libraries, my last option is to write something myself.
The lazy developerA good developer is a lazy developer. If someone else has already built a specific functionality, why the hell would you start from scratch? If something has been well-programmed, it will be easy to extend and overload specific features that you'll want to use in a slightly different way. And this is exactly the reason why one should not just focus on a single framework. Of course you can always add new stuff yourself, but if there is already a good library out there that does it, why not use that instead. If you look at the current popular PHP5 frameworks (Zend Framework, symfony, Solar, ezComponents just to name a few) then you seriously cover most probably 99% of all common use cases for web applications.
Focus on the importantInstead of writing a new custom library for your project, you should be lazy and use an already existing component, even if it's of a framework you're not using yet in your current project. That will allow you to focus on those parts of the project that can not exist in already written components: Custom business logic, your project's database schema and its related functionality, the views and templates of your project, the usability and accessibility of your application. These are the things that are really important for your project at any time. Re-using existing code will allow you to make deadlines more easy.
SpecializationNow, I am not saying that specializing is a bad thing. Especially for small development shops and for supportive departments of companies whose core business is not web development, it is probably best to specialize in a single framework. As you've done your research, you've probably found a framework that covers a huge part of your use cases and your developers will pick up easily and deploy quickly. Specialization is good in those situations, but don't stick inside that box. Even though you focus on this one framework, be aware of what is out there. Every time you're thinking "that sounds like something for which a library already exists", make a round through at least the most common frameworks and google. See if there's something usable out there already.
Use the right tool...Too often have I seen companies focussing on a single tool just because "it's the standard for our company". You should have a wider look. You should use the right tool for the job. Everybody knows (well, should know!) this by now. It should be your mantra. So that also means that you may need to think out of the box and use a tool that is not your standard tool for specific stuff. And with that, I'll leave you to look not just at your own favorite library but at other tools as well.
July 6, 2009 - tags: symfony, zend framework, solar, ezcomponents, php, frameworks
Thomas Koch: I made a list of those components from eZ Components which I consider great, good, bad or ugly. It would be fine to get these kind of list for other libraries too:
http://www.koch.ro/blog/index.php?/archives/125-eZ-Components-The-Good-The-Bad-and-the-Ugly.html
In general why not skip all these "Compare framework X to Y" posts and rather compare on the components level?
Alexandr: I think that CMS as framework is separate theme, but it need to be place where developer will take look. Because cms like Drupal and Joomla in many cases are good start point for many project. And this project provide good documented API for plugins.

leon: Nice article. I think there are the same amount of custom made CMS'es as there are webdeveloping companies.
Most of these CMS'es are very simple and not very usable but the are exactly the system they need. *not*
Typical the "not invented here syndrome"
Sven: Who's gonna develop the framworks if everyone's lazy? Are you really arguing for a monoculture? I agree that the NIH syndrome can be damaging, yet it's not always a good idea to bloat up your app by attaching yourself to various frameworks. There's also the security aspect, which I think is rather important.
left: Sven: As I mentioned above, the currently popular open source frameworks cover 99% of common web application use cases. I'm not saying there's no reason to do any custom work anymore, I'm just saying that in those 99%, you should be able to use a component from one of the existing frameworks. And when available, you *should* use it, because there is no reason not to.
Obviously any sane developer will take into account many things such as security and bloat. But as long as you're adding components because you need them in your project, not because you "might need them later", there will be no bloat. And those open source frameworks are mostly quite secure already.