The "Framework" is Dead, Long live the Framework

Posted: 2014-01-13
Category: PHP

There have been a few posts over the last few months saying that the age of the framework is dead, and that Composer is the true savior, and other similar messages. This is half-true, but lots of people have been using the word "framework" differently over the years and I wanted to really work out a good definition of what a "framework" was in relation to PHP development, and in relation to these discussions.

I had my own idea of what a framework really meant, but after reading an article by Brandon Savage, named You don't need a framework I felt really confused.

If you read through that thread I was certainly wrong about a few bits and didn't immediately notice, but as I said I was genuinely confused. This conversation helped me get my own definition clear in my head, and now I think it is a good one.

Frameworks dictate architecture, handle your bootstrapping and essentially give you a set of lines to color inside.

Components, libraries and packages are all interchangeable-ish words that can add functionality to a framework, but really are not A) part of the framework, or B) a framework themselves.

Back in Time

I got on the PHP framework train with CodeIgniter back in 2006. Before that I was munging together abominations with phpBB, Postnuke and all sorts of other systems that did not make for clean living as a programmer.

CodeIgniter came around and it had two clear goals:

  • Provide a clean "OOP" architecture for your applications
  • Avoid systems like PEAR, bundling lots of useful components with it

CakePHP and the other similar systems were all doing the same around the same time, some before and some shortly after.

That was the beginning of 8 years of thousands of us using the term "framework" incorrectly.

CodeIgniter is a framework. CodeIgniter had a bunch of libraries including file uploads and a query builder. File uploads and the query builder were not part of the framework, they were simply bundled with it because dependency management at the time was shitty. If it wasn't bundled then it would need to be PEAR or some other ZIP download, which would be awful.

Kohana is a framework. It added an ORM. People said Kohana was a better framework because it had an ORM. Wrong, it might have been a better framework and it just so happened to have an ORM bundled with it, which made it a nice ZIP file to use.

Modern Frameworks

Things like Zend Framework and SF2 are clearly a bunch of components, but call themselves frameworks.

Basically, a framework consists of:
A toolbox - a set of prefabricated, rapidly integratable software components. This means that you will have to write less code, with less risk of error. This also means greater productivity and the ability to devote more time to doing those things which provide greater added value, such as managing guiding principles, side effects, etc.
A methodology – an "assembly diagram" for applications. A structured approach may seem constraining at first. But in reality it allows developers to work both efficiently and effectively on the most complex aspects of a task, and the use of Best Practices guarantees the stability, maintainability and upgradeability of the applications you develop.


That seems to me to be the old definition of a PHP framework, back in the days where we used to bundle all of our shit together in a ZIP file. That was SF1, so is it possible for SF2 they just kept the name because it was easier?


The name FuelPHP applies to a component vendor AND a framework.

  • fuelphp - A collection of components.
  • fuelphp/fuelphp - This is a sample application which defines the architecture of your code. This is "correctly" described called a framework.
  • fuelphp/foundation - This is required by the framework to run, but is not a framework by itself, just an important component.


Laravel is a framework, but not a component vendor. It uses a component vendor called Illuminate.

  • illuminate - A collection of components. I'd call this the "Component Vendor".
  • laravel/laravel - This is a "sample application", which would be better named as "framework"
  • laravel/framework - Unfortunately named. This should be something other than "framework", like "foundation" or "kernel".

I mentioned that to Taylor, and he agreed but wasn't too fussed. It's not a complaint, I just wanted to point out how it fits in with this definition. IM NOT ATTACKING YOU LARAVEL PEOPLE. ;-)


The name Aura is a component vendor AND a framework. More specifically, one of the Aura components is called "Aura Framework".

Again, Aura points out the different between the two things, even if it does happen to share the same name.

Semantic Wankery?

Maybe. I didn't start this conversation to argue the meaning of vague terms, I did however want to know if I agreed or disagreed with Brandon, and it turns out the answer is… both.

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

Absolutely. Sure Reinventing the Wheel can be a great move if you are interested in learning how things are done, but putting your home-made framework into production can be scary if you're a junior dev. You're potentially opening yourself up to all sorts of security issues that just don't need to be toyed with.

And Brandon is of course right that dependency managers have given us the return of components which can be used outside of frameworks, as Composer (PEAR on crack, but… smart too) helped developers distribute code outside of just lumping it into a framework.

But where we start to disagree a bit is right here:

New libraries like Aura allow for the integration of framework-like components without the heavy framework.

