avatar
Lea Verou, PhD @lea.verou.me

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.

aug 23, 2025, 3:34 pm • 3 0

Replies

avatar
Jake Lazaroff @jakelazaroff.com

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

aug 23, 2025, 3:44 pm • 0 0 • view
avatar
rich harris @rich-harris.dev

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 afterwards

aug 23, 2025, 3:50 pm • 3 0 • view
avatar
Jake Lazaroff @jakelazaroff.com

we 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

aug 23, 2025, 4:04 pm • 0 0 • view
avatar
Lea Verou, PhD @lea.verou.me

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).

aug 23, 2025, 4:09 pm • 1 0 • view
avatar
Lea Verou, PhD @lea.verou.me

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.

aug 23, 2025, 4:11 pm • 2 0 • view
avatar
Lea Verou, PhD @lea.verou.me

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.

aug 23, 2025, 4:13 pm • 2 0 • view
avatar
Lea Verou, PhD @lea.verou.me

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.

aug 23, 2025, 4:14 pm • 2 0 • view
avatar
rich harris @rich-harris.dev

So the user initially sees markers like this?

Hello {{name}}

Or there's some some DSL like this?

Hello Lea

Is that DSL hand-authored, or SSR'd by the same tool?

aug 23, 2025, 3:37 pm • 0 0 • view
avatar
Lea Verou, PhD @lea.verou.me

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.

aug 23, 2025, 3:42 pm • 1 0 • view
avatar
Lea Verou, PhD @lea.verou.me

SSR tools *could* generate it too, but that's orthogonal, as long as the syntax is designed with hand-authoring DX in mind.

aug 23, 2025, 3:42 pm • 1 0 • view