The Tribal Framework Mindset

Posted: 2014-01-02
Category: PHP

Twitter seems to lead to the same thing happening over and over again.

  1. I say something I think is entirely uncontroversial
  2. People misunderstand and jump to weird conclusions
  3. Some folks start defending against that weird conclusion
  4. When I try to explain why they are mistaken, people go reporting to @PHPDrama

Yesterdays comment:

I meant to say "siloing", but being half asleep after a 24-hour session in Atlantic City in the back of a minivan with screaming kids meant that I made a mistake. It should still have made sense.

Well, I thought so at least until I had a myriad of bizarre responses from people (mostly the well-known Laravel names) defending and picking issue with things I said, assuming instead of saying something logical I must have meant something moronic. That is rather offensive to me, so let's explain it for them.


If you are building a PHP package then you are faced with two options:

  1. Make it work with your favorite framework
  2. Make it run with every framework out there

Now, if you pick option 1 then a) you are just trying to save time, or b) you suck. I've been talking about framework agnostic packages since early 2012 when Laravel 3 had bundles, CodeIgniter had Sparks, and everyone else had something else just for them. Frameworks didn't have much choice than to build their own solutions because the only other option was PEAR, and most of those frameworks were built with "avoiding PEAR" as one of their main selling points.

We've come a long way in that time through the proliferation of Composer, and frameworks like Laravel are doing a good job at making the Composer uptake better, but many people in the frameworks communities are bad at making their code work outside of their specific framework environment. Even Laravel 4 itself does not advertise much about how to use its packages outside of Laravel. I wrote about how to do it with the Database package back in December 2012 but that was made easier thanks to the Capsule package (later rolled into the core) built by an employee of mine to simplify the bootstrap process. I mention this not to "brag" as somebody suggested, but to highlight that I am very aware that some packages CAN be used alone, but most packages are not as easy to bootstrap as Eloquent, and there is a reason why Eloquent is so easy. Most L4 packages could benefit from this sort of easier bootstrapping, as it can be pretty tough on some packages, especially something like Pagination which requires an Environment variable, knowledge of the Symfony HttpRequest, Views, etc.

So if Laravel itself is not advertising its usage outside of Laravel with even the most basic README examples, and so many developers in the community are stuck in this "I only ever use Laravel for everything, and why do I care if it works with CakePHP" mindset we're left scarily close to where we were last year - with frameworks that don't play nicely together, and developers who don't build code that works together.

If you don't believe me, go and have a look at all of the Laravel specific packages on packagist. Some of them are bridge packages for generic code (which is excellent) but many of them are Laravel-only for basically no reason. That makes me sad.

An example I often use of a framework agnostic package is Sentry which took the approach of "build in support for everything". This is an excellent solution as it means seamless integration for much of it, but certainly can be hard to do. Keeping it generic and linking to bridge packages in the README is another simplistic approach.

Fractal is another example, as is any package in The PHP League of Extraordinary Packages. The League is a silly/fun vendor namespace used by me and a group of friends so we can switch responsibilities on projects without having to move them around between ourselves or constantly pull request each other. All of our packages are completely framework agnostic and list bridge-packages in the README. Nice and easy.

Update: People have suggested that writing framework agnostic code is something the average person doesn't have time for when they're trying to hit their business goals. Well two things to that:

  • It's not actually that hard. All you have to do is make sure your code (other than the service provider) does not directly require a piece of any other framework. NO HARD DEPENDENCIES. That makes testing easier anyway and is already something that most Laravel developers are doing with the repository pattern. If you use the repository pattern, you can easily tuck your framework dependencies behind an interface in a completely identical fashion.
  • Why are you releasing packages at all if you're rushing to hit your business goals? Come back and do that after "the launch".


Something that gets my back up is when developers brand themselves as "Laravel Developers" or "CakePHP Developers" instead of "PHP Developers". I have tried suggesting to people that "Web Developer" was a better term, but the more CLI, API and parallel work I do the less I feel like that term applies. "Software Developer" or "Software Engineer" fits like a glove, but regardless of wether you want to go that far: You are not purely a Laravel Developer!

Doing this you are saying to the world: "I only know FrameworkX." Like the JavaScipt developers who only know jQuery, and are therefore probably useless with AngularJS or Backbone.

By picking only one framework to represent your skills you make yourself less appealing to those who assume you don't have transferable skills. Sure they're wrong, but you just lost out on a potential job offer. After-all, if you are a good enough PHP developer to easily use any framework, why are you listing yourself so specifically with one specific framework? You are a PHP developer who specializes in Laravel, not a Laravel developer.


Everyone and their dog is writing a book at the moment (myself included) and a popular topic on the internets these days is Laravel. I suggested that if you are writing a book that could be applicable to any framework then you definitely should do that. Obviously a book about "how to learn Laravel" should not have a "to run Migrations in ZF2", but a book almost anything else does not need a hard requirement on a specific framework. For the same reason packages shouldn't, and because it hurts your sales, hurts the PHP community at large and keeps people trapped in this tribe-like mindset which has been plaguing the PHP community for a decade.

