Reading the other responses, I see where the confusion may be: By client-side only I was referring to not requiring a build step, nothing to do with routing. AFAIK SSR is part of the core philosophy of the project, which is counter to anything without a build step. Is that not the case?
i would say the core philosphy of svelte (sans kit) is precompilation into vanilla js as opposed to say a superset like jsx
You're conflating separate things — whether something requires a build step is nothing to do with whether it works client-side. Routing is a separate consideration altogether. We encourage SSR (via SvelteKit) because that's the right way to build resilient, performant apps. Not required though!
It's not totally clear what you're asking for — should the initial DOM also serve as the reactive template? Because that feels impossible. Is the template separate? Which is the source of truth? You're asking for _hydration_, but I'm not aware of any systems that can hydrate HTML they didn't create
Precisely that! Hydrate HTML that was already there (through Vue-like annotations about where data goes). JS would be the source of truth for the *data*. Important: I'm not suggesting this as the right approach for everything or even most things. Just that these cases exist and are not niche.
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 afterwards 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
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.
Not 100% what you're looking for, but there's some interesting nuggets here github.com/ChrisShank/p.... My favorite takeaway here is annotating the markup with "event intentions", and then orchestrating the events in single place via event bubbling.
I would guess Preact is closest to what you want — you can SSR then hydrate, and if you don't mind using htm you can do it all without a build step preactjs.com/guide/v10/no... But it sounds like you'd be better off just leaving a gap in the HTML and filling it with JS. Worse user experience though
yes with some effort you can kinda get svelte to run clientside without a build but its not really made for that i would just use lit in this case, or preact: preactjs.com/guide/v10/no...
Yes, these may not need a build step, but they don't fit the other requirements.
Interesting 🤔 which requirements don't they fit?
Reactive templating and preserving DOM nodes (outside loops). I literally mentioned lit-html and React (Preact has the same issue AFAIK) in the 3rd post.
you did. seems strange though since lit doesn't nuke the dom when props change. it updates attributes, text nodes, etc individually
Yes, same for (p)react, Vue etc. The difference is it's on nodes *they* created, not nodes that were already there. So if anything else depends on nodes that were already there, you run into timing issues.