Problem/Motivation
Drupal is less relevant today than it used to be for a large part of Drupal's historic user-base (read hobbyists). Total cost of ownership is pretty high and nowdays people prefer exploring the wild JS ecosystem of tools to make and publish websites.
A trend that came back is static websites. Another trend is decoupled websites. The intersections of both topics surfaced some fundamental problems with statically rendering a website: how to avoid a full site render when a single piece of content has changed.
Last year several frameworks made big announcements around incremental builds: gatsby, nextjs, and probably others.
This has been a solved problem in Drupal 8, and solved in a generic way, unlike gatsby/wordpress integration, thanks to
cache-tags →
. The original use case was to make sure content was properly updated in
CDNs →
, and a static version can be seen as a DIY CDN :)
For several years the awesome
Tome module →
has been available to export a Drupal site into a static version, using incremental build by default. I've managed a team that implemented Tome on a high traffic website, it uses redirections, about 23 languages, and by now thousands of pages.
To recap:
- Drupal has a technological advantage: I don't think other CMS can come close to Drupal about tracking content in caches in a generic way (haven't seen anything from wordpress, joomla, or typo3 other than TTL & per-url or per-block cache, without the content dependency information)
- Static sites drastically reduce the total cost of ownership (what security updates? don't need to update as often, even if you still should!)
- Static site hosting is cheap nowdays, at least much cheaper than a production ready Drupal server(s)
- For the developer audience static sites are as popular, if not more, than decoupled websites (just look at the number of static generators :p)
- People who do decoupled to have a static site won't need to add another tech layer and can just use vanilla Drupal
Proposed resolution
Provide a way for Drupal core to output a static site and provide guidance/support for common use cases:
- Redirects
- localized 404/403 pages
- Provide a true opinionated implementation of progressive decoupling to make static + authenticated a possibility
- Possibly (just an idea, not the focus of this issue) Provide a supported way to expose general purpose API (to handle form submits, comments, search, etc.)
Some things that could be done to make this easier:
- Make aggregated assets URLs more predictable (to avoid having to crawl the generated HTML)
- Image style generation (on upload, instead of on demand for example)
- To some extend, an API endpoint that can be exposed for form submission (contact module, webforms, etc.)
The last point is not the core of this proposal, only a nice side-effect, and could be a starting point to re implement some of Drupal features in a different stack (go? rust? js? java :p?) or at least have a server that can handle websockets better to unlock some more advanced features.
The core idea here is to make use of our incredible cache-tags implementation to leapfrog the other CMSs in the static generation space.
Remaining tasks
API changes
The hard part of tracking content is all already done with cache tags!