The same applies to blog posts. An article about Laravel and some piece of technology should probably just be an article about PHP and the technology. This can just come down to SEO. If the only person to write about Neo4j is writing specifically about using it in Laravel then some other PHP developer might not spot it on the search terms and spend a few days trying to work things out for themselves. The number of man-hours wasted by these different PHP tribes doing the same things over and over again is an absolute travesty.


This same logic applies to Laravel community resources.

Jeffrey Way unfortunately assumed I was talking about his Laracast video about community with my original tweet. Again, not the case. Laracasts plays an incredibly powerful role in releasing high quality training resources for people that want to learn specifically about Laravel, so shoving AuraPHP advice in there might not be something anyone would care about.

To me it seems that this video was far from being a problem, but was confirmation of everything I've been saying. The intro describes the problem that the video then goes through solving: "You know the drill, you join some new technical community but you dont yet know who is who or what is what." That is exactly the issue here.

This is what keeps people using their one-true-framework over all others for so long. With all their code in that system, and all their knowledge, and all their friends, and all their RSS feeds, all covering that one community, the thought of moving to another just seems like death.

We cannot expect all technical communities to be one because they share so little in common. Moving between Python, PHP and Ruby as I do there are certainly very separate communities, but we certainly shouldn't have this wall of confusion between different frameworks in the same language, and it certainly should not be such a large wall that it needs to be put into a video. If I start using some Python framework I might expect to be a little lost learning about where to get my Python news, but I wish we didn't have to have to have any of this confusion between PHP frameworks.

Further to that, things like the Laravel Packages Registry (linked to in the main wiki) are dangerous. Lots of developers coming into the Laravel community are extremely inexperienced as it is all about having a minimal entry level. That is excellent and was one of the biggest selling points of CodeIgniter for all those years, but folks managing various resources in the Laravel have to keep that in mind when making decisions. By making Laravel-only package repositories like this you are training these developers to go and find their packages in this one resource, instead of just… using packagist.

Every other day I see somebody saying "Anyone know a good Laravel package for X?" My answer is usually a link to


Why is this any of my business? Why should you listen to me? Because I spent almost a decade doing this shit and it was awful. CodeIgniter this, CodeIgniter that. I was typecast as the CodeIgniter guy, all of my freelance requests were CodeIgniter. My blog was entirely CodeIgniter, I built APIs in CodeIgniter, I ran gave talks about CodeIgniter, I almost had CodeIgniter stamped on my tombstone.

Then CodeIgniter pissed me off so hard I got involved with creating FuelPHP and using the two taught me some serious lessons about framework agnostic packages. Maintaining codeigniter-oauth2 and fuelphp-oauth2 was enough of a life lesson in itself.

I vowed to never get stuck in that mindset again, and have since been working my arse off on the PHP Framework Interoperability Group to help make new PSRs, help work on the community issues, get the website improved, create new bylaws to streamline the development of new PSRs, etc.

All of this work can easily be undermined by people unthinkingly staying in their tribal framework mindset, ignoring the rest of the PHP community and creating too many Laravel-only resources.

All of you developers. Guess what: In 5 years you probably wont be using the same framework.

That's not an insult to Laravel, or Taylor, or anyone else from any other framework. I'm just telling you it wont happen.

You'll change jobs, or something new will come out, or your management will randomly decide to go webscale with NodeJS, or the next version might change too much for you, or not enough for you: whatever. You will need to be ok with changing tools and knocking down the walls between the PHP frameworks by letting people continue to use the same packages and package managers, etc means changing between PHP tools is less drastic and time consuming for everyone.

One thing I am happy about is Taylor Otwell has learned from the issues of the Kohana community, which not only broke itself in half with the v2/v3 debacle, but isolated itself from the rest of the PHP community with leadership that was often nothing short of obnoxious, but definitely elitist.

Luckily that itself is not happening. Laravel made it through v3 to v4 with minimal pushback and v4.1 is a feature-packed but simple upgrade. The leadership is also generally incredibly friendly… except for when they talk to me like I am just some basic bitch.

But the other concerns worry me. I don't want any PHP developers wasting their time on tribal bullshit. I don't want people having to spend time relearning over and over again. I don't want developers getting religious about their choice. I don't want people having to port packages to work on other frameworks. All of that is happening, and all of it needs to stop. We are the PHP community and together we are fucking huge. 80% of the internet is ours, and we need to remember to work together instead of fragmenting the community, siloing it with framework specific resources that have no reason to exist.

I just ask that you keep that in mind when you are making decisions; developers and community leaders alike.


Jeffrey Way


Discussion is fine. But you often fall into the trap of assuming that every time a person responds with a question, they're "being defensive" or they "need to calm down." Maybe they're just asking questions to understand more. Always assume that the other person has a smile on their face.