With Composer becoming considerably more widespread, ALL major frameworks short of CodeIgniter (trollololol) have moved their components out into separate packages, meaning this whole "heavy framework" is: "the application architecture" + "whatever components your application structure would like".

So, the application architecture IS the framework. The rest of it is components.

Brandon here is suggesting that we don't need the "framework" anymore because we can just use components and make our own application layer. But... the application layer is the framework.

So going by the "correct" definition of a PHP framework, Brandon is actually suggesting that we code our own frameworks - something that he at the start of the article advised against:

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.

See why the article caused some confusion?

Framework GOOD or Framework BAD?

So, old-style "heavy frameworks" no longer exist. GREAT. In retrospect, those things fucking sucked.

These days all you need to do is grab a bunch of components that work together (relying on each other, or working despite each other), bootstrap them altogether, set up some routing, hook up a config system, lay your controllers out, handle session configuration and connect to your database.

You can do that completely with random pick-and-mixed Composer components. But when you've done writing that application layer... guess what you've done?

You've just written a framework.

As I said above, writing your own can be a good learning experience for beginners, but it's terrible for getting things into production. It's terrible for hitting deadlines, terrible for hack projects, terrible for prototypes, terrible for a lot of things.

If you know what you're doing it can be excellent. You can custom build a real pride and joy, it might be faster, and it will probably work just how you want it to. Yaaaaay.

But, it's really not as easy as people keep saying.

Composer is not also some magic bullet, and lots of these components are more difficult to set up than people say. Brandon gave the FIG some props which was kind of him, and I have seen this sort of idea before, but unless you want a logger these shared interfaces just have not had a chance to be completed yet.

Cache and HTTP Messages are on the cards, but the former has been going for two years and the latter is going in for an entrance vote probably tomorrow, meaning we're going to be at least 3 months away from completion, probably 6.

So... what is the harm in letting a framework do this for you?

Frameworks are bad for Beginners

Not something that Brandon said, but a mentality I've seen around a lot.

