His little startup succeeded in getting many millions of dollars of VC money poured into Drupal, and it’s actually a really good way to build a serious website now, for a particular niche. It’s not for SPAs, and it’s not for non-developer hobbyists, but it’s the best way I know of to build a performant content-heavy multilingual website. You have to be willing to a) write code and b) learn an extensive framework. Lots of people only want to do one or the other of those things, so it’s not for them.

> performant

I've been away from Drupal for ~10 years, but I recently helped a friend spruce up a Drupal site he's working on and still found it's largely powered in production by heavy caching, and the page load speeds in development are a slog. I didn't know enough about how he built the site to know if that's still the case everywhere in Drupal or just his configuration, but my impression is still that it's absolutely not production ready without heavy caching in front of the site.

Drupal IS slow, but many "modern" sites in JS or Wordpress are pretty heavily cached too. There's just no beating "static HTML file served over CDN, with portions rehydrated".

Whether you generate that HTML in Drupal, Wordpress, or some other system, having to run code to generate it is always going to be slower than caching. Drupal is plenty fast for internal previews (i.e. when the server is not overloaded), but at the end of the day it's still a PHP app, and LAMP/LEMP is generally harder to scale up and across vs plain files.

And for what it's worth, a Drupal site cached behind Acquia/Pantheon/etc and their CDN can -- usually will -- be faster than an uncached JS site served from any single data center.

So it's slow for any dynamic site? Like if I want to use it to serve a site with user generated content recommended by AI, like a reddit or twitter it's bad for that usecase?

Drupal? I think that would be very slow for that use case (if you want it to be real-time, as opposed to write-rarely-read-often, for a large number of users). I haven't tried to optimize it for that particular case, but out-of-the-box, the Acquia/Pantheon setups aren't really meant for something like that.

You could, however, use Drupal (or any other CMS) to manage the relatively infrequently-changing parts of the website (static assets, the layout, introductory text, landing pages, much of the Javascript, etc.). And then use AJAX to dynamically fetch in the dynamic portions (the user content) from some other API.

I doubt that's the best approach though... probably there are better systems for something like that. Not my specialty though, sorry =/

------

edit: It's also very different if you're operating at reddit scale vs "small website with a few dozen comments a month" scale. If you're not expecting heavy, consistent real-time traffic, it'll probably be OK. Not as fast as it could be with better architecture, but fast enough that users will put up with it. Hell, we all did it for years with phpBB, the Drupal forums, etc.

It’s great for that use case, if

- you host at one of the Drupal-optimized services (Amazee, Pantheon, Acquia)

- you put a Varnish service like Fastly in front of the site

- you use BigPipe to serve the dynamic content

- you have experienced Drupal engineers available for your project

If you’re missing one of those pieces, I’d recommend pretty strongly that you find a different platform.

What in this stack allows mass real time writes and cache invalidations?

Bigpipe looks like it chunks data from the server to the client, but it's not clear to me how that helps with real time updates to the database?

Varnish can help to a degree, but if you're on a big provider you're going through their Varnish setup anyway (among other caches) and it's not super configurable.

Drupal 8 introduced an entirely new caching system, with actually good cache invalidation. Right now if I save new content on one of my sites, it queues an invalidation request that gets sent to Varnish (which can be run either as a shutdown function or via a queue runner on cron) and the new content shows up within seconds.

I’m not sure I read the OP the same way you did. If you read it as “can I build a site on the scale of Reddit or Twitter with Drupal” then no, don’t build Reddit or Twitter with Drupal. If you read it as “will Drupal serve a site with user generated content” then yes, it will, but if you’re planning to be a top 10 site on the internet, you’ll need a custom stack.

Gotcha. Thanks for the clarification!

> if you’re planning to be a top 10 site on the internet, you’ll need a custom stack.

And yeah, that's what I thought the OP was hinting at (or at least hoping to become).

It'll handle small-medium scale forums just fine. Probably any stack would.

There's a lot of room between small- to medium-sized and Reddit-sized. Drupal 9/10 scales out well and does just fine at that large (read "enterprise") size. But certainly the more read-heavy a site is, the more suited it is to Drupal.

I have never made that to work. With Akamai we are resorting to lower ttl for cache expiry. The tag based cache architecture in practice is not helping with constraints from CDN providers

Any chance of switching to Fastly? Or at least testing it? There's excellent documentation for a working setup here: https://docs.lagoon.sh/drupal/integrate-drupal-and-fastly/ I don't know how to get invalidation working on Akamai, but the process of getting it working on another provider might get you the insight you need to get Akamai working.

> if you’re planning to be a top 10 site on the internet, you’ll need a custom stack