If I post a video on "The Laravel Community" and make reference to "Laravel Developer," when you make that tweet of yours the same day, forgive me if I assume that you're responding to the video. Evangelizing the Laravel community is no different than evangelizing, say, the jQuery or Angular or Backbone communities. It's not an attack on PHP or JavaScript; it's simply a way to learn about smaller ecosystems. This is a good thing. It's the same reason why we don't hang out in a #software-dev IRC channel.

And just to clarify, if I say "Laravel Developer," I'm not isolating Laravel from PHP (duh). I'm simply referring to a dude that likes to build stuff with Laravel. I wouldn't recommend that a PHP dev listen to the podcast. But I would to a Laravel dev. That's all I meant.

Good discussion, though. Nobody is being "touchy as f*&k," as you eloquently put it. :)

Judas Borbon


I really love Laravel because I have learned very good things about Design patterns and Dependency Injection and because it doesn't limit you at least in how you can design your classes; not to mention Composer. But I agree with you that for some folks it feels some sort of weird cult.

If my memory doesn't fail me, when the framework was gaining traction I often saw comments like "the super framework this, the very awesome that". Yeah, it's great but C'mon.

What do you think of packages that can be used standalone but offer a service provider for Laravel integration? Something that bugs me about them is even if you won't use them inside Laravel you still need to install the Illuminate/support dependency.

I was surprised of people's response at your tweet. It was really clear to me right from the start.



I would love it if people were asking questions to find out what I actually meant. That is what I always do, but it didn't happen here at all. People simply responded with "No" and "What you are making does not make any sense" as their only original responses until I mined THEM for more information.

And I called you defensive, because you were being defensive. I've noticed a few people acting like defensive is an insult, but it isn't. You mistakenly thought I was attacking your work, and responded as such. "Yeah, not gonna feel badly about a Laravel community overview video." You are defending your video (which is defensive) and defending it from an attach which never happened (which I would call being touchy as fuck). :)

Yes, a Laravel podcast about laravel news is great but you're ignoring the rest of the article.

Max Schwanekamp


It's marketing. The Rails - Laravel comparison is a good one. When Rails arose, its brand was DHH's "do it this way or fuck off." Those who accepted that, embraced the "opinionated framework" concept loved it. To this day people still commonly refer to themselves as Rails developers, I think largely due to the name-recognition that Rails has. Same with Django, to a lesser degree.

Laravel is the first popular PHP framework to really get the marketing side of things. Look at the code, starting with public/index.php. It's more comment than code. "Feels great to relax" says the first docblock. From "web artisan" to the Eloquent ORM, to the codename Illuminate, I think Taylor really got the right balance of a solid framework combined with the right marketing tone.

Laravel the codebase clearly isn't in a silo, but Laravel the brand name is gaining marketing value (look at the excitement around Laracon) and therefore a means to differentiate oneself from the worldwide herd, so to speak. If you write a book focused on good PHP coding practices, but give it a Laravel spin because you know that it'll sell more books that way, why is that a bad thing, particularly the Laravel codebase is ultimately encouraging good (or at least better than average) coding practices anyway?

Some people are always going to take the specialization thing too far, and then you get the Laravel Package Registry etc. This isn't a fault of the framework, or even its marketing angle. It's just people being enthusiastic and trying to find points of differentiation. Eventually the sparkle fades from their eyes, and they realize, like you did, that it's better to embrace the wider programming community.



Max: I agree with much that. I was definitely speaking about third-parties as much as Laravel itself. I obviously covered a few points in this, but I am not trying to blame Laravel itself for these Laravel-only resources popping up. I am saying that I don't like them existing though. :)

But back to the book comment. If a book could be about PHP in general but they decide to ignore it and go entirely Laravel then the damage is clear: people who do not care about Laravel do not get the chance to read a book that could have changed their life as a programmer. Maybe that one book would have been the one to really make polymorphism pop, or would have helped them be really SOLID. Why does Laravel need to be a requirement for that to happen?

Matt Frost


Here's how these discussions normally work: 1) Say something that suggests Laravel isn't the best thing ever 2) Get 50 replies from people jumping down your throat, telling you that you're wrong 3) Accuse them of being defensive 4) Off-putting response of "no one is being defensive" 5) Defensive people suggest that those who offered the opinion "calm down" a little bit

Even if the framework is greatest thing that ever existed, who would want to surround themselves with this every single day? Not everything that people say is an "attack" on Laravel...seriously



This is really getting old already. I really respect Phil and a lot of others, but when you guys repeatedly single out Laravel, and say, "You're doing it wrong." Obviously people passionate about it are going to respond somewhat defensively. I think as a whole, the Laravel community has been very good at responding light-heartledly to what our obviously direct criticisms.

Then what happens is the original attacker says, "I wasn't attacking you, you mis-understood, you're being hyper-sensitive." Come on, we are all intelligent people, we all know that these are attacks.

And for what? For being passionate about something we find exciting? So what if there are a lot of laravel packages, which I don't actually believe, most a just wrappers for generic packages, similar to bundles.

