Drupal 11.3 put HTMX in core — I checked what that actually changes for AJAX callbacks

Drupal 11.3.0 shipped in December with a line in the release notes I had to read twice: HTMX is now in core. Not a module you can enable, not an experimental flag — a dependency-free JavaScript library bundled with Drupal, and BigPipe's frontend now runs on it instead of the old core/drupal.ajax stack. That's the kind of change that sounds like a footnote until you realize it's touching the render pipeline every single page request goes through.

The headline numbers

Drupal's own 11.3.0 announcement claims up to 71% less JavaScript for rich UX patterns, and benchmarks showing 26-33% more requests served at the same database load. The automated tests behind that: cold-cache requests about a third faster, partially-warm-cache requests up to a quarter faster. The post attributes this to combining database and cache operations in the render, path-alias, and entity-loading layers — not just "HTMX is lighter than our old JS," but changes to what happens underneath it. I haven't run my own before/after benchmark on this site yet (it's a small blog, not exactly a stress test), so take the percentages as Drupal's own claim rather than something I've independently reproduced — but the mechanism described is plausible and worth checking if you run anything with heavier BigPipe usage.

What actually changes if you write #ajax callbacks

If you've built custom AJAX commands against Drupal's old framework, the core change is which library renders the response — HTMX attributes instead of the `core/drupal.ajax` JS driving `data-drupal-ajax` behaviors. I haven't migrated an existing callback yet, but the direction is clear enough that writing new interactive blocks against the old AJAX Framework now means building on the thing core itself is moving away from.

The rest of 11.3 that's easy to miss

• Theme Hook attributes. Themes can now use #[Hook()] the same way modules do, with hook classes living in src/Hook/. If you've already converted your custom module's hooks to the attribute style, this closes the gap where themes were still stuck on procedural `.theme` files for anything beyond preprocess.
• A core content-export command. php core/scripts/drupal content:export ENTITY_TYPE_ID ENTITY_ID, run from the site root, exports a single entity in the format the contrib Default Content module uses, optionally pulling in referenced dependencies like images or taxonomy terms. Small, but it's one fewer contrib module needed for a task I've reached for more than once.
• Navigation is stable as a replacement for Toolbar, recommended especially for sites with complex admin structures — but it's not the default yet. I'm treating that as "try it on a lower-stakes site first," not "switch immediately," since Drupal itself hasn't made the call to default to it.
• An experimental mysqli driver. MySQL/MariaDB queries through `mysqli` instead of PDO, specifically to allow parallel queries where PDO runs them sequentially. It's explicitly experimental and hidden from the UI, with async query support planned for later — not something I'd put in front of production yet, but worth knowing it exists if query serialization is ever your bottleneck.
• PHP 8.5 is now supported and tested. Given 11.3 is explicitly laying groundwork, I'd read this as a signal of where Drupal 12's minimum PHP version is heading, not just "one more version we test against."

What I'm actually doing about it

I'm not rewriting working AJAX callbacks just because core picked a new library underneath BigPipe — that's not where the return is. But any new interactive block on this site from now on gets written with HTMX patterns in mind, not the old AJAX Framework, and I'm bumping Navigation up my list of things to pilot on the admin side the next time I touch content workflows. The mysqli driver and the content:export command go in the "useful to know exists" pile until there's an actual reason to reach for them.