Same with joomla I guess[1]? What I have done in the past with Joomla 3 has now become Hugo static site only. It is so much better for my use case. No one I know needs a full-blown cms. Selling people that they can edit their own website largely fell flat, because they paid me to do it in the end every time. Also, Joomla needed an update every month or so because of security issues was bad because often plugins would randomly break.
Joomla and Drupal both have their strong points, but nowadays most people will just install WordPress with a 1-click installer and add some plugin/theme that does whatever WordPress doesn't do out of the box.
It's nothing new and both project will stay alive, although with minimal updates. I mean, phpFusion is still alive after all these years -- just with a much smaller user base.
Eventually, I suspect, WordPress will go the same way and we'll have another shiny hammer, that makes every problem look like a nail.
While I would argue Drupal may be dying, Joomla is truly dead. I don't know a single remaining Joomla consulting agency that has more than 1 employee. At least full-time Drupal shops are still a thing.
I think there are fair points/questions raised in this piece, but some of them don't really make sense or there are a few gaping contradictions:
- Drupal is also moving towards no/low code (albeit in a slower way, as is always the way with Drupal). Layout Builder is in core and is getting steadily better. Acquia has its own Site Studio solution for this (wether or not that is a good thing for the project is certainly debatable).
- I agree that Drupal does too much and there are probably too many slightly different (maybe even conflicting) ways of doing any given thing. Arguing this is bad makes no sense to me. Yes, you need to make the right choices when deciding what to go with, but this is true for every ecosystem and for the same reasons. How many different FE/JS frameworks does one have to be proficient with these days? Everyone in every field has chosen the losing horse at some point and that will continue to happen everywhere.
- Using Drupal 7 content-type editing UI screenshots in June 2022 to illustrate how "bad" Drupal is in 2022 is simply dishonest.
- Most of the 3rd party service providers (Mailchimp, Typeform, Disqus) listed as better alternatives to what Drupal offers also have integrations with Drupal. Not sure what the point here is; refer to the 2nd point I made above.
- I do agree with the point about finding talent to work on/with PHP and Drupal specifically - but how is this different from any other technology? There's always talent shortage in any given field for a varying degree of reasons. This is just PHP-shaming. Also, why would he care about developer talent/proficiency with other technology if at the end of the day he recommends building sites with a SaaS? That's for site-builders, not developers.
- Is a Google trends graph for Drupal an argument? At most I think it would be fair to assume Drupal is probably a known-quantity in the agency space and doesn't grab much headline-space nowadays also because of that. I agree you're probably better off using a SaaS alternative if what you're building is a simple CMS-type website for smaller clients. The adoption of Drupal by bigger (ie, enterprise-level) clients is what I've been personally witnessing for the last 4+ years.
Hi rantmode ! I wrote the article shared above. Let me answer your points.
1. Drupal Layout Builder > Indeed. The problem lays deep in Drupal's modular architecture, making it almost impossible to create a simple (in terms of UX) page builder with Drupal. I do not see Drupal fighting with Webflow, WeWeb or any other page builder there. Drupal ingest too much complexity.
2. Using Drupal 7 UI screenshots > I confess, clickbait on my side. Drupal 10 UI with tons of modules is still way more complicated to use than Content Stack.
3. The point about Drupal modules is not the same as for FE/JS Frameworks. The audience is not the same. On one side we have end-users that will prefer the simplicity of Mailchimp vs Simple News module. So what you're saying is that there is no point, as Mailchimp is integrated with Drupal. I'm returning you the question, if almost each module in Drupal is worse than it's SaaS equivalent, and you simply integrate Drupal with it, why using Drupal at all? At the end if your Drupal is only a content storage with CRUD, you have hundreds of better solutions (Hygraph, Xano, Content Stack, Prepr, etc...)
4. On ressources shortage. It's very different. A good PHP developer is not a good Drupal developer. Drupal's Learning curve is steep. But when you use any SaaS headless CMS you don't have to know it's internals. You simply build your front-end in any framework you're familiar with and connect it through GraphQL. Therefore any front-end developer will be ok, while with Drupal you'll need to specifically loook for experienced Drupal developer.
5. Google trends is not an argument, I regret that slippery slope I've taken. You can spank me.
I'm getting the feeling that your opinions (such as mine) come from dealing with many of the issues you've encountered when working with Drupal.
My opinion is it's far from being perfect, but is much better now than it was with Drupal 7.
If page building is all you want a CMS for, you're right: Drupal isn't for you; there are better alternatives. Doesn't mean it's dying.
Having the possibility of integrating with 3rd party services via installing a module is better than having to wire up your product/codebase to work with it. Many SaaS services also offer this, Drupal is not different.
I agree that a PHP Dev isn't a Drupal Dev and vice-versa (even though there's a very significant overlap). The learning curve for Drupal isn't steep if you only focus on learning what any of the simpler SaaS CMSs you mentioned offer. I argue it might even be lower and better documented. It does get steeper when you have to develop for Drupal - but then again, that's not something you can or have to do for a SaaS. Those products have learning curves of their own as well.
I've used Webflow before and liked it, but when the client started asking for some custom stuff, Webflow couldn't cut it either. Every tool has its limitations.
I have worked with Drupal as a backend with REST APIs for exposing data in multiple frontends and the experience was fine - probably not ideal and yes, it did require Drupal knowledge - but not different of what you'd expect trying to wire a FE app to consume/use JSON/GraphQL (which, by the way, is making its way into Drupal, too) from any other source.
Also, there's a significant point that neither of us has addressed, that I think is worth mentioning: what happens if/when one of those hot SaaS products goes bust because it didn't gain traction? Do you own the codebase? Can you quickly and simply migrate to another platform? Can you host it yourself? My guess is you're back to the same kind of predicaments you'd find in Drupal all the same. With the added bonus of now also having to find someone with experience and expertise to help migrate away from that even "nichier" product - might prove even harder to find talent than with Drupal.
I understand the complaints about Drupal, but it's all rather relative. Drupal is a glass that's 25% full. If you concentrate on the missing 75%, well, you'll just complain. But the 25% has been great for my projects. It's been a good foundation. I can usually find a module that does much of what I need and then I just jump in and help.
This kind of "X is dying" is just mean and negative.
I ditched Drupal for a Node.js based setup during the 7 to 8 migration. The writing of Drupal's decline was on the wall at that time and in hindsight switching was a good decision.
People who are ranting about PHP should know that it still powers a significant portion of the internet. The nodejs, deno and bun are an evolving space. If you want to take that train, that is definitely a good idea as it is HOT and popular now. But not everyone wants to you know.
PHP is one of those "boring technologies". Mature, slow paced and reliable tech. It has fixed a lot of the real issues which made it a meme language. If you are writing JS in the front, PHP is very similar and easy to pick up.
For people who are looking for a more mature and slow moving area, they could just fall back to PHP. Or try Laravel which adds some hotness to it.
According to metric information at (https://w3techs.com/technologies/details/pl-php), about 80% of the known public internet where we know the back-end language uses PHP. About 25% of the internet is WordPress. So... ~55% of the internet is PHP non-WordPress. These aren't the best numbers but try to disprove them.
The where we know the backend language qualifier is doing a lot of work there. According to those statistics Scala is ahead of Javascript, Python is at 1% and behind both.
I'm not sure I have a better idea on how to measure that, but the numbers don't really add up...
But PHP is on the decline. Its only hanging on barely because of wordpress.
Let me explain.
The web changed. The web evolved. Too fast for PHP to catch up, and fundamentally the web today is not compatible with the PHP way of exec + die immediately.
The web is more and more real time, all sorts of events fired thru sockets, work queues, and state is stored both on the client and on the server. PHP is not up for this task. This is why people have been moving away from PHP for the last decade, and this will only increase as time goes by.
Finally, please dont even start with that "nodejs clone in PHP" as its just a hack. If you use a node-js clone (there are many options) built in PHP you cant use any of the core stdlib, as its all blocking by nature, so for me and many others its a non starter.
PHP did a good job in evolving the web. Late 90s and early 2000s websites was the start, now its time to use better tech and continue forward.
Thanks PHP, but your time is up, its now time to say good-bye!
Modern PHP frameworks work around the issue where the web server directly executes PHP files targeted by the request URL. They also provide nice abstractions that are battle-tested and secure.
PHP is not my cup of tea (I can't be productive with the unintuitive function naming) but with a modern framework it can be proper. Laravel for example gives you a Django/Rails equivalent including task queues/etc, and becomes immune to the dumb vulnerability of uploading malicious PHP files in the media folder since all requests are routed through a single entry point rather than having the web server directly execute the PHP file.
This does not matter. PHP always starts, then exists immediately. This means you cant run something trivial as a websocket server in traditional PHP.
I know theres some caching, but each request needs "the entire state" of the PHP app, and some frameworks like laravel or symfony are huge, and this is clearly visible when you notice how poor PHP performance is in basic req/sec benchmarks.
WordPress is 25% of the internet. However, according to public metrics (https://w3techs.com/technologies/details/pl-php), almost 80% of websites with known server-side programming language use PHP.
PHP being only WordPress? Laughable. PHP dying? Also laughable. PHP is the choice for everybody but FAANG and Silicon Valley startups. But not even all of them - Facebook, Wikipedia, P*nHub, Slack, MailChimp, Tumblr, Etsy, all PHP or Hack (a stricter variant, diverging over time). (Yes, Slack is PHP, not Node!)
> The web is more and more real time, all sorts of events fired thru sockets, work queues, and state is stored both on the client and on the server. PHP is not up for this task
Go visit Slack then. They are literally built on PHP, and later moved to Hack, Facebook's stricter-typed PHP because Facebook was as well. If Slack doesn't need "all sorts of events fired thru sockets, work queues, and state" I don't know what does, and yet PHP is their foundation. They're fine, and PHP is fine.
I would not trust those metrics you showed. Its almost impossible to get real numbers. But one fact is certain, wordpress is almost the entirety of PHP out there. Facebook tried to patch PHP twice, first with HHVM, then with Hack. Finally they gave up and announced Hack will be "its own language" because they were so fed up with the inconsistencies.
Slack is really just a chat. A glorified, slow version of IRC. I would not boast it as a marvel of engineering. If you want to se how to build a good and scalable chat system? See Whatsapp.
Dont get me wrong, PHP is still used, and will be after 10-20 years. But the fact reamins that is on a slow decline. Its never going to be as popular as it was back in the early 2000s.
Is it? That has been discussed here at every PHP release, recently with 8.1. PHP is getting the job done, runs everywhere, is fast and it becomes more safe with every release. There are modern frameworks like Symfony and Laravel (also take a look at PHP application servers Swoole or Roadrunner). You can even run a version of serverless Laravel, if you like (https://vapor.laravel.com/).
For realtime there is Laravel Broadcasting that can use services like Pusher or self-hosted alternatives like Soketi. Symfony supports Mercure.
For starters a simple websocket server cant be built in traditional PHP. It will need some sort of hack like reactphp, and then you throw out all the stdlib i/o functionality.
In 2022 (soon 2023) "it runs everywhere" does not matter. Who deploys on a shared hosting service anymore? I did not even know they existed anymore. With docker you can deploy any kind of exotic stack and "it will just work".
PHP is not fast, a stock Laravel/Symfony app has poor req/sec benchmarks compared to almost anything else out there. Also the language still has all the warts it did in PHP5. Eg array_map/filter etc param order, no real unicode support, poor namespacing etc etc. Its just an overall bad development experience.
Oh, well, so it's declining according to Github stats. So is Ruby in this ranking. I like Python (which is ascending) but I don't think it's "better" than PHP according to whatever metric. Hey, I even like Java; Javascript not so much, not to talk about the ecosystem that comes with it.
PHP/Symfony/Drupal and everything is else bananas because of EOL.
You are dealing with a stack where every 2 years one subsystem goes EOL.
Drupal 6 & 7 have lasted that long because Drupal didn't have to depend on anything except PHP.
Build on a set of always EOL'd subsystems and you get developer burn out, endless budget requests and justifications for maintenance, upgrades, endless obsolescence etc.
Drupal has failed primarily because lack of leadership. Drupal has always been its community, and with so many contributors switching the community to a different language would not have been difficult. The underlying model and the fit for the language is all that would have mattered.
In the early days of PHP one Buytaert (not Dries) said Drupal should be switched to LISP, and given how stable LISP has been over the years it wasn't that farfetched. If so many people can learn Autocad and Microsoft Excel and Office Basic, then so many people could also switch to LISP. Personally I would go for Smalltalk.
The main power of Drupal is that it was always like Excel formulas -> Word/Excel Macros -> Office VBA -> Access -> C#/SQL Server/.NET. It served a whole load of users of varying skills and it helped basic users learn and upskill.
For a sheer lack of understanding or perhaps money, the leadership decided to go "enterprise" a blew up a huge majority of its users and contributors, and for most of its users it is pretty dead unless they want to try Backdrop. The focus on enterprise was a failure of leadership to understand what made Drupal as strong as it was.
Users are not going launch resource heavy Dockers and VMs with command lines just to start a personal CMS. For all those people Drupal is basically a non-starter.
Spending some karma points here, but having worked with many stacks (PHP in the 90s, Java from J(2!)EE to Quarkus and also lots of RoR), the node/bun/whatever JS/TS/[10 other tools that need to be intricately combined] has always repelled me.
Just the fact, that every little piece of software typically relies on hundereds of dependencies, half of which are not maintained and readily break with every major node version has always left me completely incredulous that anyone who ever worked with a language with a half-way decent tool chain and dependency management would ever put up with such a hot mess.
I mean, sure, PHP is certainly far from elegant and to this day suffers from the fact, that it started as a minimal template language (I got into it in the PHP 2 days). Most higher level language features feel a bit bolted on. But that's just as true for JS where everything actually has to be bolted on by the developer on a daily basis (Typescript, JSX preprocessors, etc.pp.) and in terms of effort to just get going and maintaining even a project of medium complexity PHP is still running circles around the node stack.
In my experience with the exception of very specific needs, for web development the programming language is very far down the list of what matters. Number one concern is the database schema.
I push hard for "server-rendered unless there's a reason not to" and I can't say I've ever regretted that.
Huh, it's been years since I thought about Drupal. I actually got my first major start in the tech field developing Drupal solutions for various organizations and companies. I remember the war room we put together for upgrading our clients, and all the testing we did to make sure the dozens of modules and themes would work correctly.
I always thought Drupal was great because it allowed less-technical folks to really build an interactive web application without having to write any code. We occasionally had to dive into some PHP or JavaScript, but in general we built great websites without having to do much "custom" coding beyond the themes.
Perhaps I used the wrong term. I really meant for those who are more operationally focused than development. IE you don't need to write code to get a nice Drupal website. I think it's always been the case that if you wanted to get it up in the first place, you needed to know a bit about MySQL, Apache config, and potentially PHP config. Again I haven't touched Drupal in a long time, but sounds like some of those were replaced with newer technologies like Docker, which are still more operationally focused.
While I agree with the conclusion there are many reasons for the decline of Drupal:
- the main reason people give up on Drupal 8/9/10 is that it's complex and has a lot of bugs. Some issues are going on for +5 years with no solution in sight, e.g. https://www.drupal.org/project/drupal/issues/2752443
- the old Drupal had a huge community because it was comparatively simple, for instance the hook system that is based on a convention of function names: Name your function something_alter_hook then it gets called automatically in the core. Use another hacky function if you want to determine the order when it's called :)
- now there's an abundance of classes, interfaces, design patterns and a custom ORM. You still have the old hooks system that often acts as glue between the old Drupal and the new OOP layer.
- super complicated "config system": There's a way of exporting the running "configuration" of a site (core and 3rd party modules) to YAML. So you can version control the config and transfer it between a development and live site. However this comes with many gotchas and apart from simple cases you almost always will run into some kind of problem.
- slow adoption of Drupal 8/9 (https://www.thedroptimes.com/9105/why-drupal-7-still-popular). Drupal 7 is dead for years now but still the majority of Drupal sites are running this version with no intent of migrating. This leads to a decline of the developer community and to ...
- low quality of third party modules. There are many good modules but there are also many modules that never reached beta status. It is the norm to have to work with something that's labeled "alpha".
- bad documentation. Many times the official docs are just skeletons with the obligatory remark "tbd".
38 comments
[ 2.9 ms ] story [ 118 ms ] thread[1] https://trends.google.com/trends/explore?date=all&geo=DE&q=j...
It's nothing new and both project will stay alive, although with minimal updates. I mean, phpFusion is still alive after all these years -- just with a much smaller user base.
Eventually, I suspect, WordPress will go the same way and we'll have another shiny hammer, that makes every problem look like a nail.
I think there are fair points/questions raised in this piece, but some of them don't really make sense or there are a few gaping contradictions:
- Drupal is also moving towards no/low code (albeit in a slower way, as is always the way with Drupal). Layout Builder is in core and is getting steadily better. Acquia has its own Site Studio solution for this (wether or not that is a good thing for the project is certainly debatable).
- I agree that Drupal does too much and there are probably too many slightly different (maybe even conflicting) ways of doing any given thing. Arguing this is bad makes no sense to me. Yes, you need to make the right choices when deciding what to go with, but this is true for every ecosystem and for the same reasons. How many different FE/JS frameworks does one have to be proficient with these days? Everyone in every field has chosen the losing horse at some point and that will continue to happen everywhere.
- Using Drupal 7 content-type editing UI screenshots in June 2022 to illustrate how "bad" Drupal is in 2022 is simply dishonest.
- Most of the 3rd party service providers (Mailchimp, Typeform, Disqus) listed as better alternatives to what Drupal offers also have integrations with Drupal. Not sure what the point here is; refer to the 2nd point I made above.
- I do agree with the point about finding talent to work on/with PHP and Drupal specifically - but how is this different from any other technology? There's always talent shortage in any given field for a varying degree of reasons. This is just PHP-shaming. Also, why would he care about developer talent/proficiency with other technology if at the end of the day he recommends building sites with a SaaS? That's for site-builders, not developers.
- Is a Google trends graph for Drupal an argument? At most I think it would be fair to assume Drupal is probably a known-quantity in the agency space and doesn't grab much headline-space nowadays also because of that. I agree you're probably better off using a SaaS alternative if what you're building is a simple CMS-type website for smaller clients. The adoption of Drupal by bigger (ie, enterprise-level) clients is what I've been personally witnessing for the last 4+ years.
1. Drupal Layout Builder > Indeed. The problem lays deep in Drupal's modular architecture, making it almost impossible to create a simple (in terms of UX) page builder with Drupal. I do not see Drupal fighting with Webflow, WeWeb or any other page builder there. Drupal ingest too much complexity.
2. Using Drupal 7 UI screenshots > I confess, clickbait on my side. Drupal 10 UI with tons of modules is still way more complicated to use than Content Stack.
3. The point about Drupal modules is not the same as for FE/JS Frameworks. The audience is not the same. On one side we have end-users that will prefer the simplicity of Mailchimp vs Simple News module. So what you're saying is that there is no point, as Mailchimp is integrated with Drupal. I'm returning you the question, if almost each module in Drupal is worse than it's SaaS equivalent, and you simply integrate Drupal with it, why using Drupal at all? At the end if your Drupal is only a content storage with CRUD, you have hundreds of better solutions (Hygraph, Xano, Content Stack, Prepr, etc...)
4. On ressources shortage. It's very different. A good PHP developer is not a good Drupal developer. Drupal's Learning curve is steep. But when you use any SaaS headless CMS you don't have to know it's internals. You simply build your front-end in any framework you're familiar with and connect it through GraphQL. Therefore any front-end developer will be ok, while with Drupal you'll need to specifically loook for experienced Drupal developer.
5. Google trends is not an argument, I regret that slippery slope I've taken. You can spank me.
I'm getting the feeling that your opinions (such as mine) come from dealing with many of the issues you've encountered when working with Drupal.
My opinion is it's far from being perfect, but is much better now than it was with Drupal 7.
If page building is all you want a CMS for, you're right: Drupal isn't for you; there are better alternatives. Doesn't mean it's dying.
Having the possibility of integrating with 3rd party services via installing a module is better than having to wire up your product/codebase to work with it. Many SaaS services also offer this, Drupal is not different.
I agree that a PHP Dev isn't a Drupal Dev and vice-versa (even though there's a very significant overlap). The learning curve for Drupal isn't steep if you only focus on learning what any of the simpler SaaS CMSs you mentioned offer. I argue it might even be lower and better documented. It does get steeper when you have to develop for Drupal - but then again, that's not something you can or have to do for a SaaS. Those products have learning curves of their own as well.
I've used Webflow before and liked it, but when the client started asking for some custom stuff, Webflow couldn't cut it either. Every tool has its limitations.
I have worked with Drupal as a backend with REST APIs for exposing data in multiple frontends and the experience was fine - probably not ideal and yes, it did require Drupal knowledge - but not different of what you'd expect trying to wire a FE app to consume/use JSON/GraphQL (which, by the way, is making its way into Drupal, too) from any other source.
Also, there's a significant point that neither of us has addressed, that I think is worth mentioning: what happens if/when one of those hot SaaS products goes bust because it didn't gain traction? Do you own the codebase? Can you quickly and simply migrate to another platform? Can you host it yourself? My guess is you're back to the same kind of predicaments you'd find in Drupal all the same. With the added bonus of now also having to find someone with experience and expertise to help migrate away from that even "nichier" product - might prove even harder to find talent than with Drupal.
Again: fair points raised; worth discussing; Drupal isn't dying.
I understand the complaints about Drupal, but it's all rather relative. Drupal is a glass that's 25% full. If you concentrate on the missing 75%, well, you'll just complain. But the 25% has been great for my projects. It's been a good foundation. I can usually find a module that does much of what I need and then I just jump in and help.
This kind of "X is dying" is just mean and negative.
PHP is one of those "boring technologies". Mature, slow paced and reliable tech. It has fixed a lot of the real issues which made it a meme language. If you are writing JS in the front, PHP is very similar and easy to pick up.
For people who are looking for a more mature and slow moving area, they could just fall back to PHP. Or try Laravel which adds some hotness to it.
I'm not sure I have a better idea on how to measure that, but the numbers don't really add up...
But PHP is on the decline. Its only hanging on barely because of wordpress.
Let me explain.
The web changed. The web evolved. Too fast for PHP to catch up, and fundamentally the web today is not compatible with the PHP way of exec + die immediately.
The web is more and more real time, all sorts of events fired thru sockets, work queues, and state is stored both on the client and on the server. PHP is not up for this task. This is why people have been moving away from PHP for the last decade, and this will only increase as time goes by.
Finally, please dont even start with that "nodejs clone in PHP" as its just a hack. If you use a node-js clone (there are many options) built in PHP you cant use any of the core stdlib, as its all blocking by nature, so for me and many others its a non starter.
PHP did a good job in evolving the web. Late 90s and early 2000s websites was the start, now its time to use better tech and continue forward.
Thanks PHP, but your time is up, its now time to say good-bye!
PHP is not my cup of tea (I can't be productive with the unintuitive function naming) but with a modern framework it can be proper. Laravel for example gives you a Django/Rails equivalent including task queues/etc, and becomes immune to the dumb vulnerability of uploading malicious PHP files in the media folder since all requests are routed through a single entry point rather than having the web server directly execute the PHP file.
I know theres some caching, but each request needs "the entire state" of the PHP app, and some frameworks like laravel or symfony are huge, and this is clearly visible when you notice how poor PHP performance is in basic req/sec benchmarks.
PHP being only WordPress? Laughable. PHP dying? Also laughable. PHP is the choice for everybody but FAANG and Silicon Valley startups. But not even all of them - Facebook, Wikipedia, P*nHub, Slack, MailChimp, Tumblr, Etsy, all PHP or Hack (a stricter variant, diverging over time). (Yes, Slack is PHP, not Node!)
> The web is more and more real time, all sorts of events fired thru sockets, work queues, and state is stored both on the client and on the server. PHP is not up for this task
Go visit Slack then. They are literally built on PHP, and later moved to Hack, Facebook's stricter-typed PHP because Facebook was as well. If Slack doesn't need "all sorts of events fired thru sockets, work queues, and state" I don't know what does, and yet PHP is their foundation. They're fine, and PHP is fine.
Slack is really just a chat. A glorified, slow version of IRC. I would not boast it as a marvel of engineering. If you want to se how to build a good and scalable chat system? See Whatsapp.
Dont get me wrong, PHP is still used, and will be after 10-20 years. But the fact reamins that is on a slow decline. Its never going to be as popular as it was back in the early 2000s.
Is it? That has been discussed here at every PHP release, recently with 8.1. PHP is getting the job done, runs everywhere, is fast and it becomes more safe with every release. There are modern frameworks like Symfony and Laravel (also take a look at PHP application servers Swoole or Roadrunner). You can even run a version of serverless Laravel, if you like (https://vapor.laravel.com/).
For realtime there is Laravel Broadcasting that can use services like Pusher or self-hosted alternatives like Soketi. Symfony supports Mercure.
Honestly, what are you missing?
In 2022 (soon 2023) "it runs everywhere" does not matter. Who deploys on a shared hosting service anymore? I did not even know they existed anymore. With docker you can deploy any kind of exotic stack and "it will just work".
PHP is not fast, a stock Laravel/Symfony app has poor req/sec benchmarks compared to almost anything else out there. Also the language still has all the warts it did in PHP5. Eg array_map/filter etc param order, no real unicode support, poor namespacing etc etc. Its just an overall bad development experience.
According to GitHub yes https://octoverse.github.com/2022/top-programming-languages
Usage also declined year to year on the Stack Overflow survey.
You are dealing with a stack where every 2 years one subsystem goes EOL.
Drupal 6 & 7 have lasted that long because Drupal didn't have to depend on anything except PHP.
Build on a set of always EOL'd subsystems and you get developer burn out, endless budget requests and justifications for maintenance, upgrades, endless obsolescence etc.
Drupal has failed primarily because lack of leadership. Drupal has always been its community, and with so many contributors switching the community to a different language would not have been difficult. The underlying model and the fit for the language is all that would have mattered.
In the early days of PHP one Buytaert (not Dries) said Drupal should be switched to LISP, and given how stable LISP has been over the years it wasn't that farfetched. If so many people can learn Autocad and Microsoft Excel and Office Basic, then so many people could also switch to LISP. Personally I would go for Smalltalk.
The main power of Drupal is that it was always like Excel formulas -> Word/Excel Macros -> Office VBA -> Access -> C#/SQL Server/.NET. It served a whole load of users of varying skills and it helped basic users learn and upskill.
For a sheer lack of understanding or perhaps money, the leadership decided to go "enterprise" a blew up a huge majority of its users and contributors, and for most of its users it is pretty dead unless they want to try Backdrop. The focus on enterprise was a failure of leadership to understand what made Drupal as strong as it was.
Users are not going launch resource heavy Dockers and VMs with command lines just to start a personal CMS. For all those people Drupal is basically a non-starter.
Just the fact, that every little piece of software typically relies on hundereds of dependencies, half of which are not maintained and readily break with every major node version has always left me completely incredulous that anyone who ever worked with a language with a half-way decent tool chain and dependency management would ever put up with such a hot mess.
I mean, sure, PHP is certainly far from elegant and to this day suffers from the fact, that it started as a minimal template language (I got into it in the PHP 2 days). Most higher level language features feel a bit bolted on. But that's just as true for JS where everything actually has to be bolted on by the developer on a daily basis (Typescript, JSX preprocessors, etc.pp.) and in terms of effort to just get going and maintaining even a project of medium complexity PHP is still running circles around the node stack.
I push hard for "server-rendered unless there's a reason not to" and I can't say I've ever regretted that.
I always thought Drupal was great because it allowed less-technical folks to really build an interactive web application without having to write any code. We occasionally had to dive into some PHP or JavaScript, but in general we built great websites without having to do much "custom" coding beyond the themes.
Jeff Geerling's series on trying to upgrade his fairly basic blog to Drupal 8 showed what Drupal has become.
"You can everything with Wordpress, there is always a module for any feature you might need."
Conclusion: Wordpress is dying too?
- the main reason people give up on Drupal 8/9/10 is that it's complex and has a lot of bugs. Some issues are going on for +5 years with no solution in sight, e.g. https://www.drupal.org/project/drupal/issues/2752443
- the old Drupal had a huge community because it was comparatively simple, for instance the hook system that is based on a convention of function names: Name your function something_alter_hook then it gets called automatically in the core. Use another hacky function if you want to determine the order when it's called :)
- now there's an abundance of classes, interfaces, design patterns and a custom ORM. You still have the old hooks system that often acts as glue between the old Drupal and the new OOP layer.
- super complicated "config system": There's a way of exporting the running "configuration" of a site (core and 3rd party modules) to YAML. So you can version control the config and transfer it between a development and live site. However this comes with many gotchas and apart from simple cases you almost always will run into some kind of problem.
- slow adoption of Drupal 8/9 (https://www.thedroptimes.com/9105/why-drupal-7-still-popular). Drupal 7 is dead for years now but still the majority of Drupal sites are running this version with no intent of migrating. This leads to a decline of the developer community and to ...
- low quality of third party modules. There are many good modules but there are also many modules that never reached beta status. It is the norm to have to work with something that's labeled "alpha".
- bad documentation. Many times the official docs are just skeletons with the obligatory remark "tbd".