Ready for mobile. In mobile apps, you usually can’t have big, complicated composite pages. Each segment needs a dedicated screen. With an application built using Turbo Frames, you’ve already done this work of turning the composite page into segments. These segments can then appear in native sheets and screens without alteration (since they all have independent URLs).

I’m just asking what benefits of htmx are there when you get so much out the box with Hotwire stack?

Efficient caching. In the discussion page example above, the related topics sidebar needs to expire whenever a new related topic appears, but the list of messages in the center does not. When everything is just one page, the whole cache expires as soon as any of the individual segments do. With frames, each segment is cached independently, so you get longer-lived caches with fewer dependent keys.

Parallelized execution. Each lazy-loaded frame is generated by its own HTTP request/response, which means it can be handled by a separate process. This allows for parallelized execution without having to manually manage the process. A complicated composite page that takes 400ms to complete end-to-end can be broken up with frames where the initial request might only take 50ms, and each of three lazy-loaded frames each take 50ms. Now the whole page is done in 100ms because the three frames each taking 50ms run concurrently rather than sequentially.

None of those frameworks allow this

Um, you can have lazy loaded fragments with hx-get.

I'm not sure what you're trying to do here with an infodump from the Hotwire tutorial pages. Furthermore I'd be a little wary adopting a framework that's lost almost its entire dev team overnight.

It’s a whole stack is my point

What do you mean "it's a whole stack"

Mobile

What are my options with htmx?

htmx is much more focused and targeted. Much easier to do everything Turbo is doing with more mainstream tooling + htmx. e.g. there are a ton of solutions for HTML+JS to native that would work fine with htmx. Turbo is more conceptually complicated + feels more like a lock in. I'm using htmx w/Spring Boot, lots of others are using htmx with Django happily. Turbo feels more like it's taking a similar starting point (html over the wire) and just kind of doing it's own thing.

But there’s no concept of turbo drive in htmx? Every page is a full reload?

Isn’t that the first step of an html over the wire approach 🧐

Turbo drive is the new turbo links

I agree that a major disadvantage is the unknown of the dev team

No, htmx is all about partial refreshes with html over the wire.

That’s why htmx needs to start copying over features

So we can have the full stack

Just use ordinary html selectors for targeting, no need for the turbo frame stuff.

e.g. right now I'm using htmx to dynamically add html to a particular div with no scripting at all, just a few extra attributes.

My suggestion would be to read the docs a bit more closely at https://htmx.org/docs/

Htmx is an attempt to complete html as a hypertext. It’s just a different approach. Less magic, more flexible imo. But if you like Hotwire and more “just works” magic

But yeah, read the docs a bit, you’ll see the differences pretty quickly.

What’s an example of just works magic

Do you like websockets?

You don’t need to use that at all

turbo streams can come from normal http requests as well

Ok. Sounds like that’s the approach for you. If you want to check out the docs and maybe the examples for htmx you can see what it can do.

Sure, just don’t make up random stuff when we’re all on the same team