Looking through the list of PHP frameworks can be daunting. Zend Framework. Laravel. Cake. Symfony. Picking one and learning it can seem like the most important design decision you’ll make. And yet, picking a framework is actually one of the least important decisions you face.
In fact, you don’t need a framework at all.
A brief history of frameworks
Back when PHP began, everybody and their brother was writing their own custom code for everything. A few people, realizing that this wasn’t effective, created their own proprietary frameworks that they could use for their own internal company projects. These frameworks looked something more like common ways of doing things, rather than anything formally organized.
As the PHP object model developed (and especially with the launch of PHP 5), framework development really began in earnest. Now everybody was writing their own framework, and a few frameworks because really popular (like Zend, Cake, Symfony, to name a few). Pretty soon there were roughly 2 and a third frameworks for every PHP developer out there, and we all preached a common message of “you need to adopt one of the common, established frameworks! Don’t do it alone!”
This message makes a lot of sense. Developing your own framework limits your options and opens you up to security problems and architectural challenges that most of the other frameworks are already solving. Not to mention the fact that most of the time, adding a collective set of brains together results in a better product. And I’ll be the first to admit I don’t want to compete with Matthew Weier O’Phinney in a battle of intellect; he’s smarter than I am.
And so, PHP developers started adopting major frameworks for new projects. And all was fine.
The PSR and Composer era
Frameworks offer many things, including a bunch of components that simplify common tasks (like logging, database connections, caching, serving and routing requests, etc.) A good framework comes with all of these built in, plus possibly a few more.
And for a long time, every framework included a ton of libraries built in, because it was difficult if not impossible to manage libraries in PHP. But two things have changed that.
The first is the PSR standards. PSR stands for PHP Standard Recommendation. The PSRs are created and published by the PHP-FIG (Framework Interoperability Group), a group of framework and package vendors that have come together to provide common standards of interoperability between their products.
This has made possible the creation of Composer, which is a package manager for PHP libraries. Composer allows developers to pick and choose compatible packages, create a manifest for their project, and load those packages on demand.
Now, instead of having a bunch of siloed frameworks that can’t work together, there are (supposedly) standards for how they can integrate. An added bonus is that library creators can follow the same standards, making their libraries compatible with all the frameworks that implement the PSR standards.
This means you don’t need a framework
The PHP world has now come full circle. It’s possible to mix and match packages, which would have been incompatible, to create a set of components for use in your own project. New libraries like Aura allow for the integration of framework-like components without the heavy framework. Aura, for example, offers routing, database handling, a dependency inversion container, and more as separate packages (or you can get it as one large framework, if you so choose).
This offer the experienced PHP developer a tremendous advantage over the past. Now, incompatible packages are suddenly compatible together and building an application becomes far simpler. Instead of having a tremendous learning curve on one of the old-style frameworks, it’s possible to take the packages you want and leave the packages you don’t.
Some words of warning
I’ve been developing in PHP since 2003. My experience lets me pick packages and create basic behaviors like front controllers and the like. Building these kinds of components, and doing it well, is a function of experience.
I advise new developers to learn the frameworks that exist, rather than advising them to create their own. A new developer will do far better if they learn from established experts. The only thing is that you shouldn’t agonize over the framework you’re going to pick. The one you like the most will suffice for now.
This also doesn’t mean you shouldn’t learn the language; never settle for learning a framework but not the language underneath. With some experience, you’ll be able to pick from the bevy of available tools, even if they’re not frameworks or they are components of frameworks.
Frustrated with your company’s development practices?
You don't have to be!
No matter what the issues are, they can be fixed. You can begin to shed light on these issues with my handy checklist.
Plus, I'll help you with strategies to approach the issues at the organization level and "punch above your weight."