I think every single programmer that picks up Laravel will end up a better programmer because of it. Isn't that the point? Who cares if they are not absolutely framework agnostic.

Ashley Clarke


As a developer I think it is great to get into an eco-system like laravel. I honestly do not think I would have the same skill set i do if it wasnt for laravel and its community, with all the resources out there pushing best practices its a great help.

Books: I completely agree that they should be as agnostic as possible, there will be so much more education available to all. That said, when Jeff released his TDD book with a laravel focus, i bought it almost straight away, would I have done the same if it was completely agnostic? maybe, I am not sure.

Packages: Yeah, these should definitely be agnostic whenever possible. Only reasons why it shouldnt be is if it is for laravel (such as an artisan package) or if you work in a team with only laravel then if you build a package you will create a laravel service provider and be done with it, you are not going to worry about other frameworks here but the package should still work with other frameworks.

I think last nights discussions went a bit overboard. And like you said will be be using laravel in 5 years time probably not, i'd liek to think that by then we will all be building our own frameworks that work exactly the way we need pulling in the parts we need/like from all the other php frameworks out there :D

Michael Calkins



I watched that whole conversation unfold, dude just chill and then make a response.

Leaders think, evaluate, and respond.

Be a leader.



Juni: " but when you guys repeatedly single out Laravel, and say, 'You're doing it wrong.'" I've been saying nothing of the sort. I've been talking for the last year about how I have been enjoying using Laravel.

And as for being "an attacker", I explained how their attacks were invented. Jeffrey felt attacked, and that was his assumption. Ian and Taylor felt I was making a weird and shitty point, I explained how I was not making that point.

If I want to call somebody a cunt, I will call them a cunt. I have never shied away from being direct.

I did not originally attack anyone, and I did not then retract the attack. I don't appreciate you suggesting that I did that, but I do appreciate your passion for a product you enjoy using.

You do however need to be careful to walk the line between being passionate about a product, and being a small-minded fanboy who is screaming at everyone to use the framework they like.



Michael: I thought. I evaluated. I made this blog as a response.

David Stanley


The whole "my framework is better than yours" argument sounds a lot like the Butter Battle Book ( Not that there aren't valid differences between frameworks, but Phil's point is right on.

Don't limit yourself and your work just because you like a framework or tool. Be enthusiastic about it. Learn it. Use it. If you need something that it doesn't provide, build a composer package, not just a Super-Awesome Framework package. If the problem you are trying to solve is specific to Super-Awesome Framework, then that is fine. If your book is about using Super-Awesome Framework, then great. Otherwise, you limit your impact on the greater community.

Lewis Cains


Hi Phil,

I'd like to put a different take on things if I may and would be interested to hear your thoughts on this. Sorry for the long-ish post but I keen to hear some views on my points.

I am (I guess) a fairly inexperienced developer certainly compared to you or Jeffrey Way (It's been just under 3 years since I began to self teach). I have a huge amount of respect for you both and have learned a lot from all the Laravel stuff and from reading your blog posts so thanks for that.

I have recently developed real issues/concerns with the idea of using a mainstream framework because I think that this may disrupt my learning process. I'm not too sure that the use of third party packages/libraries etc is always the best idea for me, the biggest reasons for that being that if something breaks I could suddenly be in trouble and at the mercy of things like the quality of the documentation and even my own ability sometimes. I'm not ashamed to admit that at my stage of learning, I have to be very aware of this possibility.

To date, I have used Codeigniter quite extensively (more so than any of the others) and when the realisation came that this framework may effectively 'die' it then dawned on me that if I'm only as good as the framework that I use then this is not a good thing! Suddenly I could be in a position where I am a developer who can write 'codeigniter' but may have forgotten some of the important vanilla php stuff!!

This is why for the past 2 months I've been building my own framework up and have begun utilising it in live projects as it gives me the chance to continue to build it up further during a live project. I get to see it break and then instantly get feedback about where I may have gone wrong, and then the opportunity to improve as a developer by fixing the issues.

The learning process during this time has been extremely valuable and I think it has helped me develop my own skills far more than using library after library from composer which although is simple, quick and efficient most of the time - it has never been reassuring to be using someone else's code that perhaps either:

a) I don't fully understand or b) that I wouldn't feel comfortable debugging.

This perhaps is my biggest question to you - do you agree with my approach or do you think everyone should be using libraries and frameworks consisting of someone else's code? What is your perspective as a more experienced developer and what do you advise newer developers to do? Get involved in the risks you discuss above from using a mainstream framework exclusively, or learn how to do this stuff for themselves?

I guess there is a balance in there. In a busy live working environment, obviously speed is priority and these are the times I am sometimes forced to use plugins and libraries because I can reach a solution quickly. I still don't like doing this though and try to avoid it whenever possible if can create my own solution.

Thanks for reading this and I look forward to your reply. Happy to clarify my points if nothing makes sense.

Many thanks, Lew

Sam Evaskitas


Here's the thing Phil, you're not going to stop the bandwagoning with a frustrated tweet. Laravel has reached some sort of critical mass lately, hundreds of websites and specific content - and yes, fanboys - will follow. That's how the internet happens, it's inevitable. But there's room enough for Laravel to have its own little ecosystem and not detract from the PHP community as a whole. I think you'd be a lot better promoting the benefits of cross-pollination between different communities and framework agnostic development rather than venting about potential siloing. The short-sighted tribal developers are probably not the ones you want contributing to the community anyway.

Max Schwanekamp


Good point Phil re the book. But again, if a book is one of 300 books about OO PHP, or PHP design patterns, etc, there's a good chance that it won't reach as many readers than if you call it something like "Laravel Design Patterns" or whatever. Your example of the book not reaching people who don't care about Laravel is logical, but doesn't make marketing sense if the book reaches twice as many readers by adopting a known brand as the context. And again, if by using the Laravel brand, more devs are adopting Laravel the codebase, which is obviously increasing adoption of a generic package manager and teaching by example with inclusion of community packages, it still seems to me like an overall win. Maybe someone can write "Beyond Laravel" as a bridge for us mediocre tribesmen who might wonder what life is like on the outside.

Antonio Ribeiro


I can see some good points in your post and your tweet, but if stop to think a little bit about people that doesn't know much about PHP nor Laravel, it's not really reasonble to ask them to start it all up by creating framework agnostic packages.

I think this community will have to grow a couple of years mode until people is really ready to do that.

People still doesn't know what OO PHP is, if you tell them "don't create framework specific things" you are removing from glue they have with to PHP, the thing that make them write code fast and be productive, the codebase which pushes them on writing clean code, which teaches them what the f*ck is dependency injection, SOLID, DRY, design patterns, unit testing..., you're depriving them of the community which makes things easier for any newcomer! You have a coding problem or even a design one, just tell you have a Laravel problem in the IRC and someone will fix it, or put you in a better track, just give them five seconds.

Ok, now you think you know everything, you have a nice idea and you wan to to give back and create a package, but not just for Laravel, it must be something that Symphony developers (can we call them this way?) would love to have access too.

All right, your package will need some common things:

1) Database or just data access 2) Cache 3) Session 4) Cookies

