Rendered at 02:58:40 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
poetril 9 minutes ago [-]
After far too many hours using react, Svelte has become my favorite frontend framework. I’m seeing a lot of comments about how it stacks up in the LLM age. Prior to Opus 4.6-8 (and that era of model releases) they often struggled to get Svelte 4/5 code straight and mixed it up quite a bit.
But having used it A LOT this year for personal projects, large work initiatives, and one-off web tools. I’m happy to say all the modern llms seem to do just fine with it. They even handle the experimental features, like remote functions, very well. It’s mostly preference but I find reading Svelte code much more pleasant than React/Vue.
jamies 4 hours ago [-]
Such a great project. I converted my React-enjoying cofounders to Svelte/SvelteKit worried they wouldn't like it, but they absolutely love it!
We use Svelte extensively at Orb.net for our website (duh), but also as a framework for our desktop and mobile apps. Wails serves our golang and SvelteKit/Svelte provide the UX. It's been tremendous for multiplatform productivity, and binaries are less than 20mb! Nothing like Electron!
OzzyB 3 hours ago [-]
+1 for Wails mention: just discovered it recently which brought me to Svelte--couldn't be more impressed. Golang "backend" w/ a Svelte "frontend" to build desktop apps the fraction of the size of Electron is a killer imo.
stillatit 2 hours ago [-]
I love the hands-on developer experience of programming in Svelte. But since we're in October of 2026 I have to ask, is the vibe-coding experience in Svelte any different than in React? Can anyone with experience in both comment?
weitendorf 1 hours ago [-]
Yes. We open sourced an SSG based off SvelteKit about a year ago and were starting building AI tooling and product workflows around it, https://statue.dev but have since mothballed it.
For most of 2024-2025 frontier models really struggled with Svelte 4 vs 5 compatibility issues. Some of the main contributors, to their credit, really put in a lot of work to create benchmarks/MCP/other tools to make AI better at using Svelte. Personally I am just not a fan of MCP and other tools like that at all, and decided I'd rather just use vanilla css/js for new projects.
Look at this; it's literally multiple times more expensive to have a model sifting through all this stuff in every context use them with a tool: https://svelte.dev/docs/ai/prompts/llms.txt All of these are input tokens and turns to gather context.
The "too niche to be a major training priority" dilemma is actually a really big problem that almost all new or emerging dev tools have now. Incumbents and category leaders are priorities and show up in major benchmarks, so models develop excellent tacit knowledge and capabilities with them and expose it everywhere all the time for "free" in their weights. Everything else is at a major disadvantage because models don't know about them, how to use them, how they work, what they're for/why, and every time you use them you pay a big capability and token hit because models only learn about them in-context.
I don't blame the Svelte team for this at all. There should be a better way for devtool projects to contribute to frontier labs training pipelines or properly posttrain their own agent coding models.
scosman 22 minutes ago [-]
I would have said no different. I've always loved Svelte and the amazing dev-experience and perf was worth the smaller ecosystem. Models were very good at it, I was happy.
Then I got a model to one-shot a React+Shadcn project. It just knew what to do. Every detail was perfect. I couldn't find a single thing to complain about, I didn't chase any bugs.
I still think svelte is the better technology and developer experience (if you're coding by hand). But the React experience was amazing. Hoping models close the gap fully so I can stay w Svelte -- I do still like reading and tweaking the code.
weaksauce 38 minutes ago [-]
i'd expect the fact that svelte doesn't have a shadow dom that gets recomputed all the time that it would be a significant performance and memory benefit for most apps. i'm not an expert though so idk if that's 100% accurate
avarun 2 hours ago [-]
Exact same. I was a huge user of SvelteKit from 2022 to early 2025. But ever since LLMs got good enough I went back to React, because the ecosystem size matters a lot more once the coding experience is automated away. And early models were much much better at React than they were at Svelte – I suspect that difference may be gone now but is there a good reason to switch back to Svelte?
brachkow 2 hours ago [-]
In early 2026 I struggled a lot with models messing Svelte 4 and Svelte 5. I'm sure same thing will occur with load function vs remote functions, once they will be released
smt88 29 minutes ago [-]
I’ve used both in vibe coded side projects, so the caveat is that it’s entirely personal use.
Opus 4.8+ did fine with SvelteKit and I didn’t notice much difference with token usage vs. React.
I will say that I have heavily prompted my agents to read current docs for all libraries, whether in their training set or not. So my agents read React docs even if their training set is full of React code.
killingtime74 4 hours ago [-]
The thing I like about Svelte the most is that it's closer to raw HTML. Rather than having to keep up with all the React developments if you're not using it all the time.
escapecharacter 1 hours ago [-]
yes! I learned React first, and then Svelte. Svelte seems to have all the benefits without any of the React abstractions that are more pain than they’re worth.
blakeashleyjr 5 hours ago [-]
Sveltekit has been a breath of fresh air for me over the last few years.
I've had to work on a Next.js for work and much prefer Sveltekit. Excited to try this release!
383toast 4 hours ago [-]
what's the point of svelte in a world where the llm is much better at react due to massively more available training data?
pampas 4 hours ago [-]
I don't think that's true anymore. I've seen a few benchmarks where svelte results in less tokens than React frameworks to complete the task. There was a time when LLMs were awful at svelte (especially v5) due to stale knowledge but that's not the case today. The knowledge cutoff isn't so bad and LLMs are much better at copying the patterns in your own codebase rather than relying on baked in knowledge.
In my experience LLMs write mediocre React code: it works, but is the most naive implementation possible for a given task. It needs to be bullied extensively to write performant React that considers prop stability, does updates in event handlers instead of convoluted useEffect chains, etc. I haven't tried Svelte in a while but "lots of React in training data" doesn't feel like a huge boon to me.
casper14 4 hours ago [-]
Tells you something about the average React code
ceejayoz 3 hours ago [-]
Or that there are a lot of very basic React tutorials out there.
Like how half of PHP's problem for a while was w3schools.
jack_pp 8 minutes ago [-]
tutorials are probably less than 0.1% of the training data compared to actual code, or you mean average project is influenced by basic tutorials?
DonHopkins 3 minutes ago [-]
More than half of PHP's problem was PHP's own online manuals that allowed any Bozo to confidently post idiotic answers and copy other Bozo's idiotic confident answers. It's not like confident idiocy is a new thing with LLMs -- they were trained on it.
meowface 2 hours ago [-]
It's actually the opposite now. I have never used Svelte until LLMs came around. LLMs are better at writing Svelte than React, and then you also get a faster frontend by default.
It's like Rust. Way more Python than Rust in the training data, but with LLMs you're much better off defaulting to a Rust backend and Svelte frontend than any other combination. I'd say "unless you have a specific reason", but besides legacy requirements, there is actually no reason.
alpha_squared 4 hours ago [-]
This seems like flame bait, but I'll take the question seriously: I would rather write a Svelte application by hand than manage a React one via LLM. It's just a more intuitive framework, fewer pitfalls, cleaner reactivity, and is much more performant out of the box.
zem 4 hours ago [-]
every time I see this argument I think of the fact that one of my current side projects is written in D with qt bindings off github - an obscure library for an obscure language - and claude had zero issues with it. I had to guide the architecture pretty heavily, but the fiddly bits of interfacing multithreaded c libraries to D's garbage collector and qt's event loop were all thanks to the LLM, and done a lot quicker than I would have.
digitaltrees 3 hours ago [-]
There is an argument to choose the ecosystem with the best code quality so the training data pushes the general balance to better systems. There is a lot of bad react code not to mention lots of change in react itself over time.
aoeusnth1 2 hours ago [-]
What's the point of using a slow frontend framework just because you're familiar with it, instead of a fast frontend framework which the LLMs can write equally well (or better)?
Recursing 4 hours ago [-]
In my experience LLMs write better svelte code then React code, as there's fewer footguns (e.g. useEffect is much more brittle in React)
smt88 26 minutes ago [-]
This is interesting but in my experience an avoidable issue if you force the LLM to write extensive E2E tests before writing any code. I also force mine to run performance benchmarks against any new commit before it’s committed.
I have backend bugs that I need to manage myself, usually from unknown-unknowns that I don’t think I can easily avoid, but I never have frontend bugs (since Opus 4.6 anyway).
byzantinegene 28 minutes ago [-]
svelte is like go, and react is like javascript. alot easier to write non-performant javascript then non-performant go.
afavour 3 hours ago [-]
IMO a lot of React apps are written badly, with an explosion of dependencies. I don’t want to be responsible for a project trained on that.
onemoresoop 2 hours ago [-]
React is a resource hog on the client. I really dislike it as a user. In terms of maintaining a codebase though, with LLMs it’s probably not a problem anymore with all the changes React keeps on undergoing. But if you don’t need it why bother with it?
transdev12 4 hours ago [-]
I can’t really speak directly to your question because I don’t have LLMs write react, but I get great results from svelte.
At this point I don’t think it’s about training examples, once there is sufficient training data it becomes a problem of verifiability, ie how easily can the model check its work for success.
theflyinghorse 3 hours ago [-]
I don't think LLMs are much better at react. I've migrated two apps from next to sveltekit and it was a breeze using codex.
stevenhubertron 3 hours ago [-]
LLMs are great at Svelte
sampsn 4 hours ago [-]
i have had similar thoughts. But i hold on to the idea that its still valuable to invent new tools and ways of doing things. other wise, why not just use html css and javascript and not use react at all?
winfredJa 4 hours ago [-]
svelte is way more performant than react.
esafak 4 hours ago [-]
LLMs don't struggle with Svelte. Why wouldn't you use it?
nozzlegear 4 hours ago [-]
What's the point of anything?
chrysoprace 3 hours ago [-]
Been using SvelteKit 3 on a couple of personal projects since the beta and haven't had any issues. The best part is that it barely introduces new features and instead improves on existing features.
sghiassy 2 hours ago [-]
Does anyone care anymore?
Honest question? Whatever the agent is best at programming out to achieve a high quality outcome works for me. Just write the acceptance tests and be done with it
drewbitt 1 hours ago [-]
In the last 3 months svelte + kit have had 302 issues and 1,107 PRs opened (802 merged), 512 distinct humans opening/commenting/committing, and almost 100 unique code contributors. So yes, people care.
goolz 1 hours ago [-]
For what it is worth, I care, if only for the simple fact that it is an interesting project.
jesse_dot_id 2 hours ago [-]
SvelteKit has incredible DX. I use it for everything these days.
ramijames 3 hours ago [-]
I migrated from Nuxt to SvelteKit last year and never went back. It's great.
CharlesW 1 hours ago [-]
Can you say more? I’ve been getting great results with Nuxt and Nuxt UI, and I’m having a hard time thinking of ways SvelteKit would be worth the switch.
argentinian 3 hours ago [-]
Can somebody with experience using both compare Svelte/Sveltekit with Vue/Nuxt?
1. Svelte is a good framework, but most of the DX praise comes from React folk. In my experience, Svelte is less polished and less comfortable to work with than Vue.
2. The biggest problem with Vue is that your choice of SSR frameworks is limited to Nuxt, and Nuxt is, to put it mildly... not a good framework. It is full of reinventing the wheel, ambiguity, and foot guns. In my experience, I regretted every project I used Nuxt for.
As I needed good SSR, SvelteKit was a breeze: everything just renders on the server when I want it to, proper client/server separation, MVC-looking code.
3. Svelte has way lower adoption than Vue, not to mention React. So there are not many 3rd party libraries, and even important tools like Storybook or ESLint struggle with it.
It also tends to switch syntaxes a lot. Even this announcement contains a mention of switching from +page files to queries. This hurts AI usage a lot.
As a conclusion: A year ago, I would say that you should pick Svelte where SSR is critical, and stay on Vue for the rest. But as we have https://inertiajs.com/ right now, you can do SSR of any complexity in Vue + any backend you have.
phoghed 1 hours ago [-]
I used mainly Vue from 0.12 until 3 (migrated one project to 3 but didn’t work with it extensively), with a bit of react sprinkled in. Mainly react the last 4 years or so, which let’s be honest is mainly not me writing the code.
I tried Svelte a couple times over the years, never really clicked for me though.
sharktheone 6 hours ago [-]
Still waiting for remote functions to become ready :/
chrysoprace 4 hours ago [-]
They're effectively ready to use even if experimental; the migration path is typically pretty painless when features are stabilised and the codemods get you most of the way. There's a couple of missing features for them but if you don't need those then it's not a problem.
nlh 3 hours ago [-]
I've been using them in production for several months and zero issues. A few small workarounds here and there but otherwise they've been great.
pampas 4 hours ago [-]
I've had no problem using them in 2.x
cassepipe 4 hours ago [-]
What was used instead before ?
chrysoprace 4 hours ago [-]
The idiomatic way to do data fetching in stable SvelteKit is via load functions.[0]
They still do a good job and allow you to cache the results and invalidate that cache, but they are at a route/layout level rather than at a component level, which is what remote functions solve.
i don't use svelte/kit for technical reasons, but there is no doubt they have the best developer experience of all the js frameworks, it's well-considered and coherent. they have the most aura for sure.
tamimio 3 hours ago [-]
A couple years ago I wanted to make a ui for an embedded software I made, after few research I got bamboozled with webdev eco system, it was the most frustrating thing to read, then found svelte in its first version and never looked anywhere else, the closest to vanilla, simple, and fast.
But having used it A LOT this year for personal projects, large work initiatives, and one-off web tools. I’m happy to say all the modern llms seem to do just fine with it. They even handle the experimental features, like remote functions, very well. It’s mostly preference but I find reading Svelte code much more pleasant than React/Vue.
We use Svelte extensively at Orb.net for our website (duh), but also as a framework for our desktop and mobile apps. Wails serves our golang and SvelteKit/Svelte provide the UX. It's been tremendous for multiplatform productivity, and binaries are less than 20mb! Nothing like Electron!
For most of 2024-2025 frontier models really struggled with Svelte 4 vs 5 compatibility issues. Some of the main contributors, to their credit, really put in a lot of work to create benchmarks/MCP/other tools to make AI better at using Svelte. Personally I am just not a fan of MCP and other tools like that at all, and decided I'd rather just use vanilla css/js for new projects.
Look at this; it's literally multiple times more expensive to have a model sifting through all this stuff in every context use them with a tool: https://svelte.dev/docs/ai/prompts/llms.txt All of these are input tokens and turns to gather context.
The "too niche to be a major training priority" dilemma is actually a really big problem that almost all new or emerging dev tools have now. Incumbents and category leaders are priorities and show up in major benchmarks, so models develop excellent tacit knowledge and capabilities with them and expose it everywhere all the time for "free" in their weights. Everything else is at a major disadvantage because models don't know about them, how to use them, how they work, what they're for/why, and every time you use them you pay a big capability and token hit because models only learn about them in-context.
I don't blame the Svelte team for this at all. There should be a better way for devtool projects to contribute to frontier labs training pipelines or properly posttrain their own agent coding models.
Then I got a model to one-shot a React+Shadcn project. It just knew what to do. Every detail was perfect. I couldn't find a single thing to complain about, I didn't chase any bugs.
I still think svelte is the better technology and developer experience (if you're coding by hand). But the React experience was amazing. Hoping models close the gap fully so I can stay w Svelte -- I do still like reading and tweaking the code.
Opus 4.8+ did fine with SvelteKit and I didn’t notice much difference with token usage vs. React.
I will say that I have heavily prompted my agents to read current docs for all libraries, whether in their training set or not. So my agents read React docs even if their training set is full of React code.
I've had to work on a Next.js for work and much prefer Sveltekit. Excited to try this release!
Edit: This is the benchmark. But if you suspect it's wrong it's always fun to run your own evals. https://martinalderson.com/posts/which-web-frameworks-are-mo...
Like how half of PHP's problem for a while was w3schools.
It's like Rust. Way more Python than Rust in the training data, but with LLMs you're much better off defaulting to a Rust backend and Svelte frontend than any other combination. I'd say "unless you have a specific reason", but besides legacy requirements, there is actually no reason.
I have backend bugs that I need to manage myself, usually from unknown-unknowns that I don’t think I can easily avoid, but I never have frontend bugs (since Opus 4.6 anyway).
At this point I don’t think it’s about training examples, once there is sufficient training data it becomes a problem of verifiability, ie how easily can the model check its work for success.
Honest question? Whatever the agent is best at programming out to achieve a high quality outcome works for me. Just write the acceptance tests and be done with it
In short:
1. Svelte is a good framework, but most of the DX praise comes from React folk. In my experience, Svelte is less polished and less comfortable to work with than Vue.
2. The biggest problem with Vue is that your choice of SSR frameworks is limited to Nuxt, and Nuxt is, to put it mildly... not a good framework. It is full of reinventing the wheel, ambiguity, and foot guns. In my experience, I regretted every project I used Nuxt for.
As I needed good SSR, SvelteKit was a breeze: everything just renders on the server when I want it to, proper client/server separation, MVC-looking code.
3. Svelte has way lower adoption than Vue, not to mention React. So there are not many 3rd party libraries, and even important tools like Storybook or ESLint struggle with it.
It also tends to switch syntaxes a lot. Even this announcement contains a mention of switching from +page files to queries. This hurts AI usage a lot.
As a conclusion: A year ago, I would say that you should pick Svelte where SSR is critical, and stay on Vue for the rest. But as we have https://inertiajs.com/ right now, you can do SSR of any complexity in Vue + any backend you have.
I tried Svelte a couple times over the years, never really clicked for me though.
They still do a good job and allow you to cache the results and invalidate that cache, but they are at a route/layout level rather than at a component level, which is what remote functions solve.
[0] https://svelte.dev/docs/kit/load