prerender VS kyoto

So then just to experiment, I set up https://github.com/prerender/prerender on my own VPS in like an hour... and done & dusted... no more effort needed to think about SSR issues anymore. Seems great, and I can't figure out why it's not more popular.

Spending like 1 hour setting up prerender on my server is much preferable to the ongoing issues that come with having to make all my code work with SSR frameworks. And there's the added bonus that my servers don't need to waste resources doing SSR for regular human users.

Here’s an alternative that I use: https://prerender.io and GH is https://github.com/prerender/prerender

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/92.0.4512.0 Safari/537.36 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/91.0.4472.114 Safari/537.36 Prerender (+https://github.com/prerender/prerender) ...

Ah, I didn't realize this wasn't solved -- a quick search turns up:

- https://github.com/WICG/webcomponents/issues/788

- https://github.com/w3c/DOM-Parsing/issues/58

- https://github.com/w3ctag/design-reviews/issues/494

- https://web.dev/declarative-shadow-dom

In pre-render they seem to have started in this direction extremely recently:

https://github.com/prerender/prerender/pull/731/files

I don't use prerender so I can't definitively speak to it being solved and hiccup-free, but I think that limitation is going to go away in the future.

Using something like: https://github.com/prerender/prerender

Have you used prerender - https://github.com/prerender/prerender ? Seems to be doing the same thing.

the only thing i need to do is port the htmx code to golang and then cross compile to wasm for web and then to mobile and desktop. I am currently seeing that there are other htmx style systems out there that are already written n golang. for example: https://github.com/kyoto-framework/kyoto

But this baby here https://github.com/kyoto-framework/kyoto is in the early development stages, which is a nice approach imho.

htmx requires you to return markup for specific components. So, you’ll need to maintain component template definition in two ways: embed directly into page template, and serve it as an api. IMO htmx is cool, but requires some tooling around it to simplify work. Our team is developing and using kyoto library, focused on server rendering and components approach: https://github.com/kyoto-framework/kyoto