Is PHP Still Relevant in 2026? A Practical Look at Modern PHP

Every few months I come across another discussion asking whether PHP is finally finished. The wording changes slightly each time, but the idea rarely does. Someone announces that a newer language has replaced it, another person argues that nobody should start a new PHP project anymore, and before long the familiar phrase appears once again: "PHP is dead."

What I find interesting is not whether that statement is true. It's how long the discussion has survived. PHP has supposedly been dying for almost two decades, yet millions of websites still depend on it every day. New PHP applications continue to appear, hosting companies still optimise their infrastructure for it, Laravel remains one of the most active web frameworks in the world, and WordPress continues to power an enormous portion of the web.

Building Cordinant has made me think about this question more than I expected. Every line of the website—from its custom CMS to the products I sell — runs on PHP, MySQL, HTML, CSS and JavaScript. That wasn't a nostalgic decision or an attempt to prove that PHP is better than newer technologies. It simply became the language that made the most sense for the project I wanted to build.

At the same time, I don't believe PHP is the right answer for every application. Some projects genuinely benefit from Node.js, Go, Python, ASP.NET or other ecosystems. The more software I build, the less interested I become in defending a particular language and the more interested I become in understanding why different teams choose different tools.

Perhaps that's why the question itself remains worth exploring. Not because it has a simple yes-or-no answer, but because it reveals something about how developers make technology decisions—and how those decisions are often influenced as much by perception as by reality.

Why Has PHP Been "Dying" for So Long?

One curious thing about PHP is that its reputation and its real-world usage have often moved in opposite directions. During the same years that articles declared PHP obsolete, thousands of businesses quietly continued using it to build ecommerce stores, customer portals, booking systems, company websites, CRMs and internal tools.

Part of this contradiction comes from history. PHP became popular at a time when building a website was considerably more difficult than it is today. It lowered the barrier to creating dynamic pages and eventually became one of the foundations of the early web. That popularity also meant millions of inexperienced developers wrote PHP, producing code that ranged from excellent to truly terrible.

Those early examples shaped the language's reputation for years. Many developers still associate PHP with messy files containing HTML, SQL queries and business logic all mixed together. If your first encounter with PHP happened fifteen years ago, that image is understandable.

Languages rarely escape their own history. People often remember what a technology looked like years ago rather than what it has gradually become.

Meanwhile, the software industry changed. Ruby on Rails attracted attention by making web development feel elegant. Python expanded beyond web applications into data science and machine learning. JavaScript escaped the browser through Node.js, making full-stack JavaScript increasingly attractive. Go gained a reputation for simplicity and performance, while Rust became associated with safety and systems programming.

Against that backdrop, PHP rarely generated excitement. It mostly continued solving practical business problems without trying to reinvent itself every few years. That doesn't make for dramatic conference talks or viral social media discussions, but it does explain why PHP quietly remained part of so many commercial projects.

While Everyone Was Looking Elsewhere, PHP Kept Changing

One misconception that still appears surprisingly often is the idea that PHP stopped evolving. In reality, the language has changed significantly over the last decade. A developer returning from PHP 5 would find today's language noticeably different.

Performance has improved dramatically through successive PHP 7 and PHP 8 releases. Type declarations became much more capable. Attributes reduced the need for verbose annotations. Enums, constructor property promotion, readonly properties, union types and numerous quality-of-life improvements made modern PHP feel considerably more expressive than older versions.

Composer also transformed the ecosystem. Instead of every project reinventing common functionality, developers gained a standard dependency manager and access to an enormous collection of reusable libraries. Frameworks such as Laravel and Symfony helped establish consistent architectural patterns that were often missing in older PHP applications.

None of these improvements magically turned PHP into a perfect language. Every language carries historical decisions that remain visible years later. PHP is no exception. But many criticisms repeated today describe a version of PHP that no longer reflects how modern applications are actually built.

Internet Discussions and Commercial Reality Often Tell Different Stories

Browsing developer communities can create the impression that every new startup is built with the latest framework released six months ago. Reality is usually less dramatic.

Most businesses are far more interested in reliability, hiring developers, keeping maintenance costs reasonable and delivering products on time than in using whichever language happens to dominate online discussions that year.

That's one reason PHP continues to appear in places where people rarely notice it. Ecommerce platforms, agency-built websites, SaaS back offices, membership systems, booking platforms, customer dashboards and countless internal business applications continue running on PHP because they already work—and because rebuilding stable software simply to follow fashion rarely makes financial sense.

