Re: [whatwg/dom] Declarative Shadow DOM (#831)

> This seems like a _general_ issue - any time you have declarative content and a separate set of code to create it, they can get out of sync. Suggestions appreciated here.

Forgive me if you know all of this, but just to be clear, the core idea of React SSR+hydration is:

1. compute a virtual DOM on the server side and render it as HTML
2. compute a vDOM on the client side (this regenerates the component structure of the HTML but doesn't actually touch the DOM, which would be slower)
3. quickly verify that the SSR HTML matches the client-side vDOM (e.g. by computing a hash code of the SSR vDOM and storing it in the HTML, then checking that hash code against the hash code of the CSR vDOM)
4.
    a. If the vDOM matches the HTML, attach event listeners to the existing elements; now the page is interactive.
    b. If the vDOM mismatches the HTML, the client-side render will blow away the SSR HTML, which is just what you have to do in event of mismatch.

4b is not "supposed" to happen; the developer is supposed to provide the same state data on the server side and the client side, ensuring that the SSR vDOM matches the CSR vDOM. If the developer provides different data on the client and server, that's performance a bug that the developer can/should fix, but the result is _just_ degraded performance, not a catastrophe. (It will often result in a flash of SSR content replaced by CSR content.)

With all that in mind, I'd like to reiterate [Rich's earlier comment](https://github.com/whatwg/dom/issues/831#issuecomment-586407187).

Rich pointed out that WCs can't make any assumptions about whether SSR HTML will exist or not.

• By default, all existing WCs out in the wild will presumably do the slow/bad thing and just throw away the SSR'd HTML during the `connected` callback. That's slow because it throws away perfectly good SSR HTML, and it's also bad because it replaces the SSR HTML with new identical CSR HTML, erasing form state, focus state, etc.
• WC authors could implement a very poor vDOM by just by assuming that the SSR HTML will match the CSR HTML and using `querySelector` to find elements and attach event handlers to them. But that's very fragile, because you _might_ have mismatching HTML, and if you do, `querySelector` might not find the right element(s). The React approach is to require all components to participate in vDOM, supporting fast SSR verification, but to do that for WCs, it would require standardizing vDOM in the browser, which sounds like a Herculean task to me.

I interpreted [your reply](https://github.com/whatwg/dom/issues/831#issuecomment-586422247) as "In that case, just don't SSR! You can leave the SSR HTML blank." I believe Rich understood your reply the same way I did. Rich pointed out that in that case we'd (of course) lose the benefits of SSR, "But then you'd have to wait for the JS to load and run before seeing any content!"

I think the overall moral of this story is that it will be very hard to beat non-WC hydration, which is why it would be prudent to prototype WC hydration sooner than later.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/831#issuecomment-586565905