E.g. mostly static content where a static site generator works fine, with a few dynamic islands that you want to be able to manage with good DX without affecting the architecture / build process of the whole site.
E.g. mostly static content where a static site generator works fine, with a few dynamic islands that you want to be able to manage with good DX without affecting the architecture / build process of the whole site.
can you run the dynamic island template on the server as well to generate the initial HTML? then it wouldn't really matter whether the client-side part replaced the DOM since it would all be driven by the same template anyway
IIUC the complaint is that replacing the DOM will also replace anything that was already put inside the DOM by something else, like
but honestly the answer is 'don't do that'. mount that stuff afterwardswe might be saying the same thing in different ways. what i mean is — instead of e.g. rendering a D3 chart on the server and then using svelte to try to make the HTML interactive on the client, render the D3 chart within svelte and then render that svelte component on the server and hydrate normally
A lot of this depends on the assumption that a single entity has full control over everything. That's not always the case (and I'd argue isn't even desirable — capability for composability is a good thing).
The example that prompted the OP: I was switching an old website to Vue so its UI update code can be more manageable. It used Carbon ads, which broke, as their script was making assumptions about the DOM that were no longer true. I now have to use a Vue component for Carbon ads. This doesn't scale.
Sure, you could argue that their script shouldn't be making these assumptions. Maybe they should have used WC so they work with every framework. But the reality is, there are a lot of UI scripts and libraries out there that make assumptions don't play work with what current frameworks do.
And yes, I could have just switched to using the framework to SSR everything and manage everything and maybe that wouldn't be a problem anymore. But that feels like a very blunt instrument. Often these things are tangential to what the rest of the website does.
So the user initially sees markers like this?
Either or both, they have different tradeoffs, as you know :) The latter is more verbose, but can facilitate better loading experience, if crafted well. Vue missed the opportunity there because it complains when there is HTML content too. It sees is as a mistake, not a deliberate fallback.
SSR tools *could* generate it too, but that's orthogonal, as long as the syntax is designed with hand-authoring DX in mind.