Qwik is really interesting. Initially the page is rendered server-side, then sent to the page. But what happens is very unlike most we apps, which then have to

Qwik is really interesting. Initially the page is rendered server-side, then sent to the page. But what happens is very unlike most we apps, which then have to re-run most of the app to hydrate: > Qwik is different because it does not require hydration to resume an application on the client. Not requiring hydration is what makes the Qwik application startup instantaneous. > All other frameworks' hydration replays all the application logic in the client. Qwik instead pauses execution in the server, and resumes execution in the client. https://qwik.builder.io/docs/concepts/resumable/ https://qwik.builder.io/docs/concepts/resumable/ It stores state in the DOM tree in a way that lets it "resume" running. If you click a link, a top level handler can recurse down the page to find listeners. It can gather any extra state & on the fly spin up components needed by the handler. In general I think the topic of serializing & exposing application state is a vast untapped trove of awesomeness that compsci could be mining. 9p is the best reflection we have. But we also see a steady stream of git-based data projects coming out, that also reflect the value of serializing your state in a valuable way. The twist here of using serialized app state, baked into the DOM, to allow instant resumability is awesome. On-demand paging back in state is like live migrating a vm or user process, just an awesome feat that redefines the computing model in such a more open way. Congrats on your 1.0!