Contrib.social

Hotwire Turbo minimum viable implementation

Open on Drupal.org →
Created on 11 October 2023, over 1 year ago

Problem/Motivation

After thinking about and exploring the Symfony UX Turbo code (see 🌱 META: Incorporate Symfony UX Turbo Into Module Active ), I'm not convinced that it's required to get Turbo Drive up and running, which is the Turbo equivalent of the homegrown JavaScript in the 8.x-1.x branch. Symfony UX Turbo does provide integration for Turbo Frames and Turbo Streams, which I'd want to eventually support, but I think the wise approach would be to start with basic vanilla support for Turbo Drive without the Symfony integration to keep things simple. After that, we can work on integrating the Symfony stuff as a nice to have.

Steps to reproduce

👀

Proposed resolution

Remove the old JavaScript.

Secondly, remove the server-side optimizations. Why? Stick with me, let me explain:

  1. While clever and well thought out, the server-side stuff adds complexity. Serving a mostly standard Drupal response (i.e. full page HTML) removes some complexity, and Turbo Drive is built to handle this really, really well.
  2. All modern browsers support GZIP compression, drastically cutting down on data sent over the wire compared to the dark old days. While it's still technically more data than if we only sent changed regions, it's not as big a deal as it used to be, unless you've got comically complicated pages that you're serving, in which case you probably have bigger problems.
  3. If you're doing Drupal right, you know how to use the cache API so that stuff only gets rendered (and thus render cached) when it has to be.

tl;dr: it keeps things simpler and modern Drupal and modern response compression reduce the downsides considerably. Thank you for coming to my TED Talk.

Remaining tasks

Do the actual thing.

User interface changes

Mostly none? Should just work.

API changes

Most of the original JavaScript will be removed; the equivalent Turbo events and Turbo Drive API can be used. We could probably provide a backwards compatibility layer, but given the non-existent install base of this module at the time of writing, I doubt it would be worth it.

Data model changes

The module doesn't store anything, so probably none I guess?

📌 Task
Status

Active

Version

2.0

Component

Code

Created by

🇨🇦Canada ambient.impact Toronto

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024