Hey everyone, Rich from the Svelte team here. Coordinating all the moving parts for yesterday's launch (last few PRs, doc updates and redirects, CLI release, launch blog post...) turned out to be a bit of a slog so I'll confess I turned off my laptop and went for a beer as soon as it was done instead of sticking around to engage in HN threads and Reddit and so on.
Honestly, I didn't expect the release to generate much conversation at all. There's a lot less focus/interest in front-end frameworks generally these days, for obvious reasons, so I figured the median reaction would be 'oh, the Svelte team are still shipping? good for them' and not much more. It's a joy to see the conversation here whether it's from happy users, or people who prefer different things, or people who have fully outsourced the writing-the-code bit to LLMs and straight up don't care about the underlying tools any more.
Which I totally understand! As framework authors we're very persnickety about the details of the code, so we've been on the slower end of the LLM adoption curve, but even we're starting to delegate more of the work to agents. If you're prompting an app into existence it's natural not to care that much about the particulars. But a question I've seen several times here, and in the zeitgeist more generally — 'in a world of agents why should I care about Svelte vs React vs whatever?' — deserves an answer.
And it's this: your app will be _better_ if you use Svelte. Your JavaScript bundle will use fewer bytes, your server-side rendering will take fewer milliseconds, and your users will reap the benefits: faster, more efficient apps. For all that the agentic revolution has created a huge _quantity_ of software, the _quality_ of the average app stubbornly refuses to budge. If anything, software is becoming less reliable. I think we've all felt that. Using a framework that treats things like accessibility and progressive enhancement as core concerns will help you steer towards better outcomes. (Your agent will use fewer tokens as well.)
Of course, this was always the pitch! Agents don't change that. And that's why we're still shipping and still sweating the details. We have some stuff coming up that we're unreasonably excited about — we really care about this stuff, and we're very grateful to be part of a community who shares that passion. Thank you for the support, it means the world to us.
Awesome, Rich. Been a diehard Sveltehead since 2022 - and yes, just because agents default to React doesn't make it better! Thanks for making the best JS framework of them all
For me the annoying thing is that everyone seems to assume using SvelteKit by default when looking something up about svelte. No, i don't want to use this folder based routing or server side rendering, i want to ise it to write a frontend for a backend.
Even though I delegate more and more to coding agents I've stayed with Svelte(kit) for any project where I can choose. It's always been a breeze to work with coming from an Angular background and (imho) the average quality of the resulting code (quality of training samples I guess) is just better than with most other frameworks I've seen.
I totally agree with you bundle size and performance matter and I look forward to working with remote functions.
Glad to see you and the team are still at it! The accessibility guardrails in Svelte are in particular something that I imagine steers agents in the right direction. And it would be sad if the frontend ecosystem converged on React for the LLM benefits given that it's definitely not optimal performance-wise, especially on slower mobile devices.
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.
Tauri is Rust, Wails is Go. Rust tooling and builds are heavyweight -- if you are using Rust already, the marginal cost is low, but if you aren't using Rust and want to minimize the weight of the tooling to get your app built, Go is extremely attractive by comparison.
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.
Looks like it - they both take the same "don't ship a browser, rely on the OS's built-in browser engine" approach. Unfortunately that approach seems to be great on Windows, okay on Mac, and barely workable on Linux.
Tauri has been trying to dig itself out of that hole for a while by adding CEF support. It looks like they've got that running in the Tauri 3.0 alpha, but I think they may still have some issues with Wayland.
I used Svelte daily as my main framework between 2020 and 2024. Took me a couple of years to realize Svelte's biggest strength is also its biggest issue. Having a custom language means so much effort is needed to build and maintain custom tooling to support it. And not only from the small Svelte team and its community. Eg: Even to this day, the Svelte plugin by JetBrains is trash [2]. If you want to do Svelte you're basically trapped into using their VSCode extension.
Ultimately I ended up moving away to Solid primarily because I can write vanilla TS/TSX. Like it or not, TS/TSX is a standard these days and most editors or IDEs support it out of the box.
Ironically, given the chatter in this thread, I'd say this is a problem very solvable by LLMs. The Svelte language is well defined, the JetBrains API is well defined. No reason why a plugin couldn't be LLM generated.
Seems like a separate issue? I also wouldn't assume that. Svelte is faster and smaller than React, even with all the training data in the world there are still non-negotiables.
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?
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.
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?
Vanilla css/js are not really that voluminous. Actually, they tend to be smaller than the compiled targets you get from conventional web dev builds.
I’m not really sure that most web frameworks reduce boilerplate. There is a lot of boilerplate involved in setting up routes, and builds, and so on. As far as I can tell they only really make sense for very large teams (who need a uniform shared data model, design language, processes, etc.) and people who really want to run server side js/do a lot of SSR.
The thing about web “frameworks” is that they’re not that different in structure from what you’d build to do SSR and a repeatable way to add pages/dirs and shared assets, in any language. You can build a minimal version of something that does that in less than an hour, at least in Go. go:embed and a factory method for handlers :)
I think we’ll all end up with more bespoke “frameworks” (specialized web servers) with less gravitational pull towards dysfunctional (IMO, the node ecosystem) tooling, and still have many people using the best major frameworks. Truly large projects will still need to use react and svelte and co unless they can train a model on their own framework. But that’s really hard
Even more fundamentally, frameworks were created to reduce the developer time and 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.
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 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.
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 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.
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
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
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.
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 think that strictness will be the most important feature going forward. Whichever framework creates the safest boundaries for agents to work within will gain traction. That's why I think Effect has a bright future.
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.
Is anyone hand-writing code anymore though in 2026? I don't think many people these days have to worry about "keeping up with all the React developments", because Claude/Codex handles all that now.
Yes. I can understand a backend engineer who wants to slap together a frontend just deferring the whole thing to LLMs but there are a lot of frontend engineers out there that care a lot about performance and the like who are absolutely keeping up with React developments, no matter whether the final code is LLM generated or not.
There's not really any way to make a website look exactly how you want it to look without manually fiddling with its HTML and CSS. I took the agent pill as soon as I could and never looked back, but it's truly much more work to ask the model to make small changes in natural language, observe, and iterate when you can just open the developer console and do it yourself. That said, I modify the site by hand only enough to get it into a state where I can dump it on an agent to finish up.
I handwrite plenty of code. I know what I want the thing to do, how I want it to behave, or how I want it to look; the LLM can't read my mind and doesn't get it all the way there.
To quote Mordin Solus: "Had to be me. Someone else might have gotten it wrong."
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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?
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?
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.
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.
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 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.
Integrating React with third party libraries has always been a pain for me.
The re-render model just doesn't quite fit with the way most JS libraries work. They hand you a class that you have to keep around. This can be solved with useState, but you have to use this weird construction `const [instance] = useState(() => new Whatever())`. Or even worse if the library needs an element to instantiate.
Then, you likely need some event listeners. They ended up not implementing useEvent, so this has to happen in useEffect. God forbid if you need to rebind the listener because a prop changes (possibly every rerender) or the library does something heavy on adding them.
Then, if a prop changes and you need to do something (like recenter a map), useEffect.
Occasionally you might want to reach for useSyncExternalStore but then get hit by the identity issue. The return value must be the same between renders or you end up with infinite rerenders. Many libraries just do `return { foo, bar}`. Not good enough for react.
Basically every JS library integration ends up with a thousand use effects, various useMemos (and useCallbacks) and I've never got (or seen) a satisfying result. There's always sync issues or too many rerenders or...
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'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.
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?"
I have only ever used react professional in my career and I have been sick of it since hooks were introduced. Easily the worst thing to come to the frontend world and has held it back for a solid decade.
Because your comment is irrelevant to what's being talked about. You feeling the need to add your personal opinion about how much you hate React despite having no bearing on the conversation is what React Derangement Syndrome is.
I just prompted Opus 5.5 to build a 5e character sheet tracker from the SRD (which I extracted an MD file from previously) and it got everything working with 20% of the session! Frontend only so not horribly complicated, and some of the UI is a bit janky/not to my taste, but it all works right off the bat! I was working on this with Tanstack for the last week or so and it was nowhere near this quick and easy (though I confess we use Sveltekit at work so I'm more familiar with that).
If y'all are worried about AI not doing Svelte well, I'm willing to vouch for at least Opus using it well, and there's svelte-check and friends to make sure you're not doing anything dumb on accident.
I feel that serving a single-page app with a catch-all fallback is fine for an app behind a login but costly for anything else you want found. Search engines will treat missing sitemap.xml/robots.txt or even llms.txt as soft 404s. Any tools that just check the status will think those files exist. So AI crawlers will either have to start using JS, this as they admit will hurt SEO, but more importantly today GEO.
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]
The real strength of React is that each component is a function which is an easier mental model than the spaghetti code Svelte componets turn into with special syntax which isn't even Javascript.
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.
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
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.
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.
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.
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.
I get that, seeing what a model can do with a Django codebase. Out of the major frontend frameworks, Svelte(kit) is actually the only one I would consider now as it seems to produce smaller packages.
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.
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.
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
There are no signals, proxies, or decorators, or any compilation. You just use plain data. Though the trade-off is that you have to call render() yourself. I prefer it that way 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.
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.
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.
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.
I used to spend a lot of time here discussing and debating frameworks, not so much lately. It's a depressing how much time we spent in framework wars. I don't miss it.
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.
And then you can no longer change a label without LLM assistance. I don't doubt this suits some people but impotently begging Claude to fix a critical bug while your boss looks over your shoulder must be quite humiliating.
> 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.
Hey everyone, Rich from the Svelte team here. Coordinating all the moving parts for yesterday's launch (last few PRs, doc updates and redirects, CLI release, launch blog post...) turned out to be a bit of a slog so I'll confess I turned off my laptop and went for a beer as soon as it was done instead of sticking around to engage in HN threads and Reddit and so on.
Honestly, I didn't expect the release to generate much conversation at all. There's a lot less focus/interest in front-end frameworks generally these days, for obvious reasons, so I figured the median reaction would be 'oh, the Svelte team are still shipping? good for them' and not much more. It's a joy to see the conversation here whether it's from happy users, or people who prefer different things, or people who have fully outsourced the writing-the-code bit to LLMs and straight up don't care about the underlying tools any more.
Which I totally understand! As framework authors we're very persnickety about the details of the code, so we've been on the slower end of the LLM adoption curve, but even we're starting to delegate more of the work to agents. If you're prompting an app into existence it's natural not to care that much about the particulars. But a question I've seen several times here, and in the zeitgeist more generally — 'in a world of agents why should I care about Svelte vs React vs whatever?' — deserves an answer.
And it's this: your app will be _better_ if you use Svelte. Your JavaScript bundle will use fewer bytes, your server-side rendering will take fewer milliseconds, and your users will reap the benefits: faster, more efficient apps. For all that the agentic revolution has created a huge _quantity_ of software, the _quality_ of the average app stubbornly refuses to budge. If anything, software is becoming less reliable. I think we've all felt that. Using a framework that treats things like accessibility and progressive enhancement as core concerns will help you steer towards better outcomes. (Your agent will use fewer tokens as well.)
Of course, this was always the pitch! Agents don't change that. And that's why we're still shipping and still sweating the details. We have some stuff coming up that we're unreasonably excited about — we really care about this stuff, and we're very grateful to be part of a community who shares that passion. Thank you for the support, it means the world to us.
Awesome, Rich. Been a diehard Sveltehead since 2022 - and yes, just because agents default to React doesn't make it better! Thanks for making the best JS framework of them all
Thank you. Great work by the team. I was ready to give up on JS when I came across SK and I've been a diehard fan ever since.
Can't wait for the next release
Thanks for your hard work, as well as the team.
Svelte / Sveltekit helped programming "click" for me , and years later I'm doing work I love for people who appreciate it.
SK is my favorite starting point for almost everything I build.
For me the annoying thing is that everyone seems to assume using SvelteKit by default when looking something up about svelte. No, i don't want to use this folder based routing or server side rendering, i want to ise it to write a frontend for a backend.
Check inertia.js. It’s the best of both worlds. We use it to bridge svelte with Laravel at work and I couldn’t be happier about this stack.
Thanks for the great work!
Even though I delegate more and more to coding agents I've stayed with Svelte(kit) for any project where I can choose. It's always been a breeze to work with coming from an Angular background and (imho) the average quality of the resulting code (quality of training samples I guess) is just better than with most other frameworks I've seen.
I totally agree with you bundle size and performance matter and I look forward to working with remote functions.
All this to say: Congrats on the release!
Glad to see you and the team are still at it! The accessibility guardrails in Svelte are in particular something that I imagine steers agents in the right direction. And it would be sad if the frontend ecosystem converged on React for the LLM benefits given that it's definitely not optimal performance-wise, especially on slower mobile devices.
Thank you for all the work. It's my top choice when creating a new project. And has been for several years already.
Thanks for all your hard work! We've almost exclusively used Svelte / sk for our client work at Niftic for years now. Excited to dig in on v3
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.
It really only got popular at version 3, so there's only been two syntaxes that most people have had to work with.
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.
IIRC Svelte 4 only existed to drop support for older browsers?
DeepSeek Latest does a great job with Svelte/Kit apps if you want to use an open weight models
You can also include https://svelte.dev/docs/llms to improve your LLM experience.
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.
I will never use anything else than HTMX or Elixir/Phoenix anymore.
Unless I am paid to do it.
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?
Tauri is Rust, Wails is Go. Rust tooling and builds are heavyweight -- if you are using Rust already, the marginal cost is low, but if you aren't using Rust and want to minimize the weight of the tooling to get your app built, Go is extremely attractive by comparison.
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?
Looks like it - they both take the same "don't ship a browser, rely on the OS's built-in browser engine" approach. Unfortunately that approach seems to be great on Windows, okay on Mac, and barely workable on Linux.
Tauri has been trying to dig itself out of that hole for a while by adding CEF support. It looks like they've got that running in the Tauri 3.0 alpha, but I think they may still have some issues with Wayland.
It would appear so! https://wails.io ... I hadn't heard of Tauri; cool project!
I used Svelte daily as my main framework between 2020 and 2024. Took me a couple of years to realize Svelte's biggest strength is also its biggest issue. Having a custom language means so much effort is needed to build and maintain custom tooling to support it. And not only from the small Svelte team and its community. Eg: Even to this day, the Svelte plugin by JetBrains is trash [2]. If you want to do Svelte you're basically trapped into using their VSCode extension.
Ultimately I ended up moving away to Solid primarily because I can write vanilla TS/TSX. Like it or not, TS/TSX is a standard these days and most editors or IDEs support it out of the box.
[1] https://plugins.jetbrains.com/plugin/12375-svelte
I use Svelte heavily since 2023 and have never even opened VSCode once in my life.
what do you use?
Neovim
Ironically, given the chatter in this thread, I'd say this is a problem very solvable by LLMs. The Svelte language is well defined, the JetBrains API is well defined. No reason why a plugin couldn't be LLM generated.
Yes but if you're using LLMs then surely something with more data available will produce better results?
Seems like a separate issue? I also wouldn't assume that. Svelte is faster and smaller than React, even with all the training data in the world there are still non-negotiables.
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?
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.
> 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?
Vanilla css/js are not really that voluminous. Actually, they tend to be smaller than the compiled targets you get from conventional web dev builds.
I’m not really sure that most web frameworks reduce boilerplate. There is a lot of boilerplate involved in setting up routes, and builds, and so on. As far as I can tell they only really make sense for very large teams (who need a uniform shared data model, design language, processes, etc.) and people who really want to run server side js/do a lot of SSR.
The thing about web “frameworks” is that they’re not that different in structure from what you’d build to do SSR and a repeatable way to add pages/dirs and shared assets, in any language. You can build a minimal version of something that does that in less than an hour, at least in Go. go:embed and a factory method for handlers :)
I think we’ll all end up with more bespoke “frameworks” (specialized web servers) with less gravitational pull towards dysfunctional (IMO, the node ecosystem) tooling, and still have many people using the best major frameworks. Truly large projects will still need to use react and svelte and co unless they can train a model on their own framework. But that’s really hard
Are you treating the LLM output as machine code or are you looking at it?
And if you are looking at it - do you insist on certain patterns or structure to allow yourself to more easily navigate it?
> Frameworks were created to reduce boiler plate
Even more fundamentally, frameworks were created to reduce the developer time and 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.
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 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.
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 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.
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
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
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.
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 think that strictness will be the most important feature going forward. Whichever framework creates the safest boundaries for agents to work within will gain traction. That's why I think Effect has a bright future.
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.
Is anyone hand-writing code anymore though in 2026? I don't think many people these days have to worry about "keeping up with all the React developments", because Claude/Codex handles all that now.
Yes. I can understand a backend engineer who wants to slap together a frontend just deferring the whole thing to LLMs but there are a lot of frontend engineers out there that care a lot about performance and the like who are absolutely keeping up with React developments, no matter whether the final code is LLM generated or not.
There's not really any way to make a website look exactly how you want it to look without manually fiddling with its HTML and CSS. I took the agent pill as soon as I could and never looked back, but it's truly much more work to ask the model to make small changes in natural language, observe, and iterate when you can just open the developer console and do it yourself. That said, I modify the site by hand only enough to get it into a state where I can dump it on an agent to finish up.
I handwrite plenty of code. I know what I want the thing to do, how I want it to behave, or how I want it to look; the LLM can't read my mind and doesn't get it all the way there.
To quote Mordin Solus: "Had to be me. Someone else might have gotten it wrong."
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 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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
You and Jamie sure landed on opposite sides of the AI debate.
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)?
[dead]
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.
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?
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.
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 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?
LLMs don't struggle with Svelte. Why wouldn't you use it?
LLMs are great at Svelte
svelte is way more performant than react.
What's the point of anything?
Are they still sticking to that godawful routing nomenclature of +page.svelte in infinite nested folders?
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.
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.
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 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.
Integrating React with third party libraries has always been a pain for me.
The re-render model just doesn't quite fit with the way most JS libraries work. They hand you a class that you have to keep around. This can be solved with useState, but you have to use this weird construction `const [instance] = useState(() => new Whatever())`. Or even worse if the library needs an element to instantiate.
Then, you likely need some event listeners. They ended up not implementing useEvent, so this has to happen in useEffect. God forbid if you need to rebind the listener because a prop changes (possibly every rerender) or the library does something heavy on adding them.
Then, if a prop changes and you need to do something (like recenter a map), useEffect.
Occasionally you might want to reach for useSyncExternalStore but then get hit by the identity issue. The return value must be the same between renders or you end up with infinite rerenders. Many libraries just do `return { foo, bar}`. Not good enough for react.
Basically every JS library integration ends up with a thousand use effects, various useMemos (and useCallbacks) and I've never got (or seen) a satisfying result. There's always sync issues or too many rerenders or...
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 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.
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?
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.
Read this comment section alone, it's aready been explained.
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
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?"
I have only ever used react professional in my career and I have been sick of it since hooks were introduced. Easily the worst thing to come to the frontend world and has held it back for a solid decade.
[flagged]
Then why are you posting in a forum if you don't want opinions? You can shout in front of a mirror you know.
Because your comment is irrelevant to what's being talked about. You feeling the need to add your personal opinion about how much you hate React despite having no bearing on the conversation is what React Derangement Syndrome is.
I just prompted Opus 5.5 to build a 5e character sheet tracker from the SRD (which I extracted an MD file from previously) and it got everything working with 20% of the session! Frontend only so not horribly complicated, and some of the UI is a bit janky/not to my taste, but it all works right off the bat! I was working on this with Tanstack for the last week or so and it was nowhere near this quick and easy (though I confess we use Sveltekit at work so I'm more familiar with that).
If y'all are worried about AI not doing Svelte well, I'm willing to vouch for at least Opus using it well, and there's svelte-check and friends to make sure you're not doing anything dumb on accident.
I feel that serving a single-page app with a catch-all fallback is fine for an app behind a login but costly for anything else you want found. Search engines will treat missing sitemap.xml/robots.txt or even llms.txt as soft 404s. Any tools that just check the status will think those files exist. So AI crawlers will either have to start using JS, this as they admit will hurt SEO, but more importantly today GEO.
SvelteKit does server-side rendering just fine.
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?
The real strength of React is that each component is a function which is an easier mental model than the spaghetti code Svelte componets turn into with special syntax which isn't even Javascript.
Right, it’s HTML. It’s a bit like JSX but not embedded.
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.
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
SvelteKit has incredible DX. I use it for everything these days.
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.
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.
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 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.
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 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.
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.
I get that, seeing what a model can do with a Django codebase. Out of the major frontend frameworks, Svelte(kit) is actually the only one I would consider now as it seems to produce smaller packages.
Why wouldnt frontend frameworks be relevant?
True one year ago, not now
Yeaaah! Svelte was my entry point to front-end, never left it since then!
Still waiting for remote functions to become ready :/
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'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
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
This seems like a good place to plug Solarite, my own js ui library.
https://eric-frost.github.io/solarite/
There are no signals, proxies, or decorators, or any compilation. You just use plain data. Though the trade-off is that you have to call render() yourself. I prefer it that way though.
SvelteKit made me love the web
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.
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.
lol Great insight. I really trust an opinion about something you admittedly don't use. Also is "aura" a technical term?
[flagged]
[dead]
[dead]
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?
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
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.
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.
I used to spend a lot of time here discussing and debating frameworks, not so much lately. It's a depressing how much time we spent in framework wars. I don't miss it.
This was simply replaced by LLMs wars. I find it even less fun.
Svelte is faster and smaller on client devices than React is. If you care about user experience you should probably care, yes.
Time to ask the agent to spit out compiled wasm then if it doesn't matter.
Agreed, everything is trending back to C
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.
And then you can no longer change a label without LLM assistance. I don't doubt this suits some people but impotently begging Claude to fix a critical bug while your boss looks over your shoulder must be quite humiliating.
> 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.
For what it is worth, I care, if only for the simple fact that it is an interesting project.
This kind of post is basically spam.