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.
Svelte changed things up at every single version so that's what you get. I've been a fan/hater since v1. For me Claude still tried to write "export let" for props even if I specify Svelte 5 at times.
Yes, you're right, although there was a lot of churn in SvelteKit when it was in beta--maybe they had that in mind. Of course, it was marked as a beta, so it's hard to blame them too much. But I was using Kit heavily during that period and ended up getting frustrated by the whiplash, and then the addition of runes (which was announced in late 2023 even if it wasn't released until 2024) was what made me lose interest in Svelte. I still have some fondness for the framework though.
They explicitly mention that Svelte hasn't changed much since version 3? Svelte 5 did introduce runes but, as you say, still kept legacy code compatible.
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!
+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.
Not sure, never heard of it, but looking at the README it seems similar but w/ a Rust backend?
We do a lot of data/quant analysis w/ Go which is great for that; then having the opportunity to slap on a lightweight GUI allow us to make some great internal tools etc.
The speed is what I love about Svelte websites. I checked out orb.net; the pages load instantly! I rarely see that with websites built with other frameworks.
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?
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
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?
A good reason to use svelte instead of React is performance. LLMs not only got us more convenient development but also users that use their hardware for longer since the prices are so high.
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.
This is why I switched to Astro/React in 2024. I wonder where I would be now if I had stuck things out. Svelte is very fast and elegant. I found that I can use Astro for anything I thought I might need NextJS for though.
I still use Svelte but I switched to Astro too. I think the best thing about it is that its devs are focused on building primarily a good ssg.
The Svelte people are primarily building a frontend framework and added sveltekit as an addition. Using Svelte in astro even feels nicer to me.
I strongly recommend vanilla html, js, and css. For me the benefits of having no npm and related ecosystem tools and no dependencies far outweigh any benefits you get from switching to specific framework. It took me just as long to learn modern css, html, and basically all the browser APIs as it did to learn how to setup+build+modify+deploy my svelte-vscodeextension-webview project without getting bogged down in the tooling.
All those tools and packages are constantly making breaking changes or introducing incompatibility issues or becoming obsolete, and there is so much maintenance. I went pretty deep on CSR/SSG/browser automation over the past two years and realized that everything you get out of these tools is probably 20-400 lines of javascript you could just ask an LLM to implement when you need it. I’ve seen people waste so many hours, days, and weeks on tailwind ui crap (solvable in minutes with css), vitest and object lifecycle crap (use the browser debugger, do e2e tests) and major version upgrades (there’s about 95% less of this in the browser and >99% less outside experimental APIs).
I think for Facebook/Github sized web applications, with really big teams and lots of custom tooling (eg React) these frameworks make sense. Most websites just need basic file serving/rendering, to send and respond to http requests, and some javascript to run on the client (but html and css can actually handle many core UI patterns). I’ve been much happier not using frameworks because my projects just work and the knowledge I build doesn’t constantly churn.
We had an existing sveltekit application and its components, tooling, etc and used statue to develop the landing page/legals/docs/marketing portion of our site as an SSG, deployed separately but with shared logic.
Our application was behind a proxy that requires auth, and we could host our SSG on Cloudflare pages, so we didn’t have to expose any application server/compute (besides auth) to the public Internet. To me this was very desirable for security and devex: we could develop the two applications independently and be pretty lax with the static site.
> and decided I'd rather just use vanilla css/js for new projects.
So is the rise of AI coding, the end of frameworks?
Frameworks were created to reduce boiler plate ( at the expense of new abstractions which occasionally leak ) - boiler generation is less of an issue for AI, and the underlying platform is very well specified?
I guess the only problem with vanilla is if the sheer volume of text overwhelms the context?
Even more fundamentally, frameworks were created to reduce the developer skill required to build applications. This has been a pipe dream many have chased since COBOL replaced assembly language.
LLMs are probably the first technology that actually approaches doing that. And yes, they don't need frameworks, they're indifferent to the amount of code or boilerplate needed, don't care about the developer "experience," and will write vanilla JS and HTML just as well as anything else you ask them to do, maybe better.
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
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.
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+LLM experience was amazing. Hoping models close the gap fully so I can stay w Svelte -- I do still like reading and tweaking the code.
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.
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.
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?
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.
Tutorials are often written in an imperative style that's a little like prompt injection. There's a lot more writing out there on "how to make a todo app demo" than for the complex shit.
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 Bozos' idiotic confident answers. It's not like confident idiocy is a new thing with LLMs -- they were trained on it.
Then React turned that confidently idiotic folklore into an ecosystem: every confident answer depends on which year it was posted, which version it assumes, and which of six abandoned libraries it recommends. The LLM blends them into a seventh approach that never existed.
For now, I suspect Svelte's shorter, cleaner history with fewer wrong paths taken and retreated from will mean there are fewer incoherent competing approaches for LLMs to blend together into confident hallucinations.
Perhaps less contradictory training data is better than more incoherent training data.
LLMs may not experience the mind-expanding joy that humans do from using Svelte or the mind-numbing frustration that humans do from using React, but they can inherit the coherent focus of Svelte and incoherent confusion of React without sharing Svelte's pleasure or React's pain.
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.
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).
And if you force the LLM to write extensive E2E tests and performance benchmarks before writing any Svelte code, you're even better off.
In the "Unix Haters Handbook", "X-Windows Disaster" chapter, "Ice Cube: The Lethal Weapon" section, I quoted Jamie Zawinski, whose timeless and tactile observation also applies to React:
> Using these toolkits is like trying to make a bookshelf out of mashed potatoes.
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.
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.
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.
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.
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?
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.
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)?
I'm a little out of touch with these technologies (sveltekit, nextjs), but is there any advantage to using the same technology for both frontend and backend development beyond the rise of full-stack developers?
What about using React/Svelte for the frontend and a separate backend in Node.js or another stack? Is there any real advantage to having a single monolithic codebase for everything?
The main benefit is that it's very easy to have type safety and consistency between your client and your server. NextJS and the like make it feel almost like you're just calling a native JS function in your client, but it's actually doing lots of magic to make that work. The end result is your client is never out of date with your backend API, everything is type safe, you get full type hinting, and of course all of that helps LLMs write better code for you as well.
As long as you can get an accurate OpenAPI schema out of your API, it’s not much of a value add to have the same language throughout. Stuff like Orval and OpenAPI TS make this easy.
You can enforce keeping them in sync at CI time. This is more effective in a monorepo.
OpenAPI does a similar job and is great if you're using different languages, but I disagree it's not much of a value add. You can send way more types between client/server in e.g. NextJS without thinking about it like lists, dates, promises, etc. OpenAPI can't do that, and OpenAPI also needs a codegen step and then you have to work with janky generated clients.
I’ve been working with purportedly janky generated clients across an FE and BFF monorepo and it’s been painless. From where I’m sat, the benefits I’m missing aren’t significant enough to decide the stack.
Svelte is that kind of project that never ceases to reinvent the wheel... they started with a circle, perfect and functional. Then they decided to go with a square, then an octagon, then a hexadecagon... in a few more versions they will eventually get close to something you can put on a cart and drive around.
They aren't, they did some much needed API changes after adopting signals. It reduced some of the magic but it's pretty much the same as it's always been. I agree that API stability is something a lot of mature frameworks need, but svelte has always been at the forefront of provided high quality migration tooling.
The refinements introduced in SvelteKit 3 demonstrate the team's commitment to delivering a framework with an exceptional developer experience.
The migration from Svelte 4 to 5 was handled extremely well in SK 2, and it is a rock-solid framework for production.
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.
Whenever a new version of React releases (which lately has been performance improvement and bug fixes only), the discussion has been all about how htmx and server-rendered is obviously better. But when a not-react frontend framework pushes a new version with breaking changes, somehow the htmx fans are nowhere to be seen.
It's called React Derangement Syndrome. People who may have not touched the web in over 20 years find themselves having very strong opinions about it. I've never seen a library get so much unwarranted hate in my entire career.
"Hey team, some guy on HN said we should use Svelte because it has a good "aura". Has that been factored into our CBA?"
Absolutely love svelte/kit. Using it for all my projects (e.g. stackpulse.app) for years.
I did a grave mistake using Next.js for one project not too long ago, thinking LLMs know it better and it will be a smooth sailing. It wasn't :D Never touching that thing again, it just doesn't click for me.
In general I like Svelte and SvelteKit although there's 3 problems I don't fully like:
1) The getter trap - if you forget to export hooks via getters you don't get reactivity and it's not easy to figure out (Svelte)
2) The async data fetching - for example fetching data async is currently coupled to views which it shouldn't be - was frustrating a lot (SvelteKit)
3) That reactivity system is not runtime only (Svelte)
I am also not a fan of adding these new things like remote functions - most of apps need multiple frontends and this coupling isn't needed. This will be fad same as GraphQL
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 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.
Other advantages of Svelte over React/Vue is that it does not require a Svelte specific library or wrapper, you can use vanilla JS libraries and it works seamlessly. I consider that as plus, you can old good old Chart.js, Ag-grid, etc without any wrapper, I tried some libraries with React/Vue that had wrappers for multiple frameworks, and most of them were painful, because each framework/library has their way to do things that collides with them, while Svelte is basically vanilla web tech with some sparkles over it.
I've used various vanilla js libs with Vue over the years. It was always pretty easy to make a wrapper component and hook whatever library up to the lifecycle, usually just a few lines of code. I'd prefer that over just making random charts everywhere if I was using something like highcharts.
I use React, Vue, and Svelte extensively, and I don't think that there is any problem with integrating 3rd party JS libraries in any of these frameworks.
React, as the most bare-bones framework, might be simplest to integrate, and you can see that by the enormous size of its ecosystem.
Vue and Svelte will have problems with integrating various devtools, due to the fact they use custom syntax to mimic native web tech. In Vue, this problem is solved by framework popularity and the fact that the Vue team produced most of the key devtools, so Vue is, of course, supported.
Svelte, on the other hand, still works badly with Storybook and linters.
A good counterexample to your take will be that I was unable to use the JS version of Framer Motion with Svelte without huge caveats that made making any complex animation impossible. I wasn't able to do so with Vue, for roughly the same reasons, but Vue, as a big framework, got 1st party support.
I just hated React with passion and then I spent significant time with Svelte a few years basically to appreciate how much better React is.
Svelte had one edge - compiled code making surgical DOM updates. React has a compiler too and if you ever have opened Facebook or Instrgram, all that UI is compiled by a React compiler already.[0]
I also find arguments like this quite weak. YouTube, Facebook et al work like absolute horseshit compared to other websites and web apps. If anything, they proof that these big companies manage to make simple web applications as bloated and slow as possible.
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.
With Vue, you require each library you use to be Vue specific, Nuxt UI, Vuetify, etc, while Svelte works seamlessly with vanilla JS libraries, also Svelte feels more like vanilla HTML/CSS/JS with some sparkles over it.
look at all these comments downplaying this framework and all the others solely because LLMs can code. This feels like bots spamming propaganda to sell you AI
Honestly, this may be a great framework, but who cares, really? You're not really writing anything. You're just asking Claude Code to create something in plain English and looking at the output, so I don't know. I think the era of crafting software is basically over.
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.
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.
Are frontend frameworks even relevant ? Granted, I'm no frontend engineer, but I have toy projects where I only have "vanilla" JS written and read by agents. Works a breeze, no dependency hell. It won't work everywhere but I'm pretty sure a fraction of existing apps don't need frameworks anymore.
If it's just a toy, sure. But even frontier models reach a tipping point of complexity fairly early where they start introducing bugs quicker than they fix them.
A (good) framework abstracts away the complexity so you hit that tipping point much later in terms of codebase size, and reduces your token spend to boot.
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.
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.
Needing bespoke svelte-specific tooling for _everything_ is pretty annoying when it comes to developer experience IMO. It is just overly custom when you could use something like solid and have similar performance but easy tooling integration due to just being typescript and tsx syntax. Like you can’t use typescript 7 right now in svelte, oxlint / oxfmt doesn’t fully support svelte either among other things like storybook’s mcp server not supporting svelte.
There's other rough edges too (generics for example), but the absolute chasm between svelte and JSX tooling quality and it was a major reason for me dropping it.
You can fire up a solid project and get close to react's speed and quality even with earlier preview versions. Comparison aside, the reliability and speed of svelte tooling has felt extremely lacking on larger projects to the point i resent working on my 3 year old sveltekit codebase.
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 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.
I used to keep an eye on the web frameworks. Tried Solid JS, Vue, Svelte etc regularly to see what's going on. But at this point, if I'm not gonna enjoy the platform or suffer from it then it might as well be jquery + imperative code.
Also, web frameworks are not really about coding anyway. These are HTML generators. They were about developer ergonomics beyond anything and were important when it was about developers.
> 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
Even under your premise, the framework that helps agents get there faster is the better framework, programming capabilities notwithstanding.
Yup, LLMs can just write Python scripts that can just do the same thing for you without frameworks, NPM, Yarn, dependencies, sneaky bugs, random packages needing updates.
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.
Svelte changed things up at every single version so that's what you get. I've been a fan/hater since v1. For me Claude still tried to write "export let" for props even if I specify Svelte 5 at times.
This just isn't true. It barely changed from 2019 when Svelte 3 was released until Svelte 5 at the end of 2024.
Yes, you're right, although there was a lot of churn in SvelteKit when it was in beta--maybe they had that in mind. Of course, it was marked as a beta, so it's hard to blame them too much. But I was using Kit heavily during that period and ended up getting frustrated by the whiplash, and then the addition of runes (which was announced in late 2023 even if it wasn't released until 2024) was what made me lose interest in Svelte. I still have some fondness for the framework though.
You're just forgetting.
1-2 basically a different templating language
2-3 basically a different templating language
4-5 compatible but changed again
That's 3 syntax changes over 4 versions.
They explicitly mention that Svelte hasn't changed much since version 3? Svelte 5 did introduce runes but, as you say, still kept legacy code compatible.
It really only got popular at version 3, so there's only been two syntaxes that most people have had to work with.
DeepSeek Latest does a great job with Svelte/Kit apps if you want to use an open weight models
I will never use anything else than HTMX or Elixir/Phoenix anymore.
Unless I am paid to do it.
If you liked Svelte, you might enjoy this: https://github.com/Qbix/Q.js
Unlike other frameworks, it requires no build step at all… and a few other things. It just loads your code on demand, both methods and components.
You can also include https://svelte.dev/docs/llms to improve your LLM experience.
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!
+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.
Has it any advantages to Tauri?
Not sure, never heard of it, but looking at the README it seems similar but w/ a Rust backend?
We do a lot of data/quant analysis w/ Go which is great for that; then having the opportunity to slap on a lightweight GUI allow us to make some great internal tools etc.
The speed is what I love about Svelte websites. I checked out orb.net; the pages load instantly! I rarely see that with websites built with other frameworks.
Is Wails like Tauri but for Golang?
Yeaaah! Svelte was my entry point to front-end, never left it since then!
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?
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
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?
A good reason to use svelte instead of React is performance. LLMs not only got us more convenient development but also users that use their hardware for longer since the prices are so high.
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.
This is why I switched to Astro/React in 2024. I wonder where I would be now if I had stuck things out. Svelte is very fast and elegant. I found that I can use Astro for anything I thought I might need NextJS for though.
I still use Svelte but I switched to Astro too. I think the best thing about it is that its devs are focused on building primarily a good ssg. The Svelte people are primarily building a frontend framework and added sveltekit as an addition. Using Svelte in astro even feels nicer to me.
I strongly recommend vanilla html, js, and css. For me the benefits of having no npm and related ecosystem tools and no dependencies far outweigh any benefits you get from switching to specific framework. It took me just as long to learn modern css, html, and basically all the browser APIs as it did to learn how to setup+build+modify+deploy my svelte-vscodeextension-webview project without getting bogged down in the tooling.
All those tools and packages are constantly making breaking changes or introducing incompatibility issues or becoming obsolete, and there is so much maintenance. I went pretty deep on CSR/SSG/browser automation over the past two years and realized that everything you get out of these tools is probably 20-400 lines of javascript you could just ask an LLM to implement when you need it. I’ve seen people waste so many hours, days, and weeks on tailwind ui crap (solvable in minutes with css), vitest and object lifecycle crap (use the browser debugger, do e2e tests) and major version upgrades (there’s about 95% less of this in the browser and >99% less outside experimental APIs).
I think for Facebook/Github sized web applications, with really big teams and lots of custom tooling (eg React) these frameworks make sense. Most websites just need basic file serving/rendering, to send and respond to http requests, and some javascript to run on the client (but html and css can actually handle many core UI patterns). I’ve been much happier not using frameworks because my projects just work and the knowledge I build doesn’t constantly churn.
> lightning-fast static sites with Sveltekit
[???] Why the hell would I use SvelteKit for a static site?
We had an existing sveltekit application and its components, tooling, etc and used statue to develop the landing page/legals/docs/marketing portion of our site as an SSG, deployed separately but with shared logic.
Our application was behind a proxy that requires auth, and we could host our SSG on Cloudflare pages, so we didn’t have to expose any application server/compute (besides auth) to the public Internet. To me this was very desirable for security and devex: we could develop the two applications independently and be pretty lax with the static site.
> and decided I'd rather just use vanilla css/js for new projects.
So is the rise of AI coding, the end of frameworks?
Frameworks were created to reduce boiler plate ( at the expense of new abstractions which occasionally leak ) - boiler generation is less of an issue for AI, and the underlying platform is very well specified?
I guess the only problem with vanilla is if the sheer volume of text overwhelms the context?
> Frameworks were created to reduce boiler plate
Even more fundamentally, frameworks were created to reduce the developer skill required to build applications. This has been a pipe dream many have chased since COBOL replaced assembly language.
LLMs are probably the first technology that actually approaches doing that. And yes, they don't need frameworks, they're indifferent to the amount of code or boilerplate needed, don't care about the developer "experience," and will write vanilla JS and HTML just as well as anything else you ask them to do, maybe better.
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
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.
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+LLM experience was amazing. Hoping models close the gap fully so I can stay w Svelte -- I do still like reading and tweaking the code.
You can include https://svelte.dev/docs/llms to improve your experience.
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.
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.
Are they still sticking to that godawful routing nomenclature of +page.svelte in infinite nested folders?
I was a long time Vue fan. I used svelte when it was V1 but the changes in V2 put me off. Where vue was stable.
But for my latest project I started using Svelte and I love it.
https://github.com/entangle-cloud/wave
I love that stores comes out of the box and works well. No more callbacks for two way binding and Vue $emit hacks.
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!
what's the point of svelte in a world where the llm is much better at react due to massively more available training data?
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?
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.
Tells you something about the average React code
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.
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?
Tutorials are often written in an imperative style that's a little like prompt injection. There's a lot more writing out there on "how to make a todo app demo" than for the complex shit.
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 Bozos' idiotic confident answers. It's not like confident idiocy is a new thing with LLMs -- they were trained on it.
Then React turned that confidently idiotic folklore into an ecosystem: every confident answer depends on which year it was posted, which version it assumes, and which of six abandoned libraries it recommends. The LLM blends them into a seventh approach that never existed.
For now, I suspect Svelte's shorter, cleaner history with fewer wrong paths taken and retreated from will mean there are fewer incoherent competing approaches for LLMs to blend together into confident hallucinations.
Perhaps less contradictory training data is better than more incoherent training data.
LLMs may not experience the mind-expanding joy that humans do from using Svelte or the mind-numbing frustration that humans do from using React, but they can inherit the coherent focus of Svelte and incoherent confusion of React without sharing Svelte's pleasure or React's pain.
Imo, it tells you how many footguns there are in regards to performance in React.
LLMs write bad code for everything, it isn't just React unfortunately.
But it can only write the code as bad as the framework allows and React allows a lot of bad code.
What's the point of anything?
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.
LLMs don't struggle with Svelte. Why wouldn't you use it?
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)
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).
And if you force the LLM to write extensive E2E tests and performance benchmarks before writing any Svelte code, you're even better off.
In the "Unix Haters Handbook", "X-Windows Disaster" chapter, "Ice Cube: The Lethal Weapon" section, I quoted Jamie Zawinski, whose timeless and tactile observation also applies to React:
> Using these toolkits is like trying to make a bookshelf out of mashed potatoes.
https://news.ycombinator.com/item?id=35631889
https://donhopkins.medium.com/the-x-windows-disaster-128d398...
https://www.youtube.com/watch?v=mg8xfl4L6HQ
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.
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...
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.
svelte is way more performant than react.
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.
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.
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.
LLMs are great at Svelte
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.
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?
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.
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)?
svelte is like go, and react is like javascript. alot easier to write non-performant javascript then non-performant go.
Also, Svelte is like Go, and React is like Checkers. ;)
I'm a little out of touch with these technologies (sveltekit, nextjs), but is there any advantage to using the same technology for both frontend and backend development beyond the rise of full-stack developers?
What about using React/Svelte for the frontend and a separate backend in Node.js or another stack? Is there any real advantage to having a single monolithic codebase for everything?
The main benefit is that it's very easy to have type safety and consistency between your client and your server. NextJS and the like make it feel almost like you're just calling a native JS function in your client, but it's actually doing lots of magic to make that work. The end result is your client is never out of date with your backend API, everything is type safe, you get full type hinting, and of course all of that helps LLMs write better code for you as well.
As long as you can get an accurate OpenAPI schema out of your API, it’s not much of a value add to have the same language throughout. Stuff like Orval and OpenAPI TS make this easy.
You can enforce keeping them in sync at CI time. This is more effective in a monorepo.
OpenAPI does a similar job and is great if you're using different languages, but I disagree it's not much of a value add. You can send way more types between client/server in e.g. NextJS without thinking about it like lists, dates, promises, etc. OpenAPI can't do that, and OpenAPI also needs a codegen step and then you have to work with janky generated clients.
I’ve been working with purportedly janky generated clients across an FE and BFF monorepo and it’s been painless. From where I’m sat, the benefits I’m missing aren’t significant enough to decide the stack.
But fair point on the complex types.
Svelte is that kind of project that never ceases to reinvent the wheel... they started with a circle, perfect and functional. Then they decided to go with a square, then an octagon, then a hexadecagon... in a few more versions they will eventually get close to something you can put on a cart and drive around.
I'm not actively using Svelte (even not doing FE), can you elaborate what they constantly reinventing?
Read this comment section alone, it's aready been explained.
They aren't, they did some much needed API changes after adopting signals. It reduced some of the magic but it's pretty much the same as it's always been. I agree that API stability is something a lot of mature frameworks need, but svelte has always been at the forefront of provided high quality migration tooling.
that's what it takes to make it not just for "toy project" anymore. I think people appreciated it due to it looks great for a small project
The refinements introduced in SvelteKit 3 demonstrate the team's commitment to delivering a framework with an exceptional developer experience. The migration from Svelte 4 to 5 was handled extremely well in SK 2, and it is a rock-solid framework for production.
Change for the sake of change without adding anything new, and yes i have used it for years but i kind of don't even like it.
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.
Whenever a new version of React releases (which lately has been performance improvement and bug fixes only), the discussion has been all about how htmx and server-rendered is obviously better. But when a not-react frontend framework pushes a new version with breaking changes, somehow the htmx fans are nowhere to be seen.
It's called React Derangement Syndrome. People who may have not touched the web in over 20 years find themselves having very strong opinions about it. I've never seen a library get so much unwarranted hate in my entire career.
"Hey team, some guy on HN said we should use Svelte because it has a good "aura". Has that been factored into our CBA?"
Absolutely love svelte/kit. Using it for all my projects (e.g. stackpulse.app) for years.
I did a grave mistake using Next.js for one project not too long ago, thinking LLMs know it better and it will be a smooth sailing. It wasn't :D Never touching that thing again, it just doesn't click for me.
In general I like Svelte and SvelteKit although there's 3 problems I don't fully like:
1) The getter trap - if you forget to export hooks via getters you don't get reactivity and it's not easy to figure out (Svelte)
2) The async data fetching - for example fetching data async is currently coupled to views which it shouldn't be - was frustrating a lot (SvelteKit)
3) That reactivity system is not runtime only (Svelte)
I am also not a fan of adding these new things like remote functions - most of apps need multiple frontends and this coupling isn't needed. This will be fad same as GraphQL
Can somebody with experience using both compare Svelte/Sveltekit with Vue/Nuxt?
I do. I wrote on this extensively there – https://www.brachkow.com/notes/my-experience-with-svelte/
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 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.
Other advantages of Svelte over React/Vue is that it does not require a Svelte specific library or wrapper, you can use vanilla JS libraries and it works seamlessly. I consider that as plus, you can old good old Chart.js, Ag-grid, etc without any wrapper, I tried some libraries with React/Vue that had wrappers for multiple frameworks, and most of them were painful, because each framework/library has their way to do things that collides with them, while Svelte is basically vanilla web tech with some sparkles over it.
I've used various vanilla js libs with Vue over the years. It was always pretty easy to make a wrapper component and hook whatever library up to the lifecycle, usually just a few lines of code. I'd prefer that over just making random charts everywhere if I was using something like highcharts.
I use React, Vue, and Svelte extensively, and I don't think that there is any problem with integrating 3rd party JS libraries in any of these frameworks.
React, as the most bare-bones framework, might be simplest to integrate, and you can see that by the enormous size of its ecosystem.
Vue and Svelte will have problems with integrating various devtools, due to the fact they use custom syntax to mimic native web tech. In Vue, this problem is solved by framework popularity and the fact that the Vue team produced most of the key devtools, so Vue is, of course, supported.
Svelte, on the other hand, still works badly with Storybook and linters.
A good counterexample to your take will be that I was unable to use the JS version of Framer Motion with Svelte without huge caveats that made making any complex animation impossible. I wasn't able to do so with Vue, for roughly the same reasons, but Vue, as a big framework, got 1st party support.
SvelteKit has incredible DX. I use it for everything these days.
I just hated React with passion and then I spent significant time with Svelte a few years basically to appreciate how much better React is.
Svelte had one edge - compiled code making surgical DOM updates. React has a compiler too and if you ever have opened Facebook or Instrgram, all that UI is compiled by a React compiler already.[0]
[0]. https://react.dev/learn/react-compiler
> if you ever have opened Facebook or Instrgram, all that UI is compiled by a React compiler already.
Is that supposed to be a selling point?
I also find arguments like this quite weak. YouTube, Facebook et al work like absolute horseshit compared to other websites and web apps. If anything, they proof that these big companies manage to make simple web applications as bloated and slow as possible.
Svelte/SvelteKit is awesome, easy to learn and good DX. Svelte was my first frontend framework experience. Daestro's console is built on it.
I migrated from Nuxt to SvelteKit last year and never went back. It's great.
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.
With Vue, you require each library you use to be Vue specific, Nuxt UI, Vuetify, etc, while Svelte works seamlessly with vanilla JS libraries, also Svelte feels more like vanilla HTML/CSS/JS with some sparkles over it.
Ya, exactly this.
SvelteKit made me love the web
look at all these comments downplaying this framework and all the others solely because LLMs can code. This feels like bots spamming propaganda to sell you AI
Honestly, this may be a great framework, but who cares, really? You're not really writing anything. You're just asking Claude Code to create something in plain English and looking at the output, so I don't know. I think the era of crafting software is basically over.
Maybe you're doing that. Lots of people actually care about producing good work, and thus they are not just doing LLM slop.
So, using nextjs is LLM slop?
Is this what AI psychosis is like?
Still waiting for remote functions to become ready :/
I've had no problem using them in 2.x
What was used instead before ?
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.
[0] https://svelte.dev/docs/kit/load
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.
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.
I love svelte, but I think in the world of agents programmer ergonomics is no longer relevant.
Are frontend frameworks even relevant ? Granted, I'm no frontend engineer, but I have toy projects where I only have "vanilla" JS written and read by agents. Works a breeze, no dependency hell. It won't work everywhere but I'm pretty sure a fraction of existing apps don't need frameworks anymore.
Why wouldnt frontend frameworks be relevant?
If it's just a toy, sure. But even frontier models reach a tipping point of complexity fairly early where they start introducing bugs quicker than they fix them.
A (good) framework abstracts away the complexity so you hit that tipping point much later in terms of codebase size, and reduces your token spend to boot.
True one year ago, not now
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.
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.
Needing bespoke svelte-specific tooling for _everything_ is pretty annoying when it comes to developer experience IMO. It is just overly custom when you could use something like solid and have similar performance but easy tooling integration due to just being typescript and tsx syntax. Like you can’t use typescript 7 right now in svelte, oxlint / oxfmt doesn’t fully support svelte either among other things like storybook’s mcp server not supporting svelte.
solid requires it's own jsx transform, and it's framework (imo) is not as ergonomic. but yes both are great.
i do think react (without a framework) is the beat option though.
There's other rough edges too (generics for example), but the absolute chasm between svelte and JSX tooling quality and it was a major reason for me dropping it.
You can fire up a solid project and get close to react's speed and quality even with earlier preview versions. Comparison aside, the reliability and speed of svelte tooling has felt extremely lacking on larger projects to the point i resent working on my 3 year old sveltekit codebase.
lol Great insight. I really trust an opinion about something you admittedly don't use. Also is "aura" a technical term?
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
For what it is worth, I care, if only for the simple fact that it is an interesting project.
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.
>humans
It is probably LLMs all the way down.
Time to ask the agent to spit out compiled wasm then if it doesn't matter.
Svelte is faster and smaller on client devices than React is. If you care about user experience you should probably care, yes.
God that's depressing. I would hope that this website hasn't lost all interest in coding because AI can do it now.
Isn't that inevitable?
I used to keep an eye on the web frameworks. Tried Solid JS, Vue, Svelte etc regularly to see what's going on. But at this point, if I'm not gonna enjoy the platform or suffer from it then it might as well be jquery + imperative code.
Also, web frameworks are not really about coding anyway. These are HTML generators. They were about developer ergonomics beyond anything and were important when it was about developers.
> 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
Even under your premise, the framework that helps agents get there faster is the better framework, programming capabilities notwithstanding.
Yup, LLMs can just write Python scripts that can just do the same thing for you without frameworks, NPM, Yarn, dependencies, sneaky bugs, random packages needing updates.
This kind of post is basically spam.