To be fair, that's the case with pretty much any CMS. Even if they start with a stock system, by the time they actually hit top 100/1000 (let alone 10) there's a lot of custom work to be done.

And realistically, a "top 100/1000 site" is almost always going to have a cloud of other sub-sites and related properties. The corporate site, intranet/HR, jobs and recruiting, press center... The penumbra of "Oh, yeah, we need one of those... but it would be ridiculous to build it from scratch" sites for a large organization can be pretty large indeed.

Right, the caching is how you get the performance. Ideally you’re behind, say, Varnish. (Like I said, it’s not a hobbyist platform anymore IMO.) There’s pretty slick cache invalidation now, so you can set up Varnish with long cache lifetimes, and still get near-instant updates as authors save content.

Drupal 8+ is an improvement over 7/6, especially for developers. It's more aligned with Symfony, which makes it much easier to write maintainable modules. You can also use it as a headless CMS if you have your own frontend (eg: mobile apps)

For editors, you have a slightly better default UX (Claro/Olivero), views builder, workflows, etc.

Cut my teeth with drupal back in the day. I walked away after 5 years feeling like I stifled my growth as a programmer because all I ended up doing was hacking away at this behemoth of a framework to try and overcome all of it’s idiosyncrasies.

Drupal is a great CMS framework. With Drupal and a capable development team, you can use Drupal to build an awesome CMS, and if you want to, also an awesome website on top of the CMS.

Drupal is not a great piece of software to try to use out of the box as both a CMS and a website front-end. Drupal doesn't have the same kind of ecosystem as WordPress. Many of the best themes and modules are really there to assist your development of your own features, as opposed to being plug-and-play solutions.

What, in your opinion, would be an advantage of Drupal over a headless CMS?

I'm not sure I understand the question. Drupal is a headless CMS if you want it to be. Do you mean what would be a reason for using Drupal's front-end over developing your own? I came to Drupal from managing community sites with lots of different user roles that each need complex permission sets, and I'd say it really excels over other CMS front-ends for that. Drupal.org is itself an example of this kind of site: thousands of different users (including untrusted users) logging in and creating and editing and moderating content in real-time. Sure, you could rebuild all of this functionality with the exposed APIs, but that'd be a ton of work.

Drupal basically is a headless CMS plus a CMS front end if you expose the web service module.

So... does that make a headful CMS? :)

"Recapitated"?

You can easily use Drupal to create the backend for a headless CMS. It's about as simple as turning on the JSON API module that comes out of the box, and then start creating content types.

But then you're having to maintain the CMS, which isn't as appealing as using something like Contentful. It really depends on your use case (like all technologies, of course).

This reads like something out of chat gpt

What are examples of good CMS software that you've used?

I can't remember the last project where I haven't used Craft CMS. Twig templating, no opinion on the data structure and easy to extend.

My thought as well. Craft is (inexpensively) commercial but it essentially starts where you’re fighting to get with Drupal for medium-sized projects. And authors like it.

As a CMS with web framework features, it’s also built on top of a model/controller-based framework, using Yii instead of Symfony. Craft has thinned their abstractions over time to more directly match Yii’s methods.

ProcessWire CMS. Developer oriented but amazing for clients once set up. Been using it for 10 years straight.

A few years ago, most of my job was maintaining a Drupal 7 installation for a mid-sized nonprofit. It's the most "built by engineers for engineers" CMS I'd ever used -- I don't mean that as a positive -- and the UX was atrocious. Everything was buried layers deep both in the UI and in the schema, a simple string change would take multiple functions (to go through the various localization and abstraction pathways), the plugin ecosystem was mostly abandonware that made NPM look like a well-manicured garden, etc.. The community was friendly enough, but overall it just felt like I was working with very old technology and ideology. Reminded me of the Perl days.

