You don’t need a framework

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.

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP

Richard wrote at 1/8/2014 2:45 pm:

I really think that people who don’t use frameworks has problem with those who do.

I like frameworks and I know other programmers that use them too and I don’t see them criticizing those who doesn’t prefer to use them, if you are not one of them maybe a different title would be better…

As anything in life, frameworks has advantages and disadvantages and its up to everyone get the best of these tools.

If I use a framework and let it to do all the work without trying to understand what happen backstage, then I am the problem, not the framework.

But If I use a framework, read the code, learn from it, etc. would be different, don’t you think?

It is true that sometimes you don’t need all the components, but in case you need most of them, why butter to create my own project and get almost most of the component of a framework? to say what? Look at me, I am a great developer that doesn’t use frameworks?

In some projects I don’t use frameworks but in others I do, but I won’t say “You need frameworks” or “You don’t need frameworks”…

the php expert wrote at 1/8/2014 2:58 pm:

i’ve seen pear and pyrus rise and fall, same with alot of other php stuff over the years. sorry for destroying hope and good feelings, but composer is just a modern pear clone. it has its use cases, but won’t capture the whole php community and frameworks only share their close coupled packages on it since those are build with a service injector or something alike in mind and psr haven’t set a recommendation about that nor about other cross cutting concerns.

coming to psr itself: that organisation itself is a bad joke. a few outdated cms and framework vendors try to dictate how things are organised and start with the least important things first. in addition they prefer backward compatibility with legacy code over modern and good standards (e.g. psr0 and that psr4 doesn’t replace the former).

i’m writing php since 2001 and all i can say is: focus on business logic an testing, not code and libraries.

just my 2 cent on this :]

Don Gilbert (@dilbert4life) wrote at 1/8/2014 3:10 pm:

Good article Brandon. One bit of correction though, PSR doesn’t stand for “PHP Specification Request”, it’s actually “PHP Standard Recommendation”.

Brandon Savage (@brandonsavage) wrote at 1/8/2014 3:11 pm:

There was a bit of debate about that on Twitter. I actually removed the one you say for the one I used.

Don Gilbert (@dilbert4life) wrote at 1/8/2014 3:19 pm:

That’s ok, none of those who responded to you are PHP-FIG members. I consulted with other members (myself included) and concluded that yes, it does stand for “PHP Standard Recommendation”.

Rafael Dohms was the correct one in this thread – https://twitter.com/brandonsavage/status/420973168379977728

Phil Sturgeon (@philsturgeon) wrote at 1/8/2014 3:22 pm:

Hey Brandon,

I understand what you are saying but I prefer to look at things in a different way. It’s not about wether or not you need a framework, it’s about changing your definition of what a framework is – because the frameworks themselves have changed theirs.

Lots of PHP experts (not this absolute joker in your comments) have been calling for packages to be more of a priority than frameworks, for the obvious selection of reasons that you have highlighted. Happily we are there, and the few PSR’s we’ve managed to get out so far are (I hope) helping out.

Its not “frameworks v components”, where frameworks are this old outdated idea and components are the new hotness. Modern frameworks (SF2, ZF2, Silex, Laravel, Aura, FuelPHP, etc) are all components. They are components that can be used by themselves or together. They ARE the MicroMVC manifesto.

But all of those mentioned “component vendors” also have sample applications, which tie those packages it into what we know “classically” as a framework. These applications are completely optional and you could of course bootstrap your own, to use the same packages in any way you like.

Great! :)

Components are great, and bootstrapping your own selection of components are great, but that can be rough for beginners so let somebody else bootstrap the components together for you.

That is a framework.

Brandon Savage (@brandonsavage) wrote at 1/8/2014 3:29 pm:

I updated the post. Thanks for the tip!

Hari KT (@harikt) wrote at 1/8/2014 8:59 pm:

Hi Phil,
I have been playing with SF2, ZF2, Aura and also looking at FuelPHP, Respect etc. What I dislike in the some of the framework / component system is when you want the whole system to be forked and tested when you feel there exists a bug.

