Is svelte not client side? I'm genuinely out of the loop, last I used it you needed sapper for SSR, I'm vaguely aware of sveltekit, but not familiar
Replies
svelte is the templating library that works exclusively client side, svelte kit is the additional routing framework
aug 23, 2025, 2:09 pm • 1 0 • view
Yeah that's my impression, I was wondering if newer versions of svelte only supported sveltekit, but I just went to check the docs and seems like it's just as before, and instead of sapper we use sveltekit
aug 23, 2025, 2:13 pm • 1 0 • view
yeah youre correct here
aug 23, 2025, 2:14 pm • 1 0 • view
bsky.app/profile/lea....
aug 23, 2025, 3:01 pm • 1 0 • view
Last I checked @svelte.dev did not have a client-side version, I believe it goes against the philosophy of the tool completely.
aug 23, 2025, 1:53 pm • 3 0 • view
Going through the new tutorials I believe the section on basic svelte is client side only, it'll compile into js which you can serve statically. you can also create a basic svelte project with vite, not sveltekit (apologies in advance if I'm over explaining, wanna make sure we're on the same page)
aug 23, 2025, 2:08 pm • 1 0 • view
bsky.app/profile/lea.... (also, ❤️ at the "apologies if I'm over explaining")
aug 23, 2025, 3:00 pm • 1 0 • view
What do you mean it doesn't have a client side version? Svelte is primarily a client side UI framework, SSR is baked in as a first class citizen and you can get it easily with sveltekit but it absolutely has client side reactivity
aug 23, 2025, 1:55 pm • 1 0 • view
bsky.app/profile/lea....
aug 23, 2025, 3:00 pm • 2 0 • view
I would be interested to know how you ended up with this impression so that we can fix it!
aug 23, 2025, 2:48 pm • 7 0 • view
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?
aug 23, 2025, 2:58 pm • 1 0 • view
i would say the core philosphy of svelte (sans kit) is precompilation into vanilla js as opposed to say a superset like jsx
aug 23, 2025, 3:04 pm • 1 0 • view
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!
aug 23, 2025, 3:17 pm • 5 0 • view
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
aug 23, 2025, 3:17 pm • 6 0 • view
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.
aug 23, 2025, 3:31 pm • 5 0 • view
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 • view
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
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
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
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
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
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
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
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.
aug 23, 2025, 6:29 pm • 0 0 • view
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
aug 23, 2025, 3:17 pm • 2 0 • view
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...
aug 23, 2025, 3:06 pm • 3 0 • view
Yes, these may not need a build step, but they don't fit the other requirements.
aug 23, 2025, 3:08 pm • 1 0 • view
Interesting 🤔 which requirements don't they fit?
aug 23, 2025, 3:16 pm • 1 0 • view
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.
aug 23, 2025, 3:23 pm • 1 0 • view
you did. seems strange though since lit doesn't nuke the dom when props change. it updates attributes, text nodes, etc individually
aug 23, 2025, 3:50 pm • 0 0 • view
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.
aug 23, 2025, 4:06 pm • 0 0 • view