Server-side rendering and static websites support

[MaxDesiatov]

It would be great if Tokamak supported rendering to a static HTML string without requiring DOM access, similar to what React already can do (and numerous other JS libraries probably too). There are many use cases for this, the most beneficial would be to pre-render your Tokamak app into a static HTML, serve that by default, and then hydrate that after the WebAssembly binary is loaded. This is beneficial for performance and usability as a user wouldn't need to wait for the WebAssembly module to be loaded and compiled before they can see anything useful on a web page.

Additionally, many static websites (such as blogs) wouldn't need components that utilize @State, those wouldn't need a WebAssembly binary at all, pre-rendered HTML would be enough. Of course, you could write your HTML by hand, but the abundance of React-based static websites generators (such as Gatsby) proves that it is nice to be able to reuse your existing code. Additionally, views described with Tokamak (even without any @State and other stateful property wrappers) clearly compose better than plain HTML.

I think this could look like a separate TokamakHTML module that doesn't depend on JavaScriptKit and could be compiled for any platform, not just WebAssembly. Then you'd supply any view to this HTML renderer and get an HTML string as an output. I hope that TokamakHTML could then be reused in the TokamakDOM module.

[carson-katri]

pre-render your Tokamak app into a static HTML, serve that by default, and then hydrate that after the WebAssembly binary is loaded

SwiftUI will be getting a isPlaceholder modifier in a future beta, used with WidgetKit for creating the loading state. It basically replaces the text/images with rectangles. Maybe something like this could be used for the initial load?

[MaxDesiatov]

Oh, that would be amazing if we can get there, totally would make sense to use that for interactive elements, while non-interactive could be loaded instantly as pre-rendered HTML. I think supporting just simple rendering of arbitrary views without @State to an HTML string would be a signifcant first step, enabling things such as static websites (I'd be happy to dogfood it on my own website for example), maybe providing integrations with other frameworks such as Publish. Then we can get to more advanced cases like hydration with placeholders after that, I think.