Why Use PHP Framework ???

Are you Paying Lots of money to developer for using Wordpress with lots of plugging ? Being a PHP web application developer for several years now, I've had my share of MVCs and frameworks. At first I thought they were the best thing since sliced bread; everything seemed to be very easy to implement.

Okay, frameworks are cool if I'm creating a simple company profile website; I can just whip some code in one night and they're usually ready by the morning, and the amount of good coding practice and design patterns I've learned from them is very valuable. charging big money for Ready-made code is not Ethical .

But really, for a complex web application like an all-in-one web based school management system, frameworks usually get in the way of my business process like in the example above.

Looking through the list of PHP frameworks can be Difficult. 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.

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 2004. 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.

For Developers

I've got a challenge for you. The next time you start a new project, try not using a PHP framework.

Now, this isn't an anti-framework screed. Neither is it a promotion of not invented here thinking. After all, we're going to be using some packages written by several framework developers in this tutorial. I've got nothing but great respect for the innovation going on in that space.

This isn't about them. This is about you. It's about giving yourself the opportunity to grow as a developer.

Perhaps the biggest benefit you'll find working without a framework is the wealth of knowledge about what's going on under the hood. You get to see exactly what's happening without relying on the framework's magic to take care of things for you in a way that you can't debug and don't really understand.