Build system for creating a static site?

[torrinworx]

I've been thinking about a feature that would help SEO sort of like Next.js does with its ssg. The thought is to make stupid simple builder that snaps a static version of the site during the build process. This wouldn't be anything too fancy, just something that captures the initial rendered state of the components and spits out straightforward static HTML from that.

The aim here is to keep everything lean, using basic string operations or minimal adjustments to existing destam-dom functions, so it stays true to minimal bloat. This way, we could generate two versions of a page, one dynamic version for users and another stripped-down html static version that’s friendlier for search engines and users with JS disabled.

I think this could really help with landing pages and SEO without increasing the libraries footprint by much. I don't really have the know how on if this is a good idea or if you could already do this with npm scripts or something, so making this a feature could be overkill

[Nefsen402]

This is called server side rendering. There are a couple of things needed to get this working:

1. Server components. These are components that can be run on the server and these are used to first generate the static content that is served as the initial request.
2. Hydration. Once the server side rendered content has made it to the client, it is up to the client code now to take that server side generated tree and associate that with client side rendered content.

Most existing solutions today use really complex build system steps to basically at build time create all the machinery required for this. As the library stands currently, destam-dom can be used withoun any sort of build step so really I'd like to be able to keep it that way even for server side rendering.

The current solution I have in my head is to write a version of dom.js that is re-implemented to instead run on the server. This is designed to basically render components on the server side with the same API as the client (plus native support for promises) that will generate an HTML file so that you can serve it. Then some magic on the client side will see the HTML, see identifiers that the server side conveniently added and associate that with the client tree.

This should ideally happen without build steps but that doesn't mean we can't have more complex build systems to optimize the base system.