(Yeah I'm pasting in my own quotes. Deal with it.)

This came from people saying things like:

Newbies should stay away from frameworks! Ever seen a bricklayer easily become an engineer. First he should study, if not want to follow good practices will never have a good credential to do the job.

This was a conversation on the Stop Using Facades article comments, and I had another the day before on Reddit:

And I'm not really sure the user with no discernible understanding of programming is the right demographic to be targeting with a framework in the first place. I believe firmly that no user should touch a framework before she has a firm grasp on a language. Anything else is asking for trouble.

These are not just comments from Reddit and a blog, but something I have heard a lot recently.

I feel like this is a very idealistic view of development. I know a shitload of people who do not want to become a top-level programmer, who couldn't care less. One of my close friends is a top-level DJ in the UK, playing in London at a bunch of fancy clubs. He is also a businessman, with a startup that is about to launch. He has his interests and he is great at what he does.

He does however have literally no interest in becoming a world-class programmer. He barely even wants to code, but he can thanks to frameworks like Laravel.

Using frameworks he can get shit done. He's written an awful lot of extremely good applications - that work - and that has made him some money. Ship ship ship.

This was mostly done with CodeIgniter back in the day, then he hoped over to Laravel last year.

Does he know what separation of concerns means? Ha.

Is his code SOLID? Nope.

Is the Laravel application he made unit-testable? Fuck no.

Is it going to function well enough to get him to his next round of funding? Absolutely.

Is he going to have to throw the whole thing away? Not at all.

Frameworks are great for beginners, who literally could not possibly smash together a series of random components if they wanted to. Regardless of the efforts of the FIG and PHP The Right Way combines, now or even what we've done in 3 years time, frameworks are not going to go away.

They are however moving away from being heavy, bloated omnishamble ZIP files that require all of the rest of it to work, and they are improving their interoperability slowly. So that's nice.

Polarization is misleading

Generally speaking, it's impossible to be so polar about whether a "framework" is "good" or "bad". You can't say wether you need one or not, because there are a lot of factors.

  1. Literally every single PHP framework out there has a different definition of what a framework is
  2. What "framework" means is to you is different than what it means to me
  3. I only worked out a decent definition for what a framework was the other day
  4. Even if we all had the same definition, saying they are good or bad for beginners is insane. Everyone learns in a different way. Seeing, doing, building, all are different
  5. If you ask me how "heavy" a framework is I have no idea what you mean
  6. Composer is a great tool, but not all packages work together as well as a lot of people seem to think. Yet...
  7. Even the most advanced developers sometimes just want to smash out a website in a night, and using a framework will save you a lot of time bullshitting around. Not every project is a flagship enterprise product

So... let's ship stuff?

No, thats a shitty bail-out ending.

I think Brandon had a great point. We are moving away from the age of requiring these monolithic ZIP files, and we have some great tools that let us distribute these framework agnostic packages. We have a group of people working really fucking hard on making standards that help these packages work together better, so by the looks of things everything is on the up-and-up.

What is popularly called a framework will change over time to reflect changes in the ecosystem - right or wrong - and that's cool. We just shouldn't be too quick to throw the baby out with the bathwater when a nice shiny thing comes out, and notice the changes to the tools that we used to hate as they notice the changes and follow along.

Old-frameworks are old. Modern frameworks are lovely. You should probably use one. But maybe you don't need to, and that's ok too.




Loved the article, learnt the true meaning of wether and was most surprised.

Keep up the good work.



Preface; Long time PHP guy and my kids went to bed grumpy tonight, so yeah.

At the end of the day your clients don't care. If a client approaches you and asks for a website/app and you reply with something like. "I'm going to use open source technologies to be able to work together in a clean, separation of concerns way and leverage a CMS called (insert catchy phrases here) so you can update your profile photo twice a year." The client will give you a blank stare because they don't give a sh... They want their website/app up and looking pretty, at least this is what I've seen 99% of the time. A developers job is to deal with the rest. Pick whatever makes YOUR LIFE easier, faster, better. Think ahead - will this likely mean multiple languages using internationalization?

Frankly all this PHP framework stuff is so tiring to keep hearing about., It's like that taste when you wake up in the morning after eating a bag of Ruffles with Onion dip and drinking some pints the night before.....

Composer should have channels for specific project based code. - Laravel specific plugin (requires Laravel) then it goes in the Laravel whatever chan. - Having all these myname-with-framework convension isn't very fun and will become a pain overtime

Then in your composers json file you can specify - the main channel - for all your (main project CMS/framework) dependancies. You can still use the MASTER channel for actual independent components that don't need other stuff to work

New languages are starting to grab developers attention and that's OK. PHP will always be the backbone of the web, I mean it powers the large majority of it - in WordPress... But it's still progressing too slowly IMO.

I mean if we want to all progress together as a community why don't we get together and focus on The site (even though updated with a newish look) has documentation comments from like 10 years AGO.. PHP has TONS of legacy stuff on the web that should have been deleted long, long ago.

Lets get the HUB in good shape first then worry about all these spokes. It feels like needs some modern love. Granted I'm sure the site is a beast but we should get some folks together and start sketching out what the community wants to be. It's not as bad as the Oracle Java site (lol) but it's feeling like it's not far off.

It's less about the details of PHP and now more about making it work with other tech stacks today anyways. Companies/developers are no longer one trick ponies. We use what makes sense.



I was given a definition for fw vs lib that has stuck well with me: With a library, your code uses it; In a framework, its code uses yours. I automatically make those assumptions when glossing over options, right or wrong

Will Morgan


I used to be on the "don't learn a framework until you know the language" bandwagon, but that's a pretty open ended philosophy. I mean, when can you say that you truly know a programming language?

Writing bootstrap code is boring and unproductive. As a beginner, using a framework and getting shit done is fun and productive. Over time you'll realise your approach sucks and you'll want to improve - if you're productive and successful, you'll need other developers and you will adapt as a matter of necessity... or you will die.

Any framework worth its salt also serves a decent example of how to code correctly - what is so wrong about encouraging beginners to start that way?

As a sidenote, I'm curious to know who this DJ friend of yours is.

Carrie Kendall


This is a really great article that actually approaches from the (rare) non-elitist side. Definitely some interesting points.

Andrey Andreev


Funny, I was defending the "beginners shouldn't use frameworks" side on IRC just a couple of days ago.

While it is true that it's a very broad statement, it also has a context - learning.

Of course if you're not interested in learning programming or if you need to just get shit delivered, I don't see a better option than using a framework, CMS or some other ready-to-go thing. After all, released code always earns more money than your development code that aims for perfection.

But for the purposes of learning, go do some raw PHP first. Learning everything starts with the basics and using a calculator in beginners school math class won't help you learn math, instead - you'll end up being unable to do calculations on your own. Or in PHP's world - not knowing how to code outside of a framework. That's the reason there are so many people asking "how do do X in framework Y", where X is a native PHP feature.

I like to think it's somehow related to that phenomenon where people are aliasing the thing with it's most popular brand. You won't even believe how many people in IT still call Linux "another kind of Windows", or because I'm a big time IRC fan - how many people still call IRC "the mIRC". Very annoying, even though you do understand how it ended up that way.

On the other stuff, I won't argue what a framework is and what not, but I awhile ago I did see a table comparing different frameworks and it had a "type" column. It said "monolithic" for CodeIgniter and all the other frameworks that are tightly coupled with libraries that they ship. I kind of like that term better than "old frameworks". :)



I really don't agree with some of the comments made in your post regarding doing it yourself. You're really giving developers no credit with phrases like, "As I said above, writing your own can be a good learning experience for beginners, but it's terrible for getting things into production. It's terrible for hitting deadlines, terrible for hack projects, terrible for prototypes, terrible for a lot of things.".

Frankly, I find it insulting. You seem to be suggesting developers are incapable of writing software outside having their hands held by a framework. However did we survive and develop websites before frameworks? Not to mention the numerous software packages and websites out there that exist without frameworks, or roll their own.

How did phpBB and vBulletin dominate PHP forum software without using a framework? How do Facebook and Wikipedia survive without being powered by Laravel or Phalcon? I guess they must be terrible because of it though.

Honestly it comes off as self-indulgent developer wankery when you tell people their code is going to be terrible unless they do it XYZ way.



Roy: Sadly I feel like you completely ignored 97% of the article, and just really focused on that one quote for your entire reply and opinion of the article. That is a little unfortunate.

If we're going to focus on that those two sentences, let me reword it - to keep the same intended meaning, but in a way you might prefer:

"Writing your own application layer - as Brandon mentioned - can be challenging for beginners, and that is a challenge many don't need. In other scenarios (such as scenarios where pure blazing urgency and speed of development are primary concerns) taking the time to plan and build out your own application architecture layer (your own "framework") is probably not something most developers are interested in. In my experience, nobody does this at hack projects, nobody does this for prototypes, but they do do this for production."

There was no intention for suggesting people couldn't cope. I'm not sure what gave that off, but I'm sorry for the confusion.

Following the definition in this article however, phpBB and vBulliten (both of which I am incredibly familiar with) were providing application architecture layer, with an application pre-bundled in. By this definition they were frameworks, just not even vaguely MVC frameworks. :)

