unknown

A PHP developer with 20 years of experience shares why they rejected Laravel, Symfony, CodeIgniter, CakePHP, and Yii for a real IoT digital signage project. The core argument: big frameworks are bloated, rely on 'magic' abstractions, enforce vendor lock-in, and are unsuitable for resource-constrained hardware like Raspberry Pi or NAS devices with 1-2 GB RAM. The author criticizes ORMs like Eloquent for unnecessary overhead, Symfony's DI container complexity, and proprietary template languages like Blade and Twig. The chosen stack — Slim4, Mustache, and curated Composer libraries — prioritizes PSR standards, minimal dependencies, and performance. The post concludes with a broader argument that developers should learn architecture and design patterns rather than outsourcing decisions to framework dictators.

Why Big PHP Frameworks Waste Your Time

Welcome to PHP Dev, a dedicated space for sharing knowledge about PHP and its ecosystem (only PHP directly related).
Help us find good articles and blogposts and provide links. Upvote or downvote, after reading, it's essential

PHP Dev

He describes framework problems valid for almost all languages.
My approach for decades now is to use the bridge pattern to wrap libraries from different vendors like Symfony, Laminas and non-framework solutions into my own interfaces and services. No third party solution ever directly touches my application code! This makes it independent from different external design choices that are often incompatible to each other or could break my app when they change. I can mix my own solutions with external ones, depending on wether I can create a “better” version for my use case, and replace external libraries without refactoring my whole code.
That’s also the reason why I don’t completely agree with the author. Especially Symfony and Laminas are highly modular frameworks with components that can be used without locking yourself in a specific framework. In other words: A vendor-lock-in free way of using freameworks.

This article is cleared so many questions and confusions i had about laravel.
The way the community is so opinionated and the “batteries included” means configure everything when scaling has been the biggest challenge.
Sometimes building from scratch is the solution or the medicine.

Feels like a classic ‘wrong tool for the job’ take.
Laravel/Symfony aren’t built for 1GB IoT devices, so yeah they’ll feel heavy. That doesn’t make them useless, just not a fit here.
Slim + small libs makes sense for your case, but that doesn’t mean big frameworks are a waste. Different tradeoffs, different contexts.

“I want to run service on IoT device with 1 GB RAM”, so ORM is pathetic. But doctrine/dbal is ok. Where did “learn the language of the database” go?
There are different requirements. If you want to run on small device - you optimize, drop ORM, you may skip adding layer on top of file system (hello league/flysystem) or use PHP instead of templating system (mustache/mustache).
I see my CEO’s face when I tell him that we need to add +X hours so I could write SQL, so we could save few MBs of RAM. Also, if you do not know SQL, you will shoot your own leg with ORM.

Is PHP really the right choice for that platform? Not that the framework criticism isn’t valid, but …