META: Incorporate Symfony UX Turbo Into Module

Added link to Symfony UX Turbo documentation.

Thank you so much for taking the time to do this write-up, @afinnarn, and for refining it, @Ambient.Impact! 🤩 👏

Hesitation

I am hesitant/concerned about adopting https://turbo.hotwired.dev/ because of the big notice you can see at the top of https://www.drupal.org/project/turbolinks →

They were very aggressive about it.

Then again … https://github.com/symfony/ux-turbo seems to have been around for a while and they somehow did not get shouted at by the creators of Turbolinks? 🙃🤷

Technically

Technically speaking, I'm not at all opposed to reusing a Symfony component! 😄

+1 for @Ambient.Impact's proposal to (at least initially) require BigPipe to be disabled.

Drupal.behaviors would be converted to use Stimulus controllers.

This sounds like it would be impossible to make it work automatically for contrib/custom modules' Drupal.behaviors? 😅😱 Sounds like @Ambient.Impact has similar concerns.
We'd need to figure out a way to make this work transparently, otherwise this seems not viable. (I did not look into what "Stimulus controllers" are.)

Similar concerns apply to the loading of additional CSS/JS.

Conclusion

Big +1 for creating a new branch of Refreshless that adopts this! But prior to building it all, I think we should prototype the foundations to ensure it can work as early as possible, without spending weeks/months on building this. Happy to provide reviews 😊

OMG, it looks like this prototype now already exists!?

@WimLeers

@Ambient.Impact showed me a video of the prototype through Mastodon a while ago, but I can't find it anymore.

I watched presumably the same video in in a Drupal Slack DM earlier today.

The next step here is to i) review, ii) manually test 📌 Hotwire Turbo minimum viable implementation Active . You could help with that, @Sebastian Hagens 😄

@Wim Leers

I am hesitant/concerned about adopting https://turbo.hotwired.dev/ because of the big notice you can see at the top of https://www.drupal.org/project/turbolinks →

They were very aggressive about it.

For what it's worth, I read through the exchange you had with them and was appalled at how they treated you. Sure, there's some reasonable discussion they could have had about naming and branding, but they threw that out the window.

Then again … https://github.com/symfony/ux-turbo seems to have been around for a while and they somehow did not get shouted at by the creators of Turbolinks? 🙃🤷

It's probably because they use the official Turbo that it's technically okay with them. I think as long as we don't use the Turbo name other than to refer to our own integration with the official Turbo library/framework we should be following their requirements, even if we feel they're overly restrictive/stringent.

This sounds like it would be impossible to make it work automatically for contrib/custom modules' Drupal.behaviors? 😅😱 Sounds like @Ambient.Impact has similar concerns.
We'd need to figure out a way to make this work transparently, otherwise this seems not viable. (I did not look into what "Stimulus controllers" are.)

Yeah, I can't really see an easy way to do this automagically that won't break some contrib code. It'd be interesting to explore at some point, but it feels like a whole project in itself. Also, controllers in Stimulus are just JavaScript classes that get automatically attached and detached to various elements. There's a bunch of other stuff that I'm glossing over, but that's how I understand them.

OMG, it looks like this prototype now already exists!?

😎

@Sebastian Hagens

@Ambient.Impact showed me a video of the prototype through Mastodon a while ago, but I can't find it anymore.

Just uploaded it now to YouTube: https://www.youtube.com/watch?v=KYd7vQZRqMo

See 📌 Hotwire Turbo minimum viable implementation Active for more information.