But then you said: "How do Facebook and Wikipedia survive without being powered by Laravel or Phalcon? I guess they must be terrible because of it though."

When the hell did I say something not using a framework was terrible? I am sorry if my writing was so inaccurate that you got this idea from me, but everybody else has read these same words without jumping to that conclusion so I have to assume its not just me.



Phil there is no need to be so disingenuous with your responses, we directly emailed each other after my first comment but you chose to gloss over the points I made there and repeat them here publically which is poor form.

You told me yourself in an email, to quote, "Somebody else read the article as 'fuck frameworks, you can use components for everything and you don't need those old crappy things anymore.'"

So in your own words I am not the only one that is apparently misunderstanding you. Perhaps you should consider that your point has not been clearly made by your post.



Roy: I was waiting for you to reply to link you back to the updated comment. And I didn't gloss over shit.

Yeah the two of you have misunderstood the article. One thinks I'm pro framework, the other thinks im anti-framework. Is it possible that its a balanced article, and when you see one section you read way too much into it, then didn't notice the other side? :)



Of course it is, Phil. I am not trying to pick a fight with you here, I'm addressing some issues I had with your post in the most diplomatic way possible but perhaps I failed in that regard. I'd like to end this conversation on a good note so I'd just like to say I've been following your blog for a while now and am a fan of what you do, even if I do not agree or I misunderstand some of your points at times. Please keep up what you are doing, I enjoy reading your posts.

Tomislav Kostantinov


You can't make a bicycle from two cycles without a frame. That's framework. :)

Jeff Walters


What you think about the framework I use is none of my business. It should be more about getting the job done right, than the tools used to solve the problem. Another great post Phil.

Rasmus Schultz


Thanks, Phil - great post!

I think the root of the problem, is that people say "framework" without actually qualifying it - framework for what? Often framework means "framework for everything", which is where the chain falls off, in my opinion, and since I recently had the discussion in a conversation with another developer, I felt the need to to follow up with a post of my own:

