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