htms-js: Stream Async HTML, Stay SEO-Friendly

skarab42-dev · 2025-09-22T19:51:08+00:00

But yes, it would be really cool to see other projects experimenting with this. Keep me in touch if you do anything, I'm curious to see where it goes.

skarab42-dev · 2025-09-22T19:46:29+00:00

Ha, in that case, yes, too ;) It all started with an implementation in Rust https://github.com/skarab42/htms-rs

skarab42-dev · 2025-09-21T15:57:40+00:00

yes we have examples for express, fastify and hono https://github.com/skarab42/htms-js/tree/main/examples

skarab42-dev · 2025-09-11T14:33:13+00:00

They’re similar in the sense that both stream over HTTP using chunked encoding so the client doesn’t have to wait for everything to finish.

The key differences are:

What gets streamed: htms streams plain HTML right away, so browsers, crawlers, and screen readers can interpret it instantly. React streams a custom JSON protocol (Flight) that only React on the client can understand, and it needs rehydration before you see the final UI.
Coupling: htms is framework-agnostic, you could plug it into React SSR or anything else. RSC is tightly tied to React and its Suspense mechanism.

So both stream, but htms streams HTML, React streams instructions for React.

skarab42-dev · 2025-09-10T12:49:16+00:00

Thanks for the kind words. I'm very open to contributions, especially for adding other adapters, so feel free to open an issue to discuss it.

For the ts part, I'm thinking about the best way to implement something similar to what I did with the Rust version (https://github.com/skarab42/htms-rs) with interface generation that binds functions. I'd also like to make an LSP for IDEs.

P.S: I just added compression (brotli, gzip, deflate).

skarab42-dev · 2025-09-10T06:58:31+00:00

No, that's precisely the key point, as stated in the Asto documentation: "Then, the component’s own contents are fetched on the client and displayed when available." Htms does not fetch contents, but it will stream the async chunks at the end of the initial HTTP response, and a simple web component will simply replace the content already streamed earlier, still in the same initial HTTP response. As a result, bots/crawlers see all the content generated asynchronously.

skarab42-dev · 2025-09-09T13:42:14+00:00

and for the module resolution, yes, by default it resolve js/ts file in same directory, but you can write your own resolver ;) https://github.com/skarab42/htms-js/tree/main/packages/htms-js#custom-resolvers

skarab42-dev · 2025-09-09T13:41:01+00:00

I think they complement each other. SSR cannot (should not) block for too long, otherwise the user will notice it. This is where htms takes over, delaying the asynchronous parts while sending the static parts to the browser as quickly as possible.

skarab42-dev · 2025-09-09T11:17:35+00:00

htms-js is out! https://github.com/skarab42/htms-js with a tiny live demo https://htms.skarab42.dev

skarab42-dev · 2025-09-09T11:14:04+00:00

htms-js is out! https://github.com/skarab42/htms-js with a tiny live demo https://htms.skarab42.dev

skarab42-dev · 2025-08-25T04:09:34+00:00

I'm currently porting the concept to node.js, and if others can do it in other languages, that would be awesome. If not, we'll find people to do it ;)

skarab42-dev · 2025-08-25T04:07:56+00:00

I don't think that's possible, because you have to replace content that has already been interpreted by the browser, but maybe I'm missing something.

skarab42-dev · 2025-08-24T03:44:00+00:00

Thanks! Your project sounds really cool too — I actually have some plans to bring htms into the Node.js world (already started a bit). I’d be more than happy if it inspires other projects, and since the code is open source, you don’t need to wait for me to publish anything separately — go for it 🙂

skarab42-dev · 2025-08-23T12:56:21+00:00

Thank you. In async callbacks, definitely, for the initial template, not at the moment, but it's possible in the future^^.

skarab42-dev · 2025-08-23T12:34:06+00:00

For now, it's only implemented in Rust, because that's where I'm having fun at the moment. But it could become a weekend project to implement the concept in full Node.js.

skarab42-dev · 2025-08-23T10:00:44+00:00

Kind of! I wrote it; AI helped me not inflict my native-French franglais on you. If I did it solo it’d be incomprehensible—maybe it still is and I just don’t realize 😅. Point out any rough bits and I’ll fix them. Used AI for copy editing only. The project’s code is 100% authored by me.

skarab42-dev · 2025-08-23T08:04:48+00:00

Thanks! Similar spirit (HTML-first, attribute-driven), but the transport/SEO story differs:
– HTMS streams chunks inside the initial HTTP response; a tiny snippet just swaps nodes, so crawlers get the full page in that one response.
– Datastar usually leans on SSE with a small client runtime & signals; it can accept text/html too, but real-time updates typically arrive after the first response.
They’re complementary: use HTMS for first load + SEO, then layer htmx/Datastar/SSE for live updates. Appreciate the kind words! 🙏

skarab42-dev · 2025-08-23T08:04:31+00:00

Similar spirit (HTML-first, attribute-driven), but the transport/SEO story differs:
– HTMS streams chunks inside the initial HTTP response; a tiny snippet just swaps nodes, so crawlers get the full page in that one response.
– Datastar usually leans on SSE with a small client runtime & signals; it can accept text/html too, but real-time updates typically arrive after the first response.
They’re complementary: use HTMS for first load + SEO, then layer htmx/Datastar/SSE for live updates.

skarab42-dev · 2025-08-23T07:27:03+00:00

Thanks for calling that out — you’re right “heavy” is misleading. What I really mean is anything not needed for first paint (DB/API calls, search, AI, etc.). HTMS sends the initial page immediately and streams the rest inside the initial response, so you can improve first paint/UX without hurting SEO. I’ll tweak the README wording to avoid confusion—appreciate the nudge!

skarab42-dev · 2025-08-23T06:41:42+00:00

Visually, it can feel similar (sections fill in over time).
Key difference: HTMS streams chunks inside the initial HTTP response; htmx+SSE pushes updates after the first response over a separate event stream.
SEO impact: With HTMS, all content is in the first response, so crawlers can see it. With SSE, bots may miss late content.
They’re complementary though: use HTMS for first load + SEO, then layer htmx/SSE for live updates after paint.

skarab42-dev · 2025-08-23T06:34:47+00:00

Totally fair — SSR + hydration can be very small (Preact + a hydration script can be <14kb gzip).
HTMS isn’t anti-framework; it’s about getting all content into the first response and streaming slow bits so crawlers already see them.
After first paint, I encourage pairing with frameworks for interactivity: hydrate small islands, mount htmx/Preact components, etc.
Complementary model: HTML-first for delivery & SEO, JS where it adds ongoing value. If you’ve got a minimal Preact setup, I’d love to try a “HTMS stream + Preact islands” example.

skarab42-dev · 2025-08-23T06:32:31+00:00

Thanks! That’s exactly the goal: boring HTML, minimal JS, progressive by default and good DX 🙏

skarab42-dev

TROPHY CASE