Why I Built the First Procedural MVC PHP Framework in 2026

Danny Mbanginu — Mon, 01 Jun 2026 19:54:19 +0000

Why I Built the First Procedural MVC PHP Framework in 2026

NoClass is a modern MVC (Model-View-Controller) PHP framework built around procedural application development rather than application classes. To the best of my knowledge, it is the first procedural MVC framework of its kind, designed to provide the structure, features, and scalability developers expect from a modern framework without requiring a class-centric architecture.

If you had told me ten years ago that I would build a PHP framework that deliberately avoids application classes, I probably would have laughed.

After all, modern PHP development has become almost synonymous with object-oriented programming. Laravel, Symfony, and most other popular frameworks revolve around classes, dependency injection, service containers, facades, repositories, traits, and countless other abstractions.

For many developers, that's simply how PHP is supposed to be written.

Yet in 2026, after spending nearly two years building and refining a framework that started as an idea in 2024, I found myself asking a simple question:

What problem are all these abstractions actually solving for the projects I build every day?

The answer surprised me.

It Started With Frustration

Over the years I've built numerous applications, from content systems and business tools to streaming platforms and educational software.

Like many PHP developers, I used various frameworks along the way.

What I noticed was that as frameworks became more sophisticated, they also became more complicated.

Simple tasks often required navigating through:

Controllers
Services
Repositories
Interfaces
Dependency injection containers
Providers
Configuration layers

Sometimes it felt like I was spending more time satisfying the framework than solving the business problem.

A simple database query could end up passing through multiple layers before reaching the database.

A simple route could involve several files and abstractions.

I began to wonder:

Have we confused complexity with architecture?

The Forgotten Strength of PHP

PHP became popular because it was approachable.

You could open a file, write some code, refresh the browser, and see results immediately.Many developers learned programming because PHP lowered the barrier to entry.

Somewhere along the journey, the industry began treating procedural programming as something that needed to be escaped from.Object-oriented programming became the default answer to almost every problem.But procedural programming never disappeared.

The PHP interpreter itself still executes procedural code.

Countless successful applications continue to use procedural approaches internally.

The question was never whether procedural code works.

The question was whether procedural code could still form the foundation of a modern MVC framework.

I believed it could.

Building NoClass

That belief eventually became NoClass.

The project actually began in 2024 as an experiment. At first, I simply wanted to see how far I could push a procedural architecture while still providing the conveniences developers expect from a modern framework.

What started as a curiosity gradually evolved into something much bigger.

The idea was straightforward:

What if we built a modern MVC framework while keeping application code procedural?

As development progressed, it became clear that NoClass was exploring territory that few, if any, frameworks had seriously pursued: a fully featured MVC framework that embraces procedural application development instead of building everything around classes.

Not because classes are bad.

Not because object-oriented programming is wrong.

But because many projects simply don't need that level of abstraction.

Instead of this:

$userRepository->findById($id);

Why not this?

user_find($id);

Instead of navigating through multiple service layers, why not call a function that performs the task directly?

Instead of tracing dependency injection chains, why not have an explicit execution path that can be understood immediately?

The result was a framework where application code remains procedural, but developers still get the features they expect from modern development.

Modern Features Still Matter

NoClass is not an attempt to return to PHP from 2003.

It includes:

MVC architecture
Routing
Middleware
Security helpers
Database abstraction helpers
Asset management
HMVC modules
Service registration
Composer integration
Caching support

The goal was never to remove modern features.

The goal was to remove unnecessary complexity.

Those are very different things.

Caching is a good example. Performance matters in modern applications, but implementing caching shouldn't require navigating a maze of services and abstractions. NoClass provides straightforward caching capabilities that fit naturally into a procedural workflow while still helping applications scale efficiently.

The Predictable Criticism

Whenever developers hear "procedural PHP framework," certain criticisms appear almost immediately.

"Procedural code doesn't scale."

Large systems scaled long before dependency injection containers existed.

What matters is organisation, consistency, and architecture.

NoClass supports modular development through HMVC-style modules, allowing applications to be separated into manageable units.

Combined with built-in caching support, applications can remain both simple and performant as they grow.

"OOP is more maintainable."

Sometimes.

Sometimes not.

I've seen beautifully designed object-oriented systems.

I've also seen enterprise codebases where a simple feature required modifications across ten different classes.

Maintainability comes from clarity, not from a specific programming paradigm.

"This goes against modern PHP."

Perhaps.

But "modern" should not mean "only one way." The strength of PHP has always been flexibility.The ecosystem benefits from different approaches, not fewer.

Who Is NoClass For?

NoClass is not trying to replace Laravel.

Laravel is an excellent framework.

Symfony is an excellent framework.

Many object-oriented frameworks solve problems extremely well.

NoClass exists for developers who want something different.

Developers who value:

Explicit execution flow
Simplicity
Transparency
Smaller codebases
Reduced abstraction
Procedural development

It is particularly attractive for:

Small to medium business applications
Educational projects
Rapid development
Teams that prefer native PHP
Developers transitioning from vanilla PHP

The Bigger Goal

The real goal of NoClass is not to convince everyone to abandon object-oriented programming.

That would be unrealistic and unnecessary.The goal is to challenge an assumption.The assumption that modern software development automatically requires ever-increasing layers of abstraction.

Sometimes a function is enough.

Sometimes a controller, a model, and a view are enough.

Sometimes clarity is more valuable than cleverness.

NoClass is an experiment built around that belief.Whether it becomes widely adopted is ultimately up to the community.But I believe the PHP ecosystem is healthier when developers have genuine architectural choices.

Object-oriented frameworks already exist.

Micro-frameworks already exist.

NoClass explores a different path as a procedural MVC framework.

And judging by the conversations it has already started, it seems many developers have been asking the same questions I was.

Final Thoughts

Building NoClass wasn't about rejecting modern PHP.

It was about re-examining some of the assumptions we've accumulated over the years.

The framework isn't trying to win a war against object-oriented programming.

It's trying to demonstrate that procedural PHP still has a place in modern web development.

It is also an attempt to prove that a modern MVC framework does not have to be built around application classes to provide structure, maintainability, and scalability. In that sense, NoClass represents a different architectural direction and, to the best of my knowledge, the first framework of its kind within the PHP MVC ecosystem.

The fact that the project started in 2024 and continued evolving through 2026 also taught me something important: simplicity is much harder to achieve than complexity. Removing layers requires far more thought than adding them.

That philosophy extends to every feature in the framework, including performance-focused capabilities like caching. Modern applications need speed, but achieving that speed shouldn't require sacrificing clarity or introducing unnecessary architectural complexity.

If you're interested in the technical reasoning behind NoClass, including its architectural principles, intended use cases, performance features, and position within the PHP ecosystem, you can read the full NoClass white paper here.

If nothing else, I hope NoClass encourages more discussion about simplicity, maintainability, performance, and the trade-offs we make when designing software.

Because sometimes the most interesting innovations don't come from adding more layers.

Sometimes they come from removing them.

Website: https://noclass.org

White Paper: https://noclass.org/whitepaper

GitHub: https://github.com/noclassphp/noclass

DEV Community: Danny Mbanginu

Why I Built the First Procedural MVC PHP Framework in 2026

Why I Built the First Procedural MVC PHP Framework in 2026

It Started With Frustration

The Forgotten Strength of PHP

Building NoClass

Modern Features Still Matter

The Predictable Criticism

"Procedural code doesn't scale."

"OOP is more maintainable."

"This goes against modern PHP."

Who Is NoClass For?

The Bigger Goal

Final Thoughts