When PHP Framework Sucks Series: How not to shape your app in the shape of the framework

Damnjan Jovanovic on December 26, 2018

Intro Below is an image I used on my presentation named "When PHP Framework Sucks" when I tried to explain what is happening when you ... [Read Full]
markdown guide

That is so right at so many levels: When I was a youngy PHP developper, I discovered Laravel and everything lightened up in my head. I was so happy to be so productive (at the time, Laravel just went 5.0). And then, they released 5.5, and removed support for PHP 5.6 (which is a great thing I guess), but then changed their folder structure at Laravel 5.3, and so on... So many breaking changes. Then I watched this talk when Rasmus talks about framework fatigue and say that nowadays, framework are so inclusive, you get to build an API, but you also have Queue Jobs, Mailers, View engine, ...

I think like you guys, I come up to a point when I need to step back and choose my tools and not my framework (maybe PhalconPHP is the answer, maybe Symfony Flex, or something more brutal like composing our own framework).

And then you talked about DDD, and I wanted to know if you have good resources to start with (maybe on dev.to?).



you get to build an API, but you also have Queue Jobs, Mailers, View engine, ...

I don't see your point. You get all those things with PHP. Did you ever program with PHP? I suggest giving it a try. It's one of the best things around for web development.

PHP is almost certainly among to top 3 for server side web development. Don't let figures fool you, PHP is a framework for webdevelopment where as many statistics overstate other languages by displaying their frequency of use in other domains. PHP is a DSL.

PHP and derivatives are used by the biggest web services in the world such as Google, Facebook, Wikipedia and Yahoo.

PHP is an awesome framework. You can pretty much do anything with it, you don't need any other framework.


You should check out the fat free framework. Chances are that you'll like the minimalist approach.


Nearly every php application I work on as a contractor is badly written. The main problem is that developers don't understand the model part of mvc. They put the logic in the controller or overload the DI because they dont know what a design pattern is. The hard part is explaining this to a client who has spent thousands developing a brick


Maybe there is a problem with structuring web apps that way, if a majority of programmers don't understand how to do it.

MVC was invented for graphical user interfaces in the xerox days and dependency injection is handling dependencies in the opposite way that most programming languages are designed.

...and all of this, on a language that was meant to be a template engine.


I don't get to call the shots always, but I'm beginning to realize I need to move away from framework hell. For instance, Laravel 5.7 suddenly decided to change the directory structure of asset files for no apparent reason. Same goes for Symfony 3/4, which was a major break. I'm going to experiment with doing a small personal project in Slim Framework and add components as needed. If all goes well, I'm going to create a cookie-cutter for my projects and say goodbye to frameworks in general.


I have been using an approx ~1000 line framework i've written, and for years haven't found a good reason to switch to anything else, every time i've looked.

There is always a lot to learn, which doesn't match up to the base language i've been working on for a decade. The syntax is always longer. There's always a requirement for more layers of abstraction than i'd like to deal with, for performance reasons and code comprehensibility reasons.

I've been trying to understand why frameworks are so great for many years. I'm convinced that they are just a fancy way to get everyone to code roughly the same in a language that gives you an ungodly amount of freedom.


Weird example there though, that change in Laravel 5.7 doesn't really affect anything whether you upgrade your older app or make a new one, why would that in particular set you on this path?


No, not this in particular, though it did make me vomit that there was so much chest-thumping and ceremony about this useless change. Being tied to a framework is very bad from a business perspective: imagine having built a large Laravel 4 app. Today a lot of their efforts would be going in "upgrading". Same for Symfony 3/4. I mean, I understand that framework authors realize their mistakes and correct them, but often these changes tend to be too expensive.

The problem, of course, is that thanks to excessive marketing, frameworks are embedded deep within our psyche. Consulting businesses must recommend them with glowing praise (because they help save time), job aspirants can feel good about adding a new (shallow) skill set, and everyone feels like there's on the top of the world.

This merits a full discussion of its own, but I don't have the energy for it. The bottom line is that after a point, a developer feels restricted by a framework and may want to structure things his way. If I ever get the freedom to do that, I'll avoid all of the full stack frameworks.


The kind of enthusiasm i see around Laravel kinda reminds me of how Apple products are thought of.

Maybe i don't see it, and Laravel is really freakin' good and i'm really dense..


Couldn't agree more myself (although I am a Node dev). I always create a *-core using DI, *-services and *-frontend package to combat this. Also, using Node, that enables you to use the functionality on the frontend with 0 adaption, which is awesome!


You're right about Zend 1 to 2 migrations. I maintain a Zend 1 application at work which when I inherited it, had most of the functionality stuffed into fat controllers, and while I have improved the situation it's going to take an awful lot of work to migrate it away from Zend 1. I expect it will be years before it can be fully migrated.


I'm not a fan of this idea after seeing it implemented in several projects for several years. I've seen projects not being developed to their full potential just because people spent an absurd amount of time trying to keep themselves away from the Framework.

If the Business is expecting the application to grow and they do not want to be tied to a specific Framework, it's better for them to create their own framework in the first place... one that they can control, that's able to grow with the requirements.

Bear in mind that most of the times there is just not enough time or resources to make the perfect architecture from scratch. That's when you want to use a Framework. You let the Framework make standards and take the decisions on how your code should be structured. Only when you recognize this and start to code following the Framework Conventions, you will be truly reaping the benefits of the Framework.

When you find the troubles that you're speaking about (painful migration), I believe it's more related to the way you make your own code than the Framework itself. This post in Reddit explains it better.



Basics versions of many php frameworks like symfony, cakephp etc have short life cycles and when release major version upgrade they will have breaking changes that make migration hard. If you have write well documented code, you make continues refactoring in codebase and make use of long life cycle frameworks it's ok.


I agree completely about keeping the business logic separate from the tools layer. I'll go one step further; if you want to ensure the site is maintainable I would avoid using any 3rd generation language for the customer-facing part of the site code, as it's always complicated to pick up a project years down the road. Think of something along the lines of SQL instead. I am a passionate believer in the power of DSLs to act as the bridge between human and machine. And if anyone thinks this is impractical, let me assure you it's quite easy to write a competent DSL. I've built them in Java and in JavaScript and I would never claim to be the sharpest tool in the box.


In my experience:
I tried to use Laravel and it adds +60 dependencies for a simple hello world. Are you **** kidding me?.
Now, I am working on a huge project. It has less than 15 dependencies.


Well.. i guess you didn't heard of symfony :-D


Quite opposite, I work with Symfony on a daily basis. Why do you have such an impression?

code of conduct - report abuse