Search for "Laravel vs PHP" and you'll find countless videos, blog posts and forum discussions trying to determine which one is better. Some argue that Laravel is the only sensible way to build modern PHP applications. Others insist that pure PHP is simpler, faster and gives developers more control. The conversation has been going on for years, and it doesn't seem any closer to ending.
What struck me after reading many of these discussions is that the comparison itself is slightly misleading. Laravel is written in PHP. Choosing Laravel is still choosing PHP. The real decision isn't between two competing programming languages but between two different ways of building software with the same language.
That distinction sounds obvious once it's said out loud, yet many conversations skip over it. Instead of asking whether PHP or Laravel is better, the more interesting question is when a framework genuinely makes development easier—and when adding one simply introduces another layer that may not be necessary.
While building Cordinant, I found myself thinking about this more often than I expected. The website, its custom CMS and the applications I'm developing all use plain PHP rather than Laravel. That wasn't because I believed frameworks were a bad idea. It was because, for the kind of projects I wanted to build, I preferred understanding every part of the application instead of working within someone else's architecture.
That decision also came with compromises. There were moments when I looked at features Laravel provides out of the box—authentication scaffolding, routing, queues, migrations—and wondered whether I was making life unnecessarily difficult for myself. Other times I appreciated how lightweight and predictable my own codebase remained. Neither feeling completely replaced the other.
Why This Debate Refuses to Disappear
Programming communities tend to enjoy comparisons. Editors compete with IDEs. Databases compete with other databases. JavaScript frameworks appear to compete with one another almost every year. Laravel versus pure PHP naturally became another version of the same discussion.
Part of the reason is that Laravel has grown into one of the most influential PHP frameworks ever created. Its ecosystem is extensive, its documentation is widely praised and many developers build entire businesses around it. For someone discovering PHP today, Laravel often appears almost inseparable from the language itself.
At the same time, PHP has been around for nearly three decades. Long before Laravel existed, developers were building websites, content management systems, e-commerce platforms and business applications using PHP alone. Some of those systems have continued evolving for years, while others eventually migrated to frameworks as projects became larger.
That long history means developers arrive at the conversation from very different backgrounds. Someone who started programming with Laravel may struggle to imagine writing an application without it. Someone who spent years writing custom PHP may see a framework as an additional layer they don't always need. Both perspectives make sense when viewed through personal experience.
The discussion often sounds like PHP versus Laravel, but in reality it's closer to deciding how much structure you want someone else to provide before you begin writing your own application.
What Does "Pure PHP" Actually Mean?
The phrase pure PHP can be surprisingly vague. It doesn't refer to a formal technology or a specific development style. Instead, it's generally used to describe applications built without relying on a major framework such as Laravel, Symfony or CodeIgniter.
That doesn't necessarily mean writing everything from scratch. Many developers who describe their projects as pure PHP still use Composer for dependency management, install third-party libraries, follow PSR standards and organise their code into classes and namespaces. Modern PHP development doesn't suddenly become old-fashioned simply because a framework isn't involved.
In practice, building with pure PHP often means making your own architectural decisions. You decide how routing works, how controllers are organised, how authentication behaves and how different parts of the application communicate with one another. That flexibility is attractive to some developers and unnecessarily time-consuming to others.
Choosing pure PHP doesn't mean avoiding modern development practices. Many developers still use Composer, object-oriented programming, PSR standards and external libraries while building applications without a full-stack framework.
This flexibility is also why two pure PHP projects can look completely different. One developer may build a lightweight MVC structure. Another may prefer a modular architecture. A third might create something tailored entirely to a specific product. Without a framework setting the rules, there is much more room for individual decisions.
Why I Didn't Start with Laravel
When I began building Cordinant, I wasn't trying to prove that frameworks were unnecessary. I simply wanted to understand every part of the system I was creating. Since I work independently, there isn't a team that needs to learn my architecture or contribute to the same repository. That changes the equation considerably.
Building my own CMS gradually became part of the project itself rather than a problem to eliminate. Every new feature forced me to think about routing, database design, reusable components and administration tools. Sometimes that slowed development. Sometimes it revealed problems I probably wouldn't have noticed if everything had already been solved by a framework.
I'm still not convinced there is one universally correct approach. If Cordinant eventually grows into something much larger, perhaps my opinion will change. Software has a habit of making confident decisions feel temporary. What seems like the obvious architecture today may look very different a few years later.
That uncertainty is one reason I find the Laravel versus pure PHP discussion interesting. It isn't really about technology alone. It's also about project size, personal preferences, maintenance, team structure and the kind of software someone wants to build.
Perhaps We've Been Asking the Wrong Question
Looking back, I think the most useful version of this discussion isn't "Should I use Laravel?" or "Is pure PHP better?" Those questions almost invite absolute answers that rarely exist in software development.
A more interesting place to start is understanding what each approach tries to solve. Laravel wasn't created because PHP was incapable of building applications. Pure PHP hasn't survived for decades because frameworks offer no advantages. They exist alongside each other because different projects create different kinds of problems.
Before comparing performance, productivity or long-term maintenance, it helps to understand why Laravel became so influential in the first place. That story explains far more than any benchmark chart ever could.
Why Laravel Became So Popular
It's difficult to talk about modern PHP without talking about Laravel. Even developers who have never used it are likely familiar with its name. Over the past decade, Laravel has become the framework that many people associate with PHP itself, especially those discovering the language for the first time.
That popularity wasn't accidental. Laravel appeared at a time when PHP development often felt fragmented. Different projects followed different structures, developers solved the same problems in different ways, and building common functionality usually meant writing a considerable amount of repetitive code. Laravel offered an opinionated approach that tied many of these pieces together into a coherent development experience.
Instead of starting every project with an empty directory, developers suddenly had a complete foundation. Routing, authentication, templating, database access, caching and background jobs were already designed to work together. Rather than deciding how every part of an application should be organised, much of that thinking had already been done.
Whether that is an advantage depends on the project, but it's easy to understand why so many developers appreciated having fewer architectural decisions to make before they could start building features.
A Framework That Solves Repetitive Problems
One reason Laravel became successful is that it focuses less on individual features and more on the everyday problems almost every web application eventually encounters.
Need user authentication? Laravel includes mature solutions. Building an administration panel? Routing, middleware and database models are already available. Want to queue emails or process uploads in the background? The framework provides tools for that as well. Many of these features have existed for years, have been tested by thousands of developers and continue to evolve alongside the framework.
For a developer building similar types of applications repeatedly, this can remove a remarkable amount of routine work. Instead of spending days constructing the underlying infrastructure, more time can be spent building the parts that make one application different from another.
Laravel isn't popular simply because it offers many features. Its strength comes from how those features work together using consistent conventions, documentation and tooling.
Convention Can Be Surprisingly Valuable
One aspect of frameworks that isn't discussed as often is convention. Laravel encourages developers to organise projects in a particular way. Controllers live in expected locations. Models follow predictable patterns. Configuration files have designated places. Database migrations follow established conventions.
At first glance this may seem restrictive, but consistency has practical benefits. A developer joining an unfamiliar Laravel project usually has a reasonable idea of where different parts of the application are likely to be. Documentation, tutorials and community examples also become easier to follow because everyone is speaking roughly the same architectural language.
That kind of predictability becomes increasingly valuable as projects grow and more developers become involved.
Frameworks don't just provide code. They provide shared expectations about how an application is organised.
The Ecosystem Is Bigger Than the Framework
Laravel is often described as a framework, but in practice it's closer to an ecosystem. Around the core framework sits a growing collection of official and community tools that address many common development tasks.
Developers can use Artisan for command-line automation, Eloquent for database interaction, Blade for server-side templates, Horizon for monitoring queues, Cashier for subscription billing, Sanctum for authentication and many other packages maintained by both the Laravel team and the wider community.
Not every project requires these tools, but their existence changes the economics of development. Problems that once required weeks of custom implementation may already have mature, well-documented solutions that integrate naturally with the rest of the application.
This extensive ecosystem also helps explain why Laravel appears in so many tutorials, online courses and job descriptions. When thousands of developers are building on the same foundation, educational resources naturally multiply alongside it.
Developer Experience Matters More Than Benchmarks
Framework discussions often drift towards performance benchmarks, memory usage and execution speed. Those measurements certainly have their place, but they rarely explain why developers choose one tool over another.
In many cases, the experience of building software is just as important as the speed at which the software eventually runs. If a framework helps developers organise large projects, avoid repetitive work and maintain consistency over several years, the productivity gains may outweigh the additional complexity introduced by the framework itself.
This doesn't mean Laravel is always the faster choice in terms of raw execution. A carefully written pure PHP application will generally have less framework overhead simply because there is less code involved before the application's own logic begins running. Whether that difference matters depends heavily on the project. Database queries, caching strategies, server configuration and application design often have a much greater impact on real-world performance than the framework alone.
Benchmark comparisons can be misleading when viewed in isolation. A lightweight application written in pure PHP may execute faster than an equivalent Laravel application, but overall user experience is usually influenced by many other factors, including database design, caching, infrastructure and application architecture.
Where Laravel Feels Like the Natural Choice
Reading discussions online, it's easy to find developers who use Laravel for almost every project they build. After spending time exploring the framework, I can understand why.
Applications with user accounts, dashboards, APIs, background processing, notifications, permissions and integrations quickly accumulate technical complexity. When much of that infrastructure already exists within a framework, it can become easier to focus on business logic rather than rebuilding familiar components yet again.
This is particularly true for teams. Shared conventions reduce onboarding time, make code reviews more consistent and allow developers to move between projects without learning a completely different architecture each time.
Even for solo developers, Laravel can be attractive when building products expected to grow rapidly or evolve over many years. The framework offers a stable foundation with solutions for problems that many applications eventually encounter anyway.
Yet Frameworks Also Introduce Their Own Complexity
None of this means a framework is automatically the best starting point. Every abstraction solves one problem while creating another. Learning Laravel involves learning its conventions, lifecycle, dependency injection, service providers, middleware pipeline and numerous supporting tools. That's entirely reasonable for projects that benefit from those abstractions, but it also means there is more to understand before the framework begins to feel natural.
While working on Cordinant, I occasionally looked at Laravel features with genuine curiosity. Some would almost certainly have saved time. Others would have required me to adopt patterns that weren't especially valuable for the type of application I was building.
That gradually changed how I viewed the debate. Laravel isn't popular because it magically makes PHP better. It's popular because it removes a large amount of repetitive engineering from the kinds of applications many developers build every day. Whether those are the same kinds of applications you're building is an entirely different question.
And that naturally leads to the opposite side of the discussion. If Laravel solves so many common problems, why do experienced developers continue choosing pure PHP for certain projects? The answer turns out to be more nuanced than simply preferring "less code" or "more control."
Performance Is Usually the Wrong Starting Point
Sooner or later, almost every Laravel versus pure PHP discussion reaches the same destination: performance. Benchmark charts appear. Someone measures requests per second. Another person compares memory usage. Before long, the conversation begins to sound as though the framework alone determines whether an application feels fast.
I've always found this slightly unsatisfying because most users never experience a framework in isolation. They experience an application. A slow database query, an inefficient search algorithm, an overloaded server or an API waiting for responses can all have a far greater impact than the framework itself.
That doesn't mean performance differences don't exist. They do. A lightweight application written in pure PHP generally executes less framework code before reaching its own business logic. There are simply fewer layers involved. But whether those extra milliseconds matter depends entirely on what the application is actually doing.
For a small company website or a custom administration panel serving a limited number of users, the framework is unlikely to become the primary performance bottleneck. For a high-traffic platform processing thousands of requests every minute, architectural decisions, caching strategies and infrastructure usually deserve much more attention than framework benchmarks alone.
Users rarely notice which framework generated a page. They notice whether the page feels responsive.
Performance Isn't Just About Speed
Another reason benchmark discussions become confusing is that developers often mean different things when they say "performance." Some refer to raw execution speed. Others mean developer productivity. Someone maintaining a project for five years may even define performance as how quickly new features can be added without introducing bugs.
These are all valid perspectives, but they measure completely different things.
| Type of Performance | What It Actually Measures |
|---|---|
| Runtime performance | How efficiently the application executes requests. |
| Developer productivity | How quickly features can be implemented. |
| Maintenance performance | How easily the software can evolve over time. |
| Operational performance | How simple the application is to deploy and support. |
A framework may introduce a small amount of runtime overhead while dramatically improving development speed. Equally, a lightweight custom application may execute extremely efficiently but require considerably more engineering effort whenever new functionality is added. Neither outcome is inherently better—they simply optimise different parts of the development process.
Maintenance Often Lasts Longer Than Development
When starting a new project, it's tempting to think mostly about building it. In reality, writing the first version is often the shortest phase of its life. Once software goes live, maintenance quietly becomes the dominant activity.
Features evolve. Bugs appear. Servers change. PHP versions advance. Security recommendations improve. APIs become deprecated. Software rarely stands still, even if the application itself doesn't change very much.
This is where the Laravel versus pure PHP discussion becomes much more interesting than simple performance comparisons.
Maintaining a Laravel Application
Laravel benefits from a large community and an active release cycle. Security updates, bug fixes and new features are continuously developed by the framework team and contributors. For many organisations, this is reassuring. Problems discovered by thousands of developers are often documented and resolved more quickly than they would be in a completely custom solution.
The trade-off is that frameworks continue moving forward. New major releases introduce improvements, but they may also require code changes. Dependencies need updating. Packages become deprecated. Occasionally an upgrade turns into a project of its own.
Developers who work with Laravel regularly often consider this a perfectly reasonable cost for the advantages the framework provides. Others see it as accepting an additional maintenance responsibility that wouldn't exist in a smaller custom codebase.
Maintaining a Pure PHP Application
A custom PHP application follows a different rhythm. There is no framework roadmap determining when upgrades should happen. If the codebase has few external dependencies, there may be surprisingly little pressure to make architectural changes simply because a new framework version has been released.
That independence is one reason I enjoyed building Cordinant in pure PHP. I decide how the project evolves. If I want to redesign the CMS, introduce a new routing system or reorganise the administration interface, those decisions come from the needs of the project rather than the expectations of a framework.
At the same time, that freedom also removes a safety net. Every architectural decision becomes my responsibility. If something turns out to have been poorly designed, there isn't a framework convention to blame or documentation explaining the preferred solution. The application succeeds or struggles largely because of the choices made while building it.
Building without a framework doesn't eliminate maintenance—it changes its nature. Framework maintenance often involves keeping up with ecosystem updates, while custom applications rely much more heavily on the quality of their original architecture.
The Learning Curve Depends on What You're Trying to Learn
People often ask whether Laravel is easier than pure PHP. I don't think there's a universal answer because the question itself hides another one: easier for what?
If the goal is building a modern web application quickly, Laravel can feel remarkably approachable. Documentation is extensive, tutorials are everywhere and many common problems already have established solutions. A beginner following a structured course may have a working application much sooner than someone assembling every component independently.
If the goal is understanding how web applications actually work beneath the framework, the experience is rather different. Frameworks intentionally hide complexity. That's one of their strengths. Routing, dependency injection, middleware, service containers and database abstractions all simplify development, but they also make it easier to forget how those mechanisms function underneath.
Neither learning path is more legitimate than the other. They're simply focused on different outcomes.
Frameworks often teach developers how to build applications efficiently. Writing more of the application yourself often teaches why those frameworks exist in the first place.
Which Projects Naturally Fit Pure PHP?
After building Cordinant, I realised that many of the applications I enjoy creating don't necessarily require the full capabilities of a large framework.
Custom CMS platforms, product websites, documentation systems, internal business tools and self-hosted applications often benefit from simplicity. These projects usually have clearly defined requirements, moderate traffic and a single developer responsible for most architectural decisions.
In those situations, a lightweight PHP codebase can remain surprisingly manageable. There is less abstraction to understand, fewer dependencies to update and complete freedom to organise the application around the product rather than around a framework's conventions.
- Custom business websites
- Content management systems
- Internal administration tools
- Documentation platforms
- Self-hosted software products
- Projects maintained primarily by one developer
That list isn't intended as a rule. Plenty of developers successfully build these same kinds of applications using Laravel. The point is simply that a framework isn't automatically required because a project happens to use PHP.
Where Laravel Begins to Make More Sense
There are also projects where I would probably think much more seriously about using Laravel from the beginning.
Applications with complex authentication systems, extensive APIs, background job processing, subscriptions, multiple developers and continuous feature development naturally benefit from conventions and reusable infrastructure. Rebuilding those capabilities repeatedly would be difficult to justify when mature solutions already exist.
Larger teams also change the equation. When several developers contribute to the same application, consistency often becomes more valuable than individual architectural preferences. Shared conventions reduce onboarding time and make long-term collaboration easier.
The framework isn't solving only technical problems. It's helping coordinate how people build software together.
Project Size Isn't the Only Variable
One assumption appears regularly in online discussions: small projects should always use pure PHP, while large projects should always use Laravel. Reality tends to be messier than that.
Some relatively small applications have surprisingly complicated business logic. Others serve millions of users while remaining technically straightforward. Team size, hosting environment, deployment strategy, expected lifespan and developer experience can all influence which approach feels more appropriate.
Looking back at my own work, I don't think I chose pure PHP because it's objectively superior. I chose it because it matched the way I currently enjoy building software. If I were leading a development team instead of working independently, I might very well make different architectural decisions.
That flexibility is perhaps the most useful lesson from the entire discussion. Laravel and pure PHP aren't competing philosophies that force developers into permanent camps. They're different tools shaped by different priorities. The interesting part isn't deciding which one wins. It's recognising why both continue to exist—and why experienced developers still choose each of them for entirely reasonable reasons.
Why I Chose Pure PHP for Cordinant
After everything I've written so far, this is probably the question that naturally follows. If I think Laravel is a well-designed framework with a mature ecosystem and clear advantages, why didn't I build Cordinant with it?
The simplest answer is that I wasn't looking for the fastest way to launch another website. I was building something I wanted to understand completely. Cordinant wasn't only a place to present products—it gradually became one of the products itself.
The custom CMS, product catalogue, blog, media library and administration tools all evolved together. Every time I added a feature, I learned something about the application I was creating. Sometimes the solution I implemented remained unchanged. Other times I rewrote it weeks later after discovering a better approach.
Had I started with Laravel, many of those decisions would already have been made for me. That would almost certainly have accelerated development. At the same time, I would have missed part of the process that I personally find enjoyable: designing the architecture itself.
Building the Foundation Was Part of the Project
There is an assumption that writing infrastructure yourself is always wasted effort because frameworks already solve those problems. I understand where that opinion comes from, especially in commercial environments where delivery speed is the highest priority.
My situation is a little different.
Cordinant is not a client project with a fixed deadline. It isn't maintained by a development team. It's an independent project that continues evolving whenever I decide it should. That changes how I think about the time invested in the underlying architecture.
Writing my own routing, authentication, administration interface and content management tools didn't feel like delaying the project. Those components were the project.
Sometimes the infrastructure isn't standing in the way of the product. Sometimes building the infrastructure is part of building the product.
Looking back, I don't think I would describe those months as simply "writing a website." I was gradually assembling a platform that now powers everything else I publish on Cordinant.
Complete Control Comes With Complete Responsibility
One aspect of pure PHP I appreciate is the feeling that nothing inside the application is mysterious. If I need to understand why something behaves a certain way, I can usually trace the request from beginning to end without navigating through framework internals or layers of abstraction.
That simplicity becomes valuable when returning to a project after several weeks away. Working independently means there isn't another developer to explain how a particular feature works. Future me becomes the next developer joining the project.
Of course, this has another side.
When everything is custom, every design mistake is custom as well. If I organise something poorly, there's no framework convention encouraging a better structure. If an implementation becomes difficult to maintain, the responsibility is entirely mine.
I don't necessarily see that as a disadvantage, but it does require honesty. Writing software without a framework doesn't automatically produce cleaner architecture. In some projects it can easily produce the opposite if the developer isn't careful.
Choosing pure PHP means accepting responsibility for architectural decisions that a framework would normally make on your behalf. Greater flexibility also means fewer guardrails.
There Were Moments I Questioned the Decision
It would be easy to tell a story where every architectural choice turned out to be correct. That isn't how Cordinant developed.
There were plenty of moments when I wondered whether I was making things unnecessarily difficult. While implementing user authentication, improving the CMS or restructuring parts of the administration panel, I occasionally found myself thinking, "Laravel already solved this years ago."
That thought wasn't entirely wrong.
Frameworks exist precisely because thousands of developers repeatedly encounter similar problems. Ignoring those solutions simply for the sake of writing everything yourself wouldn't make much sense.
The challenge was deciding which problems were worth solving personally and which weren't.
Interestingly, I rarely regretted building the architectural foundation myself. Most of my uncertainty came from deciding how to organise features rather than wishing a framework had made the decision instead.
Working With AI Changed the Equation Slightly
Another difference compared with developers starting projects ten years ago is that AI has become part of the development process.
While building Cordinant, I regularly used AI to discuss architecture, review code, explore alternative implementations and identify potential improvements. Sometimes it suggested genuinely useful ideas. Other times its recommendations looked convincing until I tried implementing them and discovered they didn't really fit the project.
What surprised me most wasn't that AI could generate code. It was how often reviewing its suggestions forced me to think more carefully about my own architecture.
I suspect that would have happened with Laravel as well. AI can explain framework conventions just as easily as it can discuss custom code. But because every architectural decision in Cordinant belonged to me, those conversations felt more like collaborative design reviews than code generation.
Using AI didn't remove architectural decisions. It simply made exploring different possibilities much faster. The final decisions—and responsibility for them—still remained mine.
Would I Make the Same Choice Again?
At the moment, I think I would.
Not because I believe pure PHP is objectively better than Laravel, but because it aligns with the way I currently enjoy building software. I like understanding every moving part of the applications I create. I like gradually shaping the architecture around the product rather than adapting the product to an existing framework.
That doesn't mean I'll always feel the same way.
If I were building a large SaaS platform with multiple developers, continuous deployments and dozens of integrations, my priorities would almost certainly change. In that environment, Laravel's conventions and mature ecosystem might become much more valuable than complete architectural freedom.
Software development has a habit of making absolute opinions look temporary. The more projects I build, the less interested I become in declaring one approach universally correct.
Perhaps the Better Question Is What You Want to Build
The longer I worked on Cordinant, the less I thought about choosing between Laravel and pure PHP. The framework gradually disappeared from the centre of the conversation.
Instead, I kept coming back to a different question: what kind of application am I actually trying to create?
Sometimes the answer points naturally towards a framework with years of accumulated experience behind it. Other times it points towards a smaller codebase designed specifically for one product and one developer.
Neither choice says very much about the quality of the finished software. I've seen impressive applications built with Laravel, and equally impressive ones built without it. I've also seen difficult-to-maintain projects on both sides of the debate.
Perhaps that's why I no longer find the original question especially interesting. Asking whether Laravel is better than pure PHP assumes there should be one winner. Software rarely works that way.
For Cordinant, building with pure PHP felt like the right decision because the process of creating the platform was just as valuable as the platform itself. Another project, with different goals and different constraints, might lead me somewhere else entirely.
And I suspect that's one reason this discussion has continued for so many years. The technology hasn't really been arguing with itself. Developers have simply been building very different kinds of software while trying to answer the same question.
