Coming back to Drupal after years away, while working primarily as a frontend developer in the long-established React ecosystem with TypeScript and its surrounding tech stack, a natural question emerged: does starting new projects on Drupal in 2026 still make sense?
To answer that, let’s briefly recap how the modern frontend (JS) plus backend (JS/Python) stack became so popular in the first place. You can look at this from many angles, but let’s focus on the web developer’s perspective, across a broader time span, and considering the most dominant trends.
In a web world once dominated by PHP, Python began gaining traction, along with frameworks like Django, offering better developer experience and performance. The Python ecosystem still provided a theming layer, an administrative dashboard for content management, and at the same time building API endpoints for business logic has become easier than ever.
At the same time, UI requirements for web applications were increasing. Code running in the browser needed to become more reactive and asynchronous, and vanilla JavaScript, along with jQuery and AJAX, started to feel insufficient. This led to the rise of SPA (Single Page Application) architectures. The server returned a simple index.html entry point, and the actual structure was injected and managed in the browser using JavaScript, which also handled routing. JS fetched data from the server via API endpoints, typically written in Python or JavaScript. The growth of SPAs further boosted the popularity of Node.js. Writing backend and frontend in the same language felt like a logical step.
The separation of frontend and backend became cleaner and more popular than ever, eventually turning into an industry standard. Job boards filled up with roles specialized in one side or the other. Clear role separation made specialization practical, while the process of building web applications became progressively easier.
Popularity, however, brought problems. SPA platforms were effectively invisible to SEO. Google and other search engines saw only an empty, unpopulated
This was unacceptable for sales-driven, commerce, publishing, and other industries heavily dependent on search traffic. A large market pushed for a solution, and that’s how SSR (Server Side Rendering) frameworks like Next.js emerged. They enabled libraries such as React to generate fully rendered HTML on the server, making pages visible to search engines that could not execute JavaScript.
Wait… wasn’t this exactly what PHP provided out of the box?
That question crossed many minds. Yes, we completed a full circle. A technology designed to render in the browser ended up rendering on the server again. And this is where the question of returning to Drupal becomes essential. PHP delivers fully rendered HTML directly from the server, which is why classic solutions like Drupal, WordPress, and Joomla still hold a stable position in the market.
As the meme goes:
1995: PHP is dead, learn ColdFusion
2002: PHP is dead, learn ASP.NET
2003: PHP is dead, learn Django
2004: PHP is dead, learn Ruby on Rails
2010: PHP is dead, learn Flask
2011: PHP is dead, learn AngularJS
2016: PHP is dead, learn Next.js
2022: PHP is dead, learn Go
2026: Okay, this is weird
But Who Still Cares About SEO?
One could argue that hardly anyone uses search engines anymore. In the age of ChatGPT, we don’t open Google, we start a new chat.
The thing is, LLMs (Large Language Models), when referencing their data sources, “see” websites in a way similar to search engines. They cannot render JavaScript or simulate a user. They only see raw structure. The difference is that LLMs focus less on classic HTML markup structure (headings, paragraphs, core SEO patterns) and more on semantic structure and relationships between content. This is where the emerging field of LLMO (Large Language Model Optimization) comes in.
So server-side rendering still matters, whether we are talking about SEO or LLMO.
Which brings us to another key point: data modeling and content management.
How We Think About Backend Today vs CMS Platforms
When discussing changes in web development, it’s impossible to ignore how approaches to data storage and editing have evolved, a topic traditionally associated with backend development.
During the era of PHP dominance and a less defined frontend/backend split, you would install a CMS on your own server. It gave you a theming layer, an admin UI for creating and editing content, and a complete built-in system for data modeling and database handling, what we would now call an ORM (Object-Relational Mapping). Using standardized tools, you could define content types, lists, and views, sometimes without touching code at all. This had obvious downsides, but it was fast and convenient. The platform lived as a monolith, hosted on a simple LAMP Stack server, and made building a backend relatively easy, which was especially attractive for prototyping and MVPs.
Today, you design an application, build a React frontend, and then face the question: what’s next? Where does the data come from? A custom backend in Node.js or FastAPI means a lot of code. Many developers want to avoid that, often for good reason. Sometimes it’s overkill, using a cannon to kill a fly. The alternative becomes a headless CMS provided by an external vendor, exposing a ready-made API you can plug into your frontend.
Examples include Strapi, Contentful, Sanity, Prismic, or Airtable. They offer exactly what PHP CMSs have always offered: built-in data modeling with a click-based schema editor, file storage for images and assets, and a simple admin panel for content management.
You can set up exactly this with Drupal. A headless Drupal approach, combined with the jsonapi module, allows you to define content models, enjoy a solid editorial experience, and expose full CRUD API endpoints. On top of that, you get access to a vast ecosystem of secure, community-maintained modules. This is where Drupal stands out compared to other PHP platforms like WordPress or Joomla. Drupal is an enterprise-grade solution.
You used to own your CMS. Now you pay for a headless CMS and call it progress.
So, When Should You Use Drupal?
To sum up, there are many areas where modern stack solutions clearly outperform Drupal. They represent evolution and refinement, especially for highly interactive applications with complex backend business logic. A backend written in Python or JavaScript will usually outperform a headless Drupal setup with Node API, although once you introduce proper caching layers like Redis, the gap becomes much smaller.
That said, the modern frontend plus backend stack, driven by popularity, has expanded into areas where it solves problems that were already solved long ago, while introducing new ones. These areas include marketing platforms, commerce, landing pages, and publishing platforms, anywhere the primary value is publicly accessible content.
This is where PHP and Drupal still shine.
I’ve prepared a table with example scenarios as a map showing where you can gain the most from using Drupal and where it may not be the best choice:
| Scenario | Problematics | Result |
|---|---|---|
| Company website / Marketing page | Need of CMS and good SEO/LLMO | Use Drupal |
| Publishing platform / eCommerce platform | Need of CMS, commerce features and good SEO/LLMO | Drupal saves your money |
| Content based startup / Content based SaaS platform | Need of reliable API, rapid backend prototyping and building, dynamic UI, most of screens requires user authentication | Go Headless Drupal with React SPA |
| Web application with complex data logic | Need of a very custom backend with heavy data processing logic, dynamic UI, usage requires user login | Use React Frontend + Node.js/Python Backend stack |
| Dashboard application | Custom data processing logic, dynamic UI, entire app hidden under user authentication anyway, being invisible for SEO. | Perfect use case for React SPA and Node.js/Python Backend stack |
I hope that whether you are a product owner or a developer, this article helps clarify where Drupal fits today in the wider web development landscape. If you share similar thoughts or have a different perspective, feel free to reach me out or leave a comment wherever this article is published. It will encourage me to write more. Thanks!