Tony Marston


I agree with Bibby who said: “With a library, your code uses it; in a framework, its code uses yours.”

I would expand this by saying that if you have to write the wrappers for framework code, then it’s not a framework, it’s a library. A proper framework should generate the wrappers, which do all the basic and repetitive stuff, into which you can insert your own code to do the clever stuff.

I would also define a framework as having runnable components for the following: - Run the framework to generate application components. - Run the framework to access those application components.

Too many “frameworks” out there force you to write volumes of code to do the basic, repetitive stuff before you can even start on the clever stuff. How is that an aid to Rapid Application Development?

It is totally untrue that all frameworks are equal and that they are interchangeable because they help you achieve the same thing. The big difference is how quickly they help you achieve your objective, and how much code you have to write yourself.

Another big difference that a great number of developers fail to realise is that you need a specialised framework depending on what you are building. All the frameworks I have seen are aimed at front end developers building front end websites, and these are second rate when it comes to building back end administrative applications. Let me explain the difference: a front end eCommerce website is nothing more than a glorified Order Entry system, whereas the back end application does absolutely everything – product maintenance, customer relationship management, sales order, purchase orders, inventory, shipments and invoicing. I have built my own back end ERP application, using my own back end framework, and it contains over 2,000 transactions. Compare this with a typical eCommerce website which has only 20 or so different screens.

A front end website is primarily built for show with its gaudy HTML, CSS and JavaScript whereas a back end application is about the data – members of staff need to access the data using sets of uniform screens, and need to be able to change the state of objects quickly and efficiently.

My own framework provides what no other does – it generate the Model classes for you, it has pre-built Views in the form of XSL stylesheets, and pre-built Controllers based on Transaction Patterns. It also has an in-built menu system, Role Based Access Control, Audit Logging and an Activity based Workflow system. Working transactions can be built in minutes without writing a line of code. What other frameworks can match that?



For me a framework is a set of things/Tools that helps to build a Non-Existent thing or to accomplish an action in an easy and defined way.



FW isn't suppose to give me architecture, application architecture should come from business rules not the garbage around it. The only usable framework in that sense is ZF2 that don't force any conventions except for module registration and standard auto loading like psr-0 (u could use psr-4 too). I don't want business logic mixed up in controllers + views + active record model, i want it separate and easily searchable + testable.



Love it. Keep writing man.



It's worth reiterating Martin Fowler here, because fuzzy doesn't mean "up for grabs". Frameworks are not libraries, and vice versa:

``` Inversion of Control is a key part of what makes a framework different to a library. A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client.

A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework's code then calls your code at these points. ``` from:

Frameworks and Libraries touch, and overlap… any team working on a framework is probably investing a lot of time building great libraries which the framework leverages. A bad framework makes no attempt at separating the libraries out. This is a kludge. A framework often boils down to a DI mechanism that comes bootstrapped for you, suggesting a way forward so you and your team don't have to reinvent the wheel each project. While frameworks aren't necessarily easy to build they should be as disposable as possible. While frameworks save you time by reducing boilerplate they shouldn't impose a monolithic vision on your application.

Libraries do work. A library is a collection of modules focused on a single problem domain. While some libraries may seem to touch multiple domains, these should really be subdomains — libraries should not jump between domains. Taken as a collection a library may suggest a specific orchestration but each module should be built in a discreet fashion, simple to use in relative isolation.

Modules constitute the smallest part. In an OO paradigm a module is a single concrete object that does a job. A well designed module should provide a clear input and output mechanism to accomplishing a single task.

The goal of the frameworks is to remove the repetition of knitting together libraries. The goal of libraries is to group modules. The goal of modules is to demonstrate the smallest unit of work needed to transform an input into a useful output.

Ideally every element I've described can be swapped out for a different implementation with minimal ripple in either direction. A framework should not require a particular module and vice versa. In a practical sense when you use a framework you're leverage the benefits of a curated constellation of code preconfigured to play nicely but great framework designers avoid forcing their taste down your throat.



@Tony Martson - "My own framework provides what no other does"

No, just no. For the sake of your clients and any developers that may some day have to work on your code, stop rolling out your own cowboy coder "framework." Just stop. Nothing of what you describe in any way shape or form constitutes an edge case were rolling your own framework over an established system is critical or a better alternative. In fact, the only take away from your post is that you've spent precious hours re-inventing wheel after wheel after wheel.

Posting comments after three months has been disabled.