Looking at the web through that lens makes the original question feel slightly different. Instead of asking whether PHP is still relevant, a more interesting question might be why it has remained relevant despite spending so many years being described as obsolete.

Building Cordinant Changed the Way I Think About PHP

Before I started building Cordinant, I expected WordPress would become the foundation of the website. It seemed like the obvious decision. It already solved content management, user authentication, media handling, SEO and countless other problems. It powers millions of websites for good reason, and for many projects I still think it's an excellent choice.

What I didn't expect was that my own requirements would gradually drift away from what a general-purpose CMS is designed to do. Cordinant wasn't just becoming a blog or a product catalogue. It was evolving into something that combined a custom product database, documentation, SEO management, article publishing, licensing, downloads and a structure that reflected how I personally wanted to organise content.

At first I tried to imagine how those ideas could fit into WordPress. The longer I planned the project, the more I realised I was designing around the CMS instead of designing around the product itself.

Building my own CMS suddenly looked less like an ambitious experiment and more like the simpler solution.

PHP Was Never the Main Question

Interestingly, I don't remember spending much time deciding which programming language to use. That decision almost made itself.

I already knew PHP well enough to work comfortably. Shared hosting environments support it almost everywhere. Deploying applications is straightforward. MySQL integrates naturally into the workflow, and the language is specifically designed for building dynamic websites and web applications.

I wasn't trying to build a globally distributed real-time messaging platform or process millions of events per second. I was building a content-driven website and a collection of self-hosted applications for developers. PHP fit that description remarkably well.

I wasn't looking for the most fashionable technology. I was looking for the technology that would allow me to spend more time building the product than thinking about the infrastructure.

Looking back, I think that's an important distinction. Developers often discuss languages as though selecting one automatically determines whether a project succeeds. In reality, many successful products could have been built in several different languages.

Modern PHP Feels Different From the PHP Many People Remember

One reason discussions about PHP sometimes feel disconnected from reality is that people are often talking about different versions of the language.

Someone whose experience ended around PHP 5 may still picture files full of inline SQL queries, HTML mixed with business logic and large procedural scripts that became increasingly difficult to maintain.

Modern PHP development usually looks quite different. Applications are commonly organised around controllers, services, repositories, dependency injection, Composer packages and automated testing. Static analysis tools have become commonplace, and type declarations make many mistakes easier to catch before code even reaches production.

That doesn't mean every PHP project follows those practices. Plenty of older systems still exist, just as they do in almost every other language. But poor legacy code is not unique to PHP—it tends to accumulate wherever software survives for long enough.

Composer Quietly Changed the PHP Ecosystem

If I had to point to one development that fundamentally changed PHP, it probably wouldn't be a language feature at all. It would be Composer.

Before Composer became the standard dependency manager, sharing reusable code between PHP projects was inconsistent. Developers frequently copied files from one project into another or built functionality from scratch because there was no universally accepted workflow.

Composer changed that. It gave PHP something most mature ecosystems already relied on: a predictable way to manage dependencies, update packages and build applications from reusable components.

Today it's completely normal for a PHP project to depend on dozens of well-maintained open-source libraries without manually downloading a single one.

That shift doesn't attract much attention because it happened gradually. Yet it probably had a larger long-term impact than many of the individual language features introduced over the same period.

Some Criticisms Still Deserve to Be Taken Seriously

None of this means PHP is beyond criticism. It isn't.

The language carries decades of history, and some of those historical decisions still feel inconsistent. Function names haven't always followed the same conventions. Older APIs remain for backward compatibility. The standard library occasionally reveals its age in small but noticeable ways.

There is also the challenge of perception. Languages that emerge more recently often benefit from cleaner design because they can learn from mistakes made by earlier generations. PHP has had to evolve while continuing to support an enormous amount of existing software, which naturally limits how aggressively it can change.

I also think it's healthy to acknowledge that every language has trade-offs. PHP isn't trying to become the fastest systems language, the dominant AI language or the default choice for every distributed application. Expecting it to excel equally in every area misses the point.

Building Products Matters More Than Defending Languages

One thing I've noticed while working on Cordinant is how rarely the programming language becomes the hardest part of the project.

Far more time disappears into designing databases, refining interfaces, writing documentation, planning user flows, creating product pages, organising content, fixing edge cases and making hundreds of small decisions that have very little to do with PHP itself.