You create it all? Of course not, you better use another bunch of agnostic packages, right? So you go with Laravel Eloquent or Doctrine DBAL? How do you make a third party cache layer work with Eloquent? You know Laravel, you mastered it, you love writing with it, so it will be easier to start with, but will people know that your package is framework agnostic? How agnostic would the community consider your package if you had to use some third ones? Shouldn't you learn a little Kohana or Symfony and use some of theirs? Which one is better? Should you go with the better or the easier to learn and code with?

How do you do all that and also unit test a fair portion of your code?

Should you still create this package?

I just finished a framework agnostic PHP package (, and had all those doubts, maybe more. Of course it is Laravel related, the datasource implementation uses Eloquent, but you can add your own. At some point I got stuck with cache. Doubt made me wrote an odd implementation of it until I figure how to use some better one, maybe Laravel Cache. To ease the things, I digged down the Cartalyst's Sentry source code and made mine resemble to them, helped me a lot, but when I published it I still had a lot of doubts. Will this package survive to all that?

I can tell you that I almost didn't created that package, because it's easier to go with something you know, it's faster, it will give you a lot less trouble and doubts, but Laravel taught me how to do things in good PHP, things I would never imagined one year ago, so I had enough confidence to at least try it, and I kind of did it. :)

What I can advise: if you are really experienced in PHP, if you have it mastered, write an agnostic package, if not, choose the Framework you like the most and code for it, as soon as you get better, try to make it a little bit agnostic, just don't let this package die.

Donald Allen


Phil, "cunt" is not gender-neutral.

Also, I agree with your blog post, but I would argue that becoming an expert at [insert modern framework] makes you a better PHP developer in the long-run.



"By picking only one framework to represent your skills you make yourself less appealing to those who assume you don't have transferable skills. Sure they're wrong, but you just lost out on a potential job offer. After-all, if you are a good enough PHP developer to easily use any framework, why are you listing yourself so specifically with one specific framework? You are a PHP developer who specializes in Laravel, not a Laravel developer."

While you are technically right, one thing I've found (at least in the US job market), is that framework knowledge is a huge key factor in getting hired. For example, I know JavaScript in general. Between jQuery, a little Backbone, a little NodeJS, and some random projects that use "vanilla" JS, I can pretty much pick up any framework and run with it. The problem is, the people doing the hiring don't really care. They just play Buzzword Bingo most of the time. "Oh, you know JavaScript? Do you know AngularJS? No? Sorry, we can't hire you, then." Now, I've lost a potential job offer, anyway.

Conversely, I also get a lot of crap leads, because I have .Net in my history. I have no interest in working for a .Net shop (preferring open source shops), and try to communicate it up front. It saves both my time and the recruiters'. It can even be a framework within a language, though. I don't really want to work in a WordPress-only shop, either.

As an ideal, I think you're spot on that we shouldn't be "$framework developers," but in reality, sometimes marketing yourself (at least to some extent) as such helps filter out the time-wasters and bypass entirely the offers that I have no interest in, or have no interest in me, allowing me to find work that's a better fit.

As for your initial Tweet, perhaps I missed some things, but I didn't see much in the way of getting touchy. Also, language is funny like that, how a single character can change the entire meaning of a sentence. ;) (It's also why I don't do much with Twitter. The need to fit thoughts into 140 characters tends to be prone to misunderstandings, at least for me.)

From what I've seen, though, of the framework communities, the core Laravel community has made more efforts to advance PHP as a whole than a lot of (most?) other frameworks. Is it perfect? Of course not. We're all still working the details out, and we're all still human and have limited resources. The extended community does start getting into sketchy territory, but you get that with any popular framework/platform (the same criticisms of crap packages can apply to software applications for a given OS, too). It also happens to most things built in PHP, due to PHP's low barrier to entry. I'm sure FuelPHP has its share of things built with/for it that make you want to flip your desk.

As for the books, while I also agree that a lot of the things that some consider "Laravel-specific" can and do apply to PHP in general, a lot of the techniques in general are rather new in the context of PHP development. The Facades and IoC stuff can be used in PHP outside of the context of Laravel, but it simply hasn't happened yet, just like MV* wasn't used much outside of the context of Cake and CodeIgniter back when they first started. It will come, in time. And for those that see a book like "Code Happy" and think that because it's a "Laravel book," it doesn't apply to their work in PHP - they may not be at a point in their programming knowledge to fully understand things like IoC and Facades, anyway, let alone how to apply it outside of Laravel. The ones that can do things like that will probably skim through the book (or find out about the concepts elsewhere) and incorporate what they learn.

Steven Wade


First of all, I love this. Phil speaks and everyone freaks. It's hilarious!

Second, frameworks are great. I gained traction quickly and kept my interest in PHP because CodeIgniter was so easy to learn and use. Frameworks exist to make our lives easier. A community of examples in a specific framework helps people learn how to better use that framework. They have their place. You've made a good point of stating that as well.

I totally understand where Phil is coming from though. Learning PHP by starting out with CodeIgniter, I got attached to CI and wouldn't use anything else. As I grew as a developer, I began to see that although it was a great tool, it made life easier, and it helped me learn quickly, locking myself into that framework, I learned some really bad habits that didn't translate well to plain PHP. Now having stepped out, examining other frameworks, using multiple packages, embracing PSR, I get more information and can view things from a top level to find the similarities.

Every framework, every opinion will have it's bad habits. By exposing yourself to multiple sources and diving into any resource you can get your hands on, you will learn to look through/passed the opinions and form your own.

PHP developers should be just that, PHP developers. It's ok to be a framework developer if you're just starting out or don't want to grow. A "framework developer" is really a web developer who can do PHP. A "PHP developer" is a software developer who uses PHP. The two are just different growth stages.

Anyways, I've rambled and I never read through to edit my thoughts, so I hope they made sense!


Great post Phil!

Justin R


Phil, I am a Laravel fan and think you are as abrasive as fuck. Still, I didn't see a problem with your tweet and the ganging up on Twitter seemed a bit cultish.

I think it goes without saying, Taylor is sensitive about his shit. I think Laravel is great and it's made my life a lot easier in the last 12 months, but the community needs to get off their high horses and chill.



Max: "Your example of the book not reaching people who don't care about Laravel is logical, but doesn't make marketing sense if the book reaches twice as many readers by adopting a known brand as the context."

Again a fair point, but are there more PHP developers or more Laravel developers? Opening yourself up to a larger market just makes business sense, but you can still litter your description with Laravel keywords along with other frameworks to pick up those same users.

Antonio: Writing framework agnostic packages is certainly more difficult than writing framework specific code, so maybe we as a community should focus on making more resources available covering how to do it. PHP The Right Way has helped condence a lot of advanced concepts for beginners, so we can keep on down that line. We cannot simply avoid doing something because it is difficult.

Donald: I myself consider both "cunt" and "dick" to be gender-neutral and use them both interchangeably. That is progress.

Steve: Thanks!

Shauna: Agree with most of that, but just because Laravel is dong a good job at utilizing PHP tools and components does not mean we should be forcing everyone down a Laravel path. In a recent survey done by SitePoint, a large number of people thought the Laravel team built Composer. This sort of ignorance in the community is terrifying.

Justin: You wouldn't be alone on that! My mother said I don't suffer fools gladly, which I think was her way of saying "You're abrasive as fuck". Others consider it a no bullshit attitude, so call it what you will.

But yes, I can understand people protecting their work but the only people getting their backs up were in the Laravel crowd. The ones agreeing were the people who use multiple products, build agnostic stuff, and/or who know that I wasn't trying to insult anything.

Tomas Harris


The thing is that alot of people set alot of time into laravel, so i can see your comment getting under their skin. Imho i dont think you made any "aggressive attacks" or anything like that, however i think you focus on the wrong entity here.

Its quite trivial to port a laravel package to a general composer package, skipping the facades is a good start. I see the problem more in the cms/cmf world. It is impossible to create a general composer package from a drupal/joomla/wordpress/pyrocms package. This is not a problem imo, but you could have focused on this part of tech, and not on a framework like laravel.

This is often the entry point for many to webdevelopment, and php. So getting new devs ready for composer from the start is something that could be beneficial.



Hi Phil and thanks for the great post. In my opinion, the thing to point out here is the lack of resources about how to build a framework agnostic package. Frameworks are so great, I learnt so much these last months just by using Laravel, reading its source code, reading a bunch of blog posts like yours. Now I want to go a step further and share what I learnt by making packages to help the PHP community. And as Antonio said, this step is very hard and there is not so much resources about creating framework agnostic packages. I think there is a lot of people who want to create packages but aren't even aware about framework agnostic packages. Anyway, I hope your post will transmit the message, and more resources will be made about this subject. I enjoyed this talk of Ben Corlett (from Cartalyst) about developing framework agnostic packages : and I wish there is more about it.



Love your blog posts Phil, and your community here rocks too!

Paul M. Jones


> so many developers in the community are stuck in this "I only ever use Laravel for everything, and why do I care if it works with CakePHP" mindset we're left scarily close to where we were last year - with frameworks that don't play nicely together, and developers who don't build code that works together. > > ... > > An example I often use of a framework agnostic package is Sentry which took the approach of "build in support for everything". This is an excellent solution as it means seamless integration for much of it, but certainly can be hard to do. Keeping it generic and linking to bridge packages in the README is another simplistic approach. Fractal is another example, as is any package in The PHP League of Extraordinary Packages.

It's too bad there isn't an entire framework-ish project out there that was built with a "libraries first, framework second" approach.

Oh wait, there is! It's called Aura:

I will admit to some level of impatience here. Phil, buddy, you should know better at this point than to have a blog post like this and not mention Aura prominently as an example of the very thing you are espousing.



You mean you can't have a meaningful discussion in 140 characters? Imagine that.



Jgx: Yeah I advised Ben a little on that talk and was glad to head he wanted to give it. I'd planned on writing a blog post before that but didn't want to steal his thunder. Maybe I can do a blog post and Jeffrey can do a Laracast on a few approaches to building framework agnostic code.



Developers will always be developers. There is no such thing as a PHP or Laravel developer. Interoperability is a human effort. In all domains, not limited to programming. This applies to countries as well as tribes. And how do we do that: being diplomatic. I think these are the evolutional steps a PHP developer goes through: PHP developer -> FrameworkX developer -> developer

Michael Budd


Phil... ignore the haters. If I've learnt anything since I started programming is that it is wrong to be so strict and rigid in my opinions, I am always open to new ways of doing things and different opinions. I would be scared to criticise Laravel due to it's huge fan base... but surely that isn't right? You're right to say that developers should not affiliate themselves with one framework... I'd even extend that to say they should not affiliate themselves with 1 language! I also think that Lew is right to recommend building your own framework.. reverse engineering is hugely beneficial.



"Something that really gets my back up is when developers brand themselves as "Laravel Developers" or "CakePHP Developers" instead of "PHP Developers"

As a related tangent to this, this is why I refuse to use Doctrine in a PHP project. Why? You have to learn TWO new languages just to use it (at least in advanced applications).

First, you need to learn its DocComment "language". Honestly, wtf is @inject??? Then you need to learn DQL, which is kinda like SQL, but not really. Granted you don't always have to use DQL, but why should you have to learn a new dialect of a language you already know?

MANY components do this. Redbean does it to an extent as well:


Those instructions embedded in that string are in effect, another language.

So given that so many frameworks/components/modules tend to inject their own languages into PHP, it's no real surprise that some developers label themselves as a "Laravel developer" or a "Cake developer". Too many frameworks/components/modules abstract away too much of the core PHP language itself, and require people to learn their own small sub-language just to use the code.

This is not right.

Márcio Almada


I don't see any problem with someone being a Laravel developer, I just see a problem when people start to alienate themselves with a stack of misconceptions about the tools they are using.

I already met Laravel developers that thought composer was part of the framework and they got really surprised I was using it to handle a non Laravel project, like if was doing some kind of hackerism. THIS IS SAD and happens not only with Laravel... I already met rails developers that really thought active record pattern was some kind of package invented for Rails... sigh.



Paul, we all know you are trying to school the internet on your version of reality but its enough when you do this on your blog. Most of the more known frameworks have taken given a high priority to build components that can stand on their own. Knowing Symfony2's history the best, I can tell you for example that Jordi and I created a framework on top of the Symfony2 components, while they were still in development, in 2009. I even gave a presentation about it in 2010. Guess what? This was in fact the first Symfony2 based framework that was available and aside from the components and some email exchanges Fabien didn't have any hand in it. And why was that the case? Because Fabien wanted to take a component first approach. Here are the slides:

Silex btw was a by product of wanting to then have 2 frameworks as test beds to ensure that the interfaces in the components are actually also sensible in the real world serving different ends of the user spectrum (full stack vs. micro).

Anyway, I know you are busy releasing the first PSR-4 auto loader. Whatever "first" means but in your reality beta seems to be better than "in production" (see composer).

That being said, you are not alone with this bullshit of course, Lithium still claims to be "the first and only major PHP framework built from the ground up for PHP 5.3+". I of course have also been criticized for questioning aspects of Zend Framework.

Argh, I shouldn't even bother ..



anyone who doesn't know how to write a framework agnostic library should not be a developer.all resources you need is php documentation and optionally packagist to reuse some existing packages.

very simple and easy

Stelian Mocanita


What if I told you that MVP names such as League of Extraordinary Packages or w/e is part of the reason communities are highly segregated? What if asking for people to namespace their code with League is actually part of the problem (take it as an example, don't get stuck on it)?

Another thing I would like to point at is you "paying an employee" to refactor something. Is that information necessary in any aspect other than you gloating?




> What if I told you that MVP names such as League of Extraordinary Packages or w/e is part of the reason communities are highly segregated? What if asking for people to namespace their code with League is actually part of the problem (take it as an example, don't get stuck on it)?

Well that would confuse me for a number of reasons Stelian.

  1. The League is not a community, and therefore cannot lead to community segregation
  2. We do not ask anyone to namespace their code with League
  3. All packages are completely framework agnostic, so this is completely 100% the opposite of the problem I am suggesting, and that you are suggesting

> Another thing I would like to point at is you "paying an employee" to refactor something. Is that information necessary in any aspect other than you gloating?

It is not at all unnecessary gloating. Why would I gloat about doing my job? I pointed it out to highlight two facts to the reader:

  1. I know that some laravel components can be used outside of Laravel itself, especially Eloquent. People kept telling me about that, and I wanted to explain how and why I was very aware of that fact
  2. I wanted to point out why Eloquent is more able to work outside of Laravel than others, and why it had more documentation that others: because I made it be the case

I would ask you to reconsider your comment based on that feedback.



Ha, Sturgeon, why it that every time I see your name popup on the internets you are invariably embroiled in some bitch spat? You ain't no Zed Shaw, friend, but I must admit that I do find it amusing.



Christian: I'll be damned if I know. I'd like to think that its not EVERY time, sometimes I do something useful.

Paul M. Jones


Hi Lukas,

> Most of the more known frameworks have taken given a high priority to build components that can stand on their own.

And I'm glad that's the case. Aura <> happens to be 100% consistent in applying that principle to its library packages. This is more than, say, Symfony2, as noted here: <>

I think you know that, though, seeing as you commented on that article and agreed that Symfony needs to modify its marketing langauge: <>.

> Anyway, I know you are busy releasing the first PSR-4 auto loader.

Thanks for bringing it up!

And hardly "busy"; Aura.Autoload v2 has been relasable for quite a while now, and the release process is pretty simple (one command!). I just got around to it after the holidays. Anyone not using Composer (and there are some of those folks out there) can have independent PSR-4 autoloading available now: <>

> Whatever "first" means

"First" as in "before anyone else"; hell, not just released first, but developed first too, as we can see from from the Aura.Autoload develop-2 branch history. But "first" doesn't mean "only" (and it doesn't last for long anyway ;-).

> but in your reality beta seems to be better than "in production" (see composer).

Not at all! I'm glad the Composer guys got one out too; more adoption for PSR-4 seems like a good thing to me. I'm surprised that you care, seeing as you voted against PSR-4: <!searchin/php-fig/PSR-4/php-fig/NWfyAeF7Psk/_xk2QQuCYsIJ>

> I of course have also been criticized for questioning aspects of Zend Framework.

I know that feeling; I get criticized for questioning aspects of different frameworks, too! (/me tilts head and furrows brow)

> Argh, I shouldn't even bother ..

Hey man, do what you think is right.



Paul, the link you are pointing to for me agreeing with you is about the fact that some components have mandatory dependencies. That is hardly saying that Symfony2 is not build as a component first approach.



awesome minivan *



Phil: Naw dude, didn't mean it that way - to be honest, you provide a voice of dissent, which this (the PHP) community sorely needs. Honestly, I am sick of the developer status quo that suggests we (should) only bring positive/constructive feedback to a dialog; meanwhile, most attempt to hide (thinly veiled) passive aggression with over-intellectualized arguments. Bleeeh.. people are dicks.. there's no reason we should pretend to be otherwise.



Christian: I took it as light hearted, I was kidding :)

I'll agree with that.

Posting comments after one week has been disabled.