Rasmus Lerdorf’s philosophy can be applied to almost all frameworks from any language
About a decade ago, during a Q&A session at PHP Frameworks Day, PHP creator Rasmus Lerdorf was asked a straightforward question:
“What do you think about PHP frameworks?”
His answer was equally straightforward — and intentionally provocative:
“They all suck.”
The clip circulated widely, often stripped of context and turned into a meme. But Lerdorf wasn’t trolling, and he wasn’t staging a dramatic anti-framework manifesto. His comment was rooted in a specific philosophy about how PHP works, how web applications should be structured, and how developers often over-engineer solutions.
To understand what he meant, we need to unpack both the technical and philosophical layers behind that blunt statement.
The Philosophy Behind the Provocation
Lerdorf has always approached PHP from a pragmatic angle. PHP was designed as a simple, request-driven scripting language: a request comes in, the script runs, output is generated, and everything shuts down. Clean. Stateless. Direct.
Frameworks, in his view, often add layers of abstraction that work against this simplicity.
His criticism wasn’t that frameworks are useless. It was that they frequently introduce overhead, complexity, and generalization that many applications don’t actually need.
The Core Critiques
1. Overhead on Every Request
PHP traditionally operates in a “shared nothing” model: each HTTP request is handled independently. Lerdorf’s concern was that many frameworks bootstrap large amounts of code on every request:
- Loading configuration files
- Initializing service containers
- Wiring dependency injection
- Registering middleware
- Bootstrapping ORM layers
Even if the request only needs a small portion of that machinery, it often all gets initialized anyway.
From his perspective, this means you’re paying a performance and complexity cost for capabilities you might not even use.
2. Generality at the Expense of Simplicity
Frameworks aim to solve every problem:
- MVC architecture
- Routing
- Authentication
- Templating
- ORM/database abstraction
- Caching
- CLI tooling
- Event systems
The tradeoff? They must be flexible enough to support countless use cases. That flexibility means more abstraction, more indirection, and more code paths.
Lerdorf’s underlying message:
The more generic your solution, the less optimized it is for any specific problem.
He has often encouraged using domain-specific solutions instead of generic frameworks. If you’re building a blog, for example, using a mature platform might be more sensible than assembling a custom stack from scratch.
3. Reinventing the Web Server
Another recurring theme in his talks is that frameworks sometimes replicate functionality that web servers already provide.
URL routing, for instance, is frequently handled through elaborate PHP router systems — even though servers like Apache and Nginx already support URL rewriting and dispatching.
From Lerdorf’s standpoint, that duplication can feel unnecessary. Why implement complex routing layers in PHP when the web server is already built for request dispatching?
4. Interdependency and Deep Class Trees
Frameworks tend to introduce deeply interwoven components:
- Controllers depend on services
- Services depend on containers
- Containers manage lifecycle bindings
- ORM layers abstract database access
- Middleware pipelines wrap execution
While this structure promotes consistency and maintainability in large teams, it also increases the cognitive load for smaller projects.
Lerdorf’s argument wasn’t that architecture is bad — it was that architecture should be proportional to the problem being solved.
The Context of the Time
It’s important to remember that this statement came around 2013. At that point, frameworks were still evolving rapidly. Autoloading and opcache improvements weren’t as mature. Performance tuning practices weren’t as standardized.
Since then, frameworks like Laravel and Symfony have become highly optimized and modular. Composer-based ecosystems allow developers to install only what they need. Modern PHP versions dramatically reduce overhead.
In other words, the landscape has changed — though the philosophical debate remains.
What He Probably Didn’t Mean
Lerdorf was not saying:
- “Never use frameworks.”
- “Frameworks are useless.”
- “You’re a bad developer if you use one.”
He was challenging developers to think critically:
- Are you using a framework because you need it?
- Or because everyone else does?
- Is your application truly complex enough to justify the abstraction layers?
The remark was less an insult and more a provocation.
The Broader Engineering Debate
This discussion extends far beyond PHP. It’s the classic tension in software engineering:
| Simplicity | vs | Abstraction |
|---|---|---|
| Performance | vs | Productivity |
| Custom solutions | vs | Reusable frameworks |
| Minimal overhead | vs | Standardized patterns |
Frameworks optimize for productivity and consistency.
Raw PHP scripts optimize for simplicity and directness.
Neither approach is inherently superior. The right choice depends on scale, team size, complexity, and long-term maintenance needs.
The Takeaway
When Rasmus Lerdorf said “all PHP frameworks suck,” he was articulating a deeply pragmatic stance:
- Don’t introduce abstraction unless it solves a real problem.
- Don’t pay overhead you don’t need.
- Don’t generalize prematurely.
- Keep things as simple as possible for as long as possible.
It’s less an anti-framework argument and more a reminder of a fundamental engineering principle:
Complexity should be earned, not assumed.
In that sense, the statement still resonates today. Frameworks are powerful tools — but like all tools, they’re best used intentionally, not automatically.