That's one reason I find language debates less interesting than I once did. They're important, but they're only one piece of a much larger puzzle. Once a project grows beyond a certain size, architecture, maintainability and product design usually begin to matter far more than whether the backend happens to be written in PHP, Python or Go.

Building Cordinant reinforced that idea almost every week. The biggest challenges rarely came from the language. They came from deciding what to build, not how to express it in code.

Comparing PHP With Other Popular Backend Technologies

One thing that has changed over the past decade is that choosing a backend language is no longer a decision between only two or three realistic options. A developer starting a new web application today could reasonably consider PHP, Node.js, Python, Go, ASP.NET, Ruby, Java and several others.

That abundance of choice is generally a good thing, but it also encourages endless comparisons that assume one language must eventually replace another. In practice, software development rarely works that way. Different technologies tend to become popular because they solve different kinds of problems particularly well.

Rather than asking which language is objectively better, I find it more useful to ask a simpler question: What kind of project are we trying to build?

PHP vs Node.js

PHP and Node.js are probably compared more often than almost any other backend technologies. Both are widely used for web development, but they arrived from very different directions.

PHP was designed specifically for server-side web applications. JavaScript, on the other hand, began life inside the browser before eventually expanding onto the server through Node.js. That history still shapes how each ecosystem feels today.

If I were building a collaborative application where hundreds of users constantly exchange live updates, Node.js would certainly deserve serious consideration. If I'm creating a content-driven website, a customer portal or a self-hosted application similar to those on Cordinant, PHP still feels like an extremely natural fit.

PHP vs Python

Python occupies a rather different position because web development is only one part of its ecosystem. It has become the dominant language in areas such as machine learning, scientific computing, automation and data analysis.

That breadth sometimes creates the impression that Python is automatically a better backend language. In reality, many developers choose Python because they already use it elsewhere, not because PHP is incapable of handling the web application itself.

If artificial intelligence were the centre of my application rather than a supporting feature, Python would probably move much higher up my shortlist. For websites and business applications, however, both languages remain entirely capable choices.

PHP vs Go

Go is one of the most interesting additions to the backend landscape over the past decade. It has developed a reputation for simplicity, fast compilation and efficient performance, particularly in cloud infrastructure and highly concurrent services.

Developers who enjoy minimalism often appreciate Go's deliberately small language design. At the same time, its ecosystem for traditional content management and web publishing is nowhere near as extensive as PHP's.

I can certainly imagine building parts of a large distributed platform in Go. I have a much harder time imagining that language making my own content management workflow noticeably better.

PHP vs ASP.NET

ASP.NET has long been a strong choice, particularly for organisations already invested in the Microsoft ecosystem. It integrates naturally with Azure, Visual Studio and a wide range of enterprise tools.

Many large companies successfully build substantial platforms with ASP.NET. At the same time, independent developers often find PHP easier to deploy, less expensive to host and simpler to distribute as self-hosted software.

Laravel Deserves Its Own Conversation

It almost feels impossible to discuss modern PHP without mentioning Laravel. For many developers, Laravel has become synonymous with PHP itself.

Its influence goes far beyond providing routing or database abstractions. Laravel helped establish a modern development style that feels consistent, expressive and productive. Authentication, queues, scheduling, caching, mail, testing and deployment all fit together remarkably well.

It's also one reason why some older criticisms of PHP feel increasingly outdated. Many developers entering PHP today experience Laravel long before they encounter the historical quirks that shaped the language's reputation years ago.

Interestingly, I chose not to build Cordinant with Laravel.

That wasn't because I dislike the framework. Quite the opposite. It was because I wanted complete control over every part of the architecture while creating my own CMS. Building everything myself forced me to understand every relationship between products, articles, SEO metadata, categories, media and administration screens.

Had I been building a client application or a SaaS product under tighter deadlines, Laravel would almost certainly have become a much stronger candidate.

Where PHP Continues to Be an Excellent Choice

Looking at my own projects and many commercial products I encounter, several scenarios still seem particularly well suited to PHP.

• Content-driven websites and custom CMS platforms.
• Business dashboards and administration systems.
• Self-hosted commercial applications.
• Customer portals and membership platforms.
• Booking systems and ecommerce websites.
• Developer products distributed as installable source code.

A common thread runs through all of these examples. They prioritise reliability, maintainability, mature hosting infrastructure and long-term stability over chasing the newest programming trends.

Where Another Technology Might Be the Better Choice