Eventually I was tasked with upgrading it to Drupal 8/9 (a new generation, with no backward compatibility with 7.x). It was basically a full rewrite. Well, I built a prototype in the new version, but it was still a convoluted mess -- slightly better, but nowhere near "modern". The whole thing is just way more complicated than it needs to be, and reminds me of 90s-style data management, and a web UI reminiscent of cheap wifi router dashboards: ugly, very slow (much of it wasn't ajax yet), and in general just total drudgery to work with.

After I built that prototype, I swore to myself, "This is the last time I'll ever use Drupal. Ugh." As a proof of concept, I also built that same prototype in several other CMSes: Wordpress with Advanced Custom Fields, Ghost, DatoCMS, Strapi, Contentful, GraphCMS (now Hygraph), Storyblok, Grav, etc. ALL of them were way more usable than Drupal, and each one took like 1/10th the time or less to make. It was especially fast with the headless CMSes + Next.js

Wordpress with ACF was probably the closest direct comparison, and that provided a much better editor experience, but still had poor DX (cuz you had to either work in Wordpress/PHP, or else shim ACF with other plugins to make it act headlessly).

It took me a few months to upsell the team, IT, and management to switch to a proper headless CMS instead, completely detaching the editor experience (managed by the CMS) and the DX (we were now free to develop the frontend however we wanted to, fetching content via GraphQL). It made everyone happier in the end, and it's much more maintainable.

Editors never have to care about forced upgrades, web technology changes, etc., anymore, and devs don't have to worry about accidentally breaking the editor experience while working. And a modern Jamstack (or anything else, really) is way way easier to work in than Drupal or Wordpress templates, especially since they don't share the same server as the database & editor and can be independently hosted, developed, tested, deployed, etc.

I still would never touch Drupal again. I've never used a technology I was so annoyed by (and that's coming from someone who grew up writing AT commands for their 14.4k modem, made websites in Perl, had to use Applescript to shim Filemaker into a web CMS... ugh.) Drupal is by far the most traumatic software I've ever had to use.

---------

Side note: Drupal itself aside, companies like Acquia and Pantheon do make the experience much nicer though. They basically manage hosting, forking, dev environments, backups, visual diffing etc. for you, like a bespoke cloud tailor-made for Drupal and Wordpress. I would definitely host at one of those companies (I prefer Pantheon, personally, but both are great compared to non-Drupal-specific hosting).

You're forgetting the additional eye-poke joys of minor plugin updates causing WSODs, how slow it is without caching, how painful styling certain things can be, how difficult the DB schema is to wrangle with regards to making _any_ changes and dozens of others that are worth forgetting because of various PTSD.

It _is_ flexible for people wanting to be able to create types/taxonomies within the GUI, if you ignore the chaos behind the scenes. It also has good support for returning said content via JSON if you choose to do so, but if you're doing that, just define your own back-end and avoid the suffering.

> You're forgetting the additional eye-poke joys [...]

Oh, no... I didn't "forget" as much as "permanently blocked it out of my memory to maintain some shred of sanity" :)

> It _is_ flexible for people wanting to be able to create types/taxonomies within the GUI, if you ignore the chaos behind the scenes. It also has good support for returning said content via JSON if you choose to do so, but if you're doing that, just define your own back-end and avoid the suffering.

Ultimately this is what convinced us to move to a headless CMS (which I hadn't heard of at the time, and I had to do some research and prototyping to understand it). But through our internal user (editor) studies, we learned that content organization, ease of editing (good WYSIWYGs), relationships, speed, and most of all UI clarity were really important. I built the same prototype in like 20 different CMSes, excluded the ones that didn't meet some baseline criteria, and had the editors and stakeholders try my demos for like 5-8 of the finalists, ranking each one by the ease of several tasks (rich text formatting, linking to related content, restoring a past revision, sharing a preview draft, etc.). Drupal was pretty much dead last in most of the categories (and this was the newer version, 9 I think). I had my own favorites but I let the editors decide, and the headless systems won by a large margin.

Any good CMS these days will have rich taxonomies -- that's arguably the defining characteristic of a proper CMS (as opposed to a blog engine, say). Where they differentiate is in the editor experience (ease of use, ease of drafts, ease of previews, ease of admin, ease of relationships, etc.) and/or the developer experience (response shapes, GraphQL mutability or not, API and SDK documentation and support). But for teams that have a mix of devs and editors, any of those would typically be better for both sides than a bespoke database.

For the editors, a vendor-supported (or polished open-source) CMS means a nicer editing experience than fighting with some tiny team's internal WYSIWYG field tied to a Postgres/MySQL field, with the corresponding bugs and quirks that's never prioritized by the (typically) backend developers and DB admins who care more about schema purity and such.

And for the developers, well, it frees them from having to worry about that and focus on the frontends, mobile apps, whatever, and also gives them the freedom to use whatever stack they want (be it Jamstack, .NET, HTMX, whatever). The content just come in as JSON and the rest is entirely up to them.

I feel like Drupal tries to occupy that space where it tries to do all of the above (and it CAN, to be fair), but it's not great (or even GOOD) at any of it. It's just a mishmash of sub-par experiences where nobody is happy, except maybe management (because they can worry about just one piece of software at one vendor like Acquia/Pantheon).

Even if your constraints are PHP and self-hosting/commodity virtual hosting, I think Wordpress + ACF is a way cleaner experience for the majority of sites...

I thought Drupal 6 and 7 were great, but this was about 5-10 years ago. Haven't looked at it since then. It was the first CMS I worked with professionally, so I may be biased, but once I "got it", it became quick to add features (not "Features", which wasn't very fun). This was before everything went headless and javascript :)

