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 8 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 5 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 5 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 4 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.
prophesi 48 minutes ago [-]
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.
runtime_terror 8 hours ago [-]
DeepSeek Latest does a great job with Svelte/Kit apps if you want to use an open weight models
8 hours ago [-]
OtomotO 6 hours ago [-]
I will never use anything else than HTMX or Elixir/Phoenix anymore.
Unless I am paid to do it.
jamies 13 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 12 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.
zuhsetaqi 29 minutes ago [-]
Has it any advantages to Tauri?
spieke 6 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.
ForHackernews 3 hours ago [-]
Is Wails like Tauri but for Golang?
stillatit 11 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 10 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.
DrScientist 36 minutes ago [-]
> 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?
pelagicAustral 3 hours ago [-]
> lightning-fast static sites with Sveltekit
[???] Why the hell would I use SvelteKit for a static site?
weitendorf 2 hours 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.
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.
tonyoconnell 9 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 3 hours 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 4 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 10 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 10 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 11 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?
zuhsetaqi 20 minutes ago [-]
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.
brachkow 11 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 10 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 13 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 10 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.
rukshn 46 minutes ago [-]
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.
I love that stores comes out of the box and works well. No more callbacks for two way binding and Vue $emit hacks.
sensanaty 3 hours ago [-]
Are they still sticking to that godawful routing nomenclature of +page.svelte in infinite nested folders?
blakeashleyjr 14 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 14 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 13 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 13 hours ago [-]
Tells you something about the average React code
dale-cooper 5 hours ago [-]
Imo, it tells you how many footguns there are in regards to performance in React.
ceejayoz 12 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 9 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?
ceejayoz 1 hours ago [-]
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.
DonHopkins 9 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 5 hours ago [-]
LLMs write bad code for everything, it isn't just React unfortunately.
zuhsetaqi 16 minutes ago [-]
But it can only write the code as bad as the framework allows and React allows a lot of bad code.
alpha_squared 13 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 11 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 12 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 13 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.
afavour 12 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.
Recursing 13 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 10 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 9 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 9 hours ago [-]
[dead]
onemoresoop 12 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 13 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 10 hours ago [-]
svelte is like go, and react is like javascript. alot easier to write non-performant javascript then non-performant go.
DonHopkins 9 hours ago [-]
Also, Svelte is like Go, and React is like Checkers. ;)
theflyinghorse 12 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 12 hours ago [-]
LLMs are great at Svelte
sampsn 14 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 13 hours ago [-]
svelte is way more performant than react.
esafak 13 hours ago [-]
LLMs don't struggle with Svelte. Why wouldn't you use it?
nozzlegear 13 hours ago [-]
What's the point of anything?
pelagicAustral 2 hours 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.
cristaloleg 2 hours ago [-]
I'm not actively using Svelte (even not doing FE), can you elaborate what they constantly reinventing?
written-beyond 1 hours ago [-]
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.
pelagicAustral 2 hours ago [-]
Read this comment section alone, it's aready been explained.
krehwell 1 hours ago [-]
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
59 minutes ago [-]
stephaner 5 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.
gozzoo 2 hours ago [-]
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?
mindwok 2 hours ago [-]
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.
lelandfe 43 minutes ago [-]
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.
mindwok 36 minutes ago [-]
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.
lelandfe 25 minutes ago [-]
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.
chrysoprace 13 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 6 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.
mexicocitinluez 1 hours ago [-]
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.
shreedx 3 hours 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.
dankobgd 2 hours ago [-]
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.
argentinian 13 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 10 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 5 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.
jesse_dot_id 11 hours ago [-]
SvelteKit has incredible DX. I use it for everything these days.
wg0 5 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]
> 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?
herrherrmann 1 hours ago [-]
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.
thevivekshukla 6 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.
ramijames 12 hours ago [-]
I migrated from Nuxt to SvelteKit last year and never went back. It's great.
CharlesW 11 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 5 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.
tnkuehne 3 hours ago [-]
SvelteKit made me love the web
efilife 4 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
cpt100 5 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.
jamesnorden 2 hours ago [-]
Is this what AI psychosis is like?
bigstrat2003 5 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 5 hours ago [-]
So, using nextjs is LLM slop?
sharktheone 16 hours ago [-]
Still waiting for remote functions to become ready :/
chrysoprace 13 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 12 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 13 hours ago [-]
I've had no problem using them in 2.x
cassepipe 13 hours ago [-]
What was used instead before ?
chrysoprace 13 hours ago [-]
The idiomatic way to do data fetching in stable SvelteKit is via load functions.[0]
They still do a good job and allow you to cache the results and invalidate that cache, but they are at a route/layout level rather than at a component level, which is what remote functions solve.
I love svelte, but I think in the world of agents programmer ergonomics is no longer relevant.
JodieBenitez 5 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.
marmarama 27 minutes ago [-]
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.
mexicocitinluez 1 hours ago [-]
Why wouldnt frontend frameworks be relevant?
tamimio 12 hours ago [-]
A couple years ago I wanted to make a ui for an embedded software I made, after few research I got bamboozled with webdev eco system, it was the most frustrating thing to read, then found svelte in its first version and never looked anywhere else, the closest to vanilla, simple, and fast.
slopinthebag 12 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_ 7 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 5 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 6 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.
mexicocitinluez 1 hours ago [-]
lol Great insight. I really trust an opinion about something you admittedly don't use. Also is "aura" a technical term?
huflungdung 3 hours ago [-]
[dead]
favori995749721 10 hours ago [-]
[flagged]
nayaravis 8 hours ago [-]
[dead]
sghiassy 11 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 10 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 3 hours ago [-]
>humans
It is probably LLMs all the way down.
rbits 6 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 4 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.
password54321 3 hours 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.
afavour 8 hours ago [-]
Svelte is faster and smaller on client devices than React is. If you care about user experience you should probably care, yes.
etatester 8 hours ago [-]
Time to ask the agent to spit out compiled wasm then if it doesn't matter.
x-complexity 6 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.
jamesnorden 2 hours ago [-]
This kind of post is basically spam.
goolz 11 hours ago [-]
For what it is worth, I care, if only for the simple fact that it is an interesting project.
Rendered at 12:17:04 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
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?
[???] Why the hell would I use SvelteKit for a static site?
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.
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.
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'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.
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?
You can enforce keeping them in sync at CI time. This is more effective in a monorepo.
But fair point on the complex types.
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.
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?
They still do a good job and allow you to cache the results and invalidate that cache, but they are at a route/layout level rather than at a component level, which is what remote functions solve.
[0] https://svelte.dev/docs/kit/load
A (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.
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.