Is there any more complex app to see?

[frederikhors]

I saw the famous video https://www.youtube.com/watch?v=3GObi93tjZI about SaaS htmx app (from React).

But honestly that app doesn't seem so complex to make, also because the parts where they use htmx are few and "simple".

Is there an example of some more complex app out there?

[Telroshan]

Don't want to sound like self promoting, but I'm making zorro.management which is extensively using htmx.
I have additionnal custom JS to add UX where appropriate (drag'n drop, mood boards interactivity in general).

Though, that's the neat part ; it's always "simple" to use htmx, so I wouldn't expect to find particularly intricate htmx usages in Zorro, despite having ~1200 hx- search results in the project's codebase.

[Telroshan]

Hey @frederikhors, thanks a lot for the feedback!
Yeah I totally understand the frustration there!

By instinct, I would've waited for the - yet to come - native apps (desktop & mobile) to implement such features and not be fully dependent on the internet connection, and not bother with those for a web app and a javascript environment.

I don't know much (if not anything) about service workers and stale-while-revalidate, so I'll have to look more into that
All static assets are cached (I mean css/js/images) but not HTML indeed.
Tbh, I don't really know how to tackle that and avoid outdated views ; let's say another user in your project changes something on a task, if the client is using a cache, you would get the outdated view for the task instead right?

I couldn't come up with an easy way (i.e that doesn't add a ton of complexity) to add some HTML caching client side, that wouldn't end up rendering outdated views and missing updates for some time. So I'll have to look more into what you mentioned here!

As for the backend, I'm not sure I fully understand what you're saying here, as intellisense works just fine. In my case, my backend is in Go, I'm using Goland and simply writing HTML templates, so the intellisense works just as fine as it would if I was writing for client side HTML rendering. Though it's likely that I misunderstood your point here, let me know

The only difference I noticed on the backend is that instead of responding with JSON, that you then use to build the HTML for your page on the client with a SPA, you generate the HTML right away. I moved away from SPAs to htmx and it felt alleviating to me rather than adding complexity on the backend to be honest

[frederikhors]

not bother with those for a web app and a javascript environment

I think this is a mistake because the browser can give us the same emotions if not better.

I don't know much (if not anything) about service workers and stale-while-revalidate

Little gifts:

1. https://web.dev/stale-while-revalidate

2. An amazing library with the core all focused on this: https://tanstack.com/query/v4/docs/react/guides/queries

3. This one too: https://swr.vercel.app

4. Another one with similar fetch policies (for GraphQL): https://formidable.com/open-source/urql/docs/api/core/#requestpolicy

5. An htmx competitor natively handles this (although not 100% like I need): https://unpoly.com/a-up-follow#up-revalidate

6. An amazing-magic-beautiful-wow article by one of the smartest people on the web: https://philipwalton.com/articles/smaller-html-payloads-with-service-workers/

let's say another user in your project changes something on a task, if the client is using a cache, you would get the outdated view for the task instead right?

Yes and IMMEDIATELY with an indicator (a spinner? a different color?) that indicates that content is stale and after the call's latency (150ms for example) the new content comes and get cached.

I'm not sure I fully understand what you're saying here, as intellisense works just fine

I'm referring to the intellisense in your "partial" templates. The things like:

<div hx-post="/mouse_entered" hx-trigger="mouseenter once">
    [Here Mouse, Mouse!]
</div>

Is there an intellisense help for mouseenter once or for /mouse_entered too? I think not. Using API yes. But I know, this is ALL COMPLETELY DIFFERENT issue.

instead of responding with JSON, you generate the HTML right away

JSON is just one of the players in this arena. And htmx - like EVERYTHING - has cons and pros of course.

I think that the combination htmx-service-worker could give us good emotions, but I haven't yet found material from someone who has tried it nor had the time to try it myself unfortunately.

[Telroshan]

Thanks for the links! I'll check all this out and let you know when I try it along with htmx

If it is easy to add some HTML caching with such a system, then I'd be more than happy to add it to Zorro, because as you said it would greatly improve the UX when you just want to read some information that you had seen a few seconds before.

So see you soon 😄 probably a matter of days, if not a whole week, before I get into it

[Telroshan]

Hey, finally getting to it @frederikhors
Thanks for the links again, really helpful
I'm trying to investigate first without using a service worker.

• So htmx fires an XMLHttpRequests when meeting the trigger criteria
• I answer on the backend with, say, Cache-Control: max-age=1, stale-while-revalidate=300 for a task's details tab. I can indeed observe an instant tab opening while it's cached when closing the tab and clicking again on the same task. I must admit it's a pretty smooth UX there
• I can see in the Network tab that the browser automatically fires another request right away to update its cache
• So, I may be wrong there, but it seems to me that we shouldn't need a service worker, given that the browser already takes care of that making a revalidation request depending on the Cache-Control value, and updating its cache
• If htmx could hook to that revalidation request the browser automatically makes to update the cache, htmx could then come back to the first request it made (that returned the outdated cached response), and update it with the up-to-date content retrieved in the meantime by the browser
• Though, I still haven't found any way to bind a listener or anything similar to that browser's automatic revalidation request, do you know if and how one could do that? Or is precisely because we can't do that that you're suggesting a service worker here?

Being able to rely on the browser's native features would be neat, would be sad imo to have to implement our own caching strategy with a service worker when the browser could already handle it

[frederikhors]

I'm glad (or not so?) that you have the same doubts of mine.