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

  today at 12:20 AM

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

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

  today at 1:57 AM

  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.

• brachkow

  today at 1:03 AM

  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

• avarun

  today at 1:04 AM

  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?

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

  today at 1:55 AM

  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.

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

  yesterday at 10:37 PM

  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

    yesterday at 10:56 PM

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

  • jitl

    yesterday at 10:44 PM

    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

      yesterday at 11:19 PM

      Tells you something about the average React code

      • ceejayoz

        today at 12:28 AM

        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.

  • meowface

    today at 12:49 AM

    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

    yesterday at 11:08 PM

    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.

  • digitaltrees

    today at 12:12 AM

    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.

  • zem

    yesterday at 10:56 PM

    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.

  • aoeusnth1

    today at 1:14 AM

    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

    yesterday at 10:55 PM

    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)

  • onemoresoop

    today at 12:37 AM

    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?

  • afavour

    today at 12:06 AM

    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.

  • transdev12

    yesterday at 10:51 PM

    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

    yesterday at 11:52 PM

    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

    today at 12:07 AM

    LLMs are great at Svelte

  • sampsn

    yesterday at 10:41 PM

    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

    yesterday at 10:57 PM

    svelte is way more performant than react.

  • esafak

    yesterday at 10:51 PM

    LLMs don't struggle with Svelte. Why wouldn't you use it?

  • nozzlegear

    yesterday at 10:47 PM

    What's the point of anything?

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

  today at 1:56 AM

  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

  today at 1:31 AM

  For what it is worth, I care, if only for the simple fact that it is an interesting project.

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.

SvelteKit has incredible DX. I use it for everything these days.

I migrated from Nuxt to SvelteKit last year and never went back. It's great.

• CharlesW

  today at 1:38 AM

  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.

Can somebody with experience using both compare Svelte/Sveltekit with Vue/Nuxt?

• brachkow

  today at 12:56 AM

  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.

  • phoghed

    today at 1:51 AM

    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.

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.

Still waiting for remote functions to become ready :/

• chrysoprace

  yesterday at 11:25 PM

  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

  yesterday at 11:56 PM

  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

  yesterday at 10:54 PM

  I've had no problem using them in 2.x

• cassepipe

  yesterday at 11:20 PM

  What was used instead before ?

  • chrysoprace

    yesterday at 11:27 PM

    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

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.

[flagged]