Drupal 6/7 was actually what led me to discover headless and JS :) After I learned it and built a few features & Features, I thought to myself, "Huh, okay, I see what they're getting at here... it's pretty powerful, just hard to use. Wonder if there's an easier way to do this..."

Turns out, absolutely yes! I guess there's a reason why headless and JS exploded. We migrated and never looked back.

Which headless CMS did you go with?

Full disclosure: I now do some paid work for one of those CMS companies, so I don't want to give a biased answer :) I'm also not authorized to speak for them. What I can offer, though, is what I remember of our finalists of the Drupal migration project (what the parent post was about) -- that happened long before I joined the CMS company. Also keep in mind this info is from circa 2021-22; I haven't reevaluated since then and the players might've changed. That said:

* Contentful was by far the market leader. They were one of the first in the space, and probably the reason it got so big. Their UI was pretty decent, SDK and docs were good, support was good, good plugin ecosystem... but it was really expensive. When they started they were really affordable, but eventually I think they pivoted towards enterprise and wanted to wind down their more affordable plans. At the org I worked for, they wouldn't quote us an enterprise plan until we signed a NDA, and provided very limited developer sales/devrel time. My boss wasn't willing to continue with the sales process after that.

* DatoCMS was the most editor-friendly one, with a really nice UI, powerful field types, and a good admin interface with good roles & permissions & workflows that enabled complex user types to work in different parts of the CMS. Had a good plugin ecosystem, community support, and a small but really friendly and helpful team of staff. The sales process was great, with several of them sitting down with us to discuss all the details we needed. This was the editors' favorite in several ease-of-use categories. The primary concern there was that they're a relatively small Italian company instead of some huge American business (meaning potential time zone issues, etc.), but they'd been in business a few years already by that point and we were impressed by how supportive and welcoming they were.

* GraphCMS, now Hygraph, was what I considered the most technically powerful of the bunch. It had a really clean API, and was the only one (at least at the time) which allowed GraphQL mutations, meaning you could actually write to the GraphQL API. The others all needed REST APIs for updates, and provided GraphQL for reads. Its UI was pretty good, though a bit developer-centric compared to the others (like fields at the time didn't have editor-friendly labels, just their developer-facing names). The sales process was also great, and they were very accommodating of our questions.

* Prismic offered a really clean editor interface and stood out to me as the one that lets you jump right into editing the quickest. However, at the time, it didn't have some of the more advanced relationships / field types that we needed (don't recall the details, sorry). But I do remember it as "a CMS to revisit if I ever needed a simpler, cleaner one for a less complex schema" just cuz it felt so polished and easy.

* Wordpress with Advanced Custom Fields (a plugin), to my surprise, offered some of the most powerful AND easy to use schema, both in terms of the cleanliness of how it comes out in the API and in terms of how easy it was to compose/define in the editor and admin GUI. If data modeling were our chief concern, this would've been one of the top choice. ACF was really good, but we didn't want the baggage of Wordpress itself (i.e. having to host a LEMP & WP stack on Acquia or Pantheon just to run ACF headlessly; that'd be a waste of resources and dollars).

* There's a bunch of other commercial ones (Sanity, Storyblok, ButterCMS, Agility... see here for a list: https://jamstack.org/headless-cms/). In general they were all "good enough" and passed most of our criteria, but just didn't really stand out against our finalists. But that was just us, with our particular evaluation criteria and our specific individual editors' preferences. Before the eval, I built a prototype in many/most of these systems. I'd really encourage that! It really doesn't take long (it's so much faster and easier than in Drupal) and gives you a much better picture of what it's like to use each one, both as an editor and as a dev. Just define some good-enough schema (something like Northwind Traders, or even simpler https://en.wikiversity.org/wiki/Database_Examples/Northwind) and some basic frontend, then try to implement that schema in each service, fetch its data, and also try to programatically add/edit a record. I had a lot of fun doing that for about 20 different providers in the span of a week or so, and learned a lot along the way.

* There are also a few open-source/self-hostable ones if the cloud isn't your jam: the ones I remember were Strapi, Directus, and Ghost. There are probably more these days.

A very contentful answer, thank you so much, I greatly appreciate the indepth response!

> A very contentful answer

I see what you did there ;)

My sentiments and experience completely. Could mostly put up with the DX with the right mix of modules in place, but never got over the UI. Next. Level. Terrible.