It should be easy to fork a single library and push it back.
When you are saying they are optional I will urge you to make another bridge for glue. Not in the same place.

Eg : If you need to use Aura.Sql inside silex, either the framework say silex can place the bridge or there needs another provider like https://github.com/jtreminio/Aura.Sql-Service-Provider

Else in-order to test a single library you are forcing people to either fork the whole ecosystem and figuring out what went wrong when you promote it as component library.

I respect and do use the components and know maintaining is a bit hard. But I could not resist my self to write my inner feeling.

Frameworks are great!
Components are awesome and everyone should build your framework with in-dependent components, else you will end up in the same monolithic framework which could not replace the components ;)

cebe (@cebe_cc) wrote at 1/9/2014 1:53 am:

How is picking or learning a framework a “design decision”?

Charlie Jolly (@K_International) wrote at 1/9/2014 11:22 am:

Despite the cynicism of some, I’m happy to see convergence on this and greater interoperability. Composer gives me more control than Pear.

Brandon Savage (@brandonsavage) wrote at 1/9/2014 12:12 pm:

Once you’ve picked it, you have to implement it.

Roy wrote at 1/9/2014 3:54 pm:

I don’t have much choice at work but for my hobby projects I actively avoid using frameworks because in my opinion they take all the fun out of developing websites. There’s no better way to properly learn how to build a website than having to tackle all of the issues yourself head on rather than hiding behind pre-built code. Not to mention it means I know my code inside out and it does exactly everything I want and nothing I don’t want resulting in zero overhead and a faster website overall.

Frameworks are useful for professional development but I see too many web developers who say they can build websites but really all they know how to do is use XYZ framework. That’s not the fault of the frameworks of course, but it makes it incredibly awkward when they don’t really know how the site they’re building even works, it’s just sort of assumed to be a magic black box that takes X input and gives Y output.

Web development is very much about fads and shinies. Developers will evangelize a certain technology for a while then drop that and move on to the next, newer shiny. If you’re just learning the latest fads and hot topics then you’ll be left behind when it gets stale.

It’s important that developers actually understand how everything works behind the scenes so I believe it’s just as important that developers are able to create websites without frameworks, or with their own custom framework, as it is knowing CodeIgniter or Laravel or whatever is currently trending.

Christof wrote at 1/24/2014 3:11 am:

Some reasons why I think all developers and specifically Development companies SHOULD be using frameworks.

1. Standardization, it ridiculous to think that you will model a system from the ground up using your own idea of what good architecture is, then expect future developers to learn and maintain your code.

2. RAD, why reinvent the wheel, when these MVC frameworks are already doing the heavy lifting for you in terms of all the MVC benefits.

3. Community, when you’ve adopted a popular framework you automatically have access to that framework’s community and resources – you are not alone.

Mark (@mogosselin) wrote at 3/20/2014 9:37 pm:

@Roy : You said: “I actively avoid using frameworks because in my opinion they take all the fun out of developing websites.”

It’s true that it can be fun to write all of your code, but there’s a lot of stuff that the “good” frameworks will do well and you won’t. Except maybe if you have the luxury to work on your own framework for a couple of years. If you have to build a big enterprise website, you can’t just tell your boss that you’re not going to use a framework because it’s not fun. And, anyway, the enterprise will probably have their own framework of choice anyway.

And you said:
“There’s no better way to properly learn how to build a website than having to tackle all of the issues yourself head on rather than hiding behind pre-built code.”

And I agree with that! Beginners have to understand the code and how requests are “sent” to PHP (the HTTP protocol and PHP basics) before they use a framework. But I would not let a beginner write a full application and put it in production without a using a framework. If it’s something big, it won’t be maintainable, I guarantee it ;)

Anyway, I really like the PHP-FIG work to define standards. It should get the language easier to “manage” (if that makes sense). As long as it doesn’t get as bloated as all the different Java specifications.

Copyright © 2023 by Brandon Savage. All rights reserved.