A balanced discussion should also recognise that PHP is not automatically the best answer simply because it works well for my projects.

If I were building a high-frequency trading platform, a machine learning system, an application centred around large-scale scientific computing or a globally distributed real-time communication platform, my technology choices would probably look very different.

Those aren't weaknesses unique to PHP—they're examples of choosing tools that align more naturally with a project's primary challenges.

Looking at software through that lens makes the discussion considerably less dramatic. Languages stop competing to become universal solutions and instead become specialised tools with different strengths, different ecosystems and different trade-offs.

That, at least, feels much closer to the reality I see while building products than many of the debates that continue to appear online.

Does AI Change the Question?

One topic that rarely appears in discussions about PHP is how much AI-assisted development has changed the way many of us write software.

I don't mean AI generating an entire application with a single prompt. My own experience has been far less dramatic and far more practical. AI has become another development tool—alongside documentation, Stack Overflow, GitHub repositories and search engines. Sometimes it helps explain an unfamiliar concept. Sometimes it suggests a cleaner implementation. Sometimes it spots a bug that I've been staring at for half an hour without noticing.

Building Cordinant would have taken considerably longer without AI. Not because AI wrote the project for me, but because it reduced the time spent switching between dozens of browser tabs looking for documentation, syntax examples or possible approaches. It became another source of ideas rather than a replacement for making technical decisions.

That experience has also changed how I think about programming languages themselves.

Years ago, learning a completely different framework or language often meant spending weeks reading documentation before becoming productive. Today, AI can shorten that learning curve considerably. It can explain unfamiliar syntax, compare approaches, generate small examples and help interpret compiler or runtime errors.

That doesn't eliminate the need to understand software architecture or debugging. If anything, those skills become more valuable. But it does make switching between technologies feel less intimidating than it once did.

AI makes it easier to learn another language. It doesn't automatically make that language the right choice for your project.

In other words, AI may reduce the cost of learning new tools, but it doesn't remove the importance of choosing tools that fit the problem you're trying to solve.

Technology Trends and Product Requirements Rarely Move at the Same Speed

Watching technology trends can sometimes create the impression that software development is constantly starting over. Every year introduces another framework, another runtime, another architecture or another promise that this time we've finally discovered the ideal way to build applications.

Real products usually evolve much more slowly.

A business that depends on an application doesn't replace it simply because another language becomes fashionable. Teams invest years refining workflows, testing edge cases, improving user experience and integrating with other systems. Those investments often matter far more than whether the backend happens to be written in PHP, Python or something else.

That's one reason so many mature technologies remain relevant long after they disappear from conference headlines. Stability is difficult to market, but businesses tend to value it highly.

Building Cordinant reinforced that idea repeatedly. Most of my time wasn't spent wondering whether I should rewrite the project in another language. It was spent designing database relationships, improving the content editor, organising products, refining SEO metadata, restructuring pages and making hundreds of decisions that visitors will probably never notice individually.

So, Is PHP Still Relevant in 2026?

After spending the last few years building both Cordinant and several self-hosted applications, my answer is fairly simple.

Yes—PHP is still relevant.

Not because it wins every benchmark, dominates every discussion or represents the future of every kind of software development. It doesn't.

It's relevant because it continues solving real problems for real projects. It remains supported by an enormous ecosystem, benefits from decades of accumulated knowledge, runs on virtually every hosting platform and continues evolving without abandoning the millions of applications that already depend on it.

At the same time, I wouldn't recommend PHP simply because it's familiar to me. There are projects where Node.js, Python, Go, ASP.NET or another technology will almost certainly be a better fit. Ignoring those strengths would be just as misleading as pretending PHP has become obsolete.

Looking Beyond the Language

The longer I spend building software, the less convinced I become that there is a universally correct technology stack.

Languages matter. Frameworks matter. Performance matters. But they are only part of a much larger picture. Every successful product is shaped by countless decisions that have nothing to do with syntax: understanding users, simplifying workflows, organising information, writing documentation, fixing small frustrations and gradually improving something over time.

When I started building Cordinant, I thought I was choosing a programming language. Looking back, I think I was really choosing a workflow that matched the kind of products I wanted to create.

Perhaps that's why the question "Is PHP still relevant?" has never felt quite as interesting to me as another one.

Does this technology help me build the product I actually want to build?

For Cordinant, the answer has consistently been yes. For someone else's project, it might be something entirely different. And perhaps that's exactly how technology decisions should work.