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.
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).
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.
every time I see this argument I think of the fact that one of my current side projects is written in D with qt bindings off github - an obscure library for an obscure language - and claude had zero issues with it. I had to guide the architecture pretty heavily, but the fiddly bits of interfacing multithreaded c libraries to D's garbage collector and qt's event loop were all thanks to the LLM, and done a lot quicker than I would have.
This seems like flame bait, but I'll take the question seriously: I would rather write a Svelte application by hand than manage a React one via LLM. It's just a more intuitive framework, fewer pitfalls, cleaner reactivity, and is much more performant out of the box.
There is an argument to choose the ecosystem with the best code quality so the training data pushes the general balance to better systems. There is a lot of bad react code not to mention lots of change in react itself over time.
React is a resource hog on the client. I really dislike it as a user. In terms of maintaining a codebase though, with LLMs it’s probably not a problem anymore with all the changes React keeps on undergoing. If you don’t need it why bother with it?
It's actually the opposite now. I have never used Svelte until LLMs came around. LLMs are better at writing Svelte than React, and then you also get a faster frontend by default.
It's like Rust. Way more Python than Rust in the training data, but with LLMs you're much better off defaulting to a Rust backend and Svelte frontend than any other combination. I'd say "unless you have a specific reason", but besides legacy requirements, there is actually no reason.
What's the point of using a slow frontend framework just because you're familiar with it, instead of a fast frontend framework which the LLMs can write equally well (or better)?
+1 for Wails mention: just discovered it recently which brought me to Svelte--couldn't be more impressed. Golang "backend" w/ a Svelte "frontend" to build desktop apps the fraction of the size of Electron is a killer imo.
Not sure, never heard of it, but looking at the README it seems similar but w/ a Rust backend?
We do a lot of data/quant analysis w/ Go which is great for that; then having the opportunity to slap on a lightweight GUI allow us to make some great internal tools etc.
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.
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.
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.
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.
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 and any backend you have.
I used mainly Vue from 0.12 until 3 (migrated one project to 3 but didn’t work with it extensively), with a bit of react sprinkled in. Mainly react the last 4 years or so, which let’s be honest is mainly not me writing the code.
I tried Svelte a couple times over the years, never really clicked for me though.
Other advantages of Svelte over React/Vue is that it does not require a Svelte specific library or wrapper, you can use vanilla JS libraries and it works seamlessly. I consider that as plus, you can old good old Chart.js, Ag-grid, etc without any wrapper, I tried some libraries with React/Vue that had wrappers for multiple frameworks, and most of them were painful, because each framework/library has their way to do things that collides with them, while Svelte is basically vanilla web tech with some sparkles over it.
I've used various vanilla js libs with Vue over the years. It was always pretty easy to make a wrapper component and hook whatever library up to the lifecycle, usually just a few lines of code. I'd prefer that over just making random charts everywhere if I was using something like highcharts.
I use React, Vue, and Svelte extensively, and I don't think that there is any problem with integrating 3rd party JS libraries in any of these frameworks.
React, as the most bare-bones framework, might be simplest to integrate, and you can see that by the enormous size of its ecosystem.
Vue and Svelte will have problems with integrating various devtools, due to the fact they use custom syntax to mimic native web tech. In Vue, this problem is solved by framework popularity and the fact that the Vue team produced most of the key devtools, so Vue is, of course, supported.
Svelte, on the other hand, still works badly with Storybook and linters.
A good counterexample to your take will be that I was unable to use the JS version of Framer Motion with Svelte without huge caveats that made making any complex animation impossible. I wasn't able to do so with Vue, for roughly the same reasons, but Vue, as a big framework, got 1st party support.
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...
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.
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.
I love the hands-on developer experience of programming in Svelte. But since we're in October of 2026 I have to ask, is the vibe-coding experience in Svelte any different than in React? Can anyone with experience in both comment?
In early 2026 I struggled a lot with models messing Svelte 4 and Svelte 5. I'm sure same thing will occur with load function vs remote functions, once they will be released
Exact same. I was a huge user of SvelteKit from 2022 to early 2025. But ever since LLMs got good enough I went back to React, because the ecosystem size matters a lot more once the coding experience is automated away. And early models were much much better at React than they were at Svelte – I suspect that difference may be gone now but is there a good reason to switch back to Svelte?
A good reason to use svelte instead of React is performance. LLMs not only got us more convenient development but also users that use their hardware for longer since the prices are so high.
Yes. We open sourced an SSG based off SvelteKit about a year ago and were starting building AI tooling and product workflows around it, https://statue.dev but have since mothballed it.
For most of 2024-2025 frontier models really struggled with Svelte 4 vs 5 compatibility issues. Some of the main contributors, to their credit, really put in a lot of work to create benchmarks/MCP/other tools to make AI better at using Svelte. Personally I am just not a fan of MCP and other tools like that at all, and decided I'd rather just use vanilla css/js for new projects.
Look at this; it's literally multiple times more expensive to have a model sifting through all this stuff in every context use them with a tool: https://svelte.dev/docs/ai/prompts/llms.txt All of these are input tokens and turns to gather context.
The "too niche to be a major training priority" dilemma is actually a really big problem that almost all new or emerging dev tools have now. Incumbents and category leaders are priorities and show up in major benchmarks, so models develop excellent tacit knowledge and capabilities with them and expose it everywhere all the time for "free" in their weights. Everything else is at a major disadvantage because models don't know about them, how to use them, how they work, what they're for/why, and every time you use them you pay a big capability and token hit because models only learn about them in-context.
I don't blame the Svelte team for this at all. There should be a better way for devtool projects to contribute to frontier labs training pipelines or properly posttrain their own agent coding models.
This is why I switched to Astro/React in 2024. I wonder where I would be now if I had stuck things out. Svelte is very fast and elegant. I found that I can use Astro for anything I thought I might need NextJS for though.
I still use Svelte but I switched to Astro too. I think the best thing about it is that its devs are focused on building primarily a good ssg.
The Svelte people are primarily building a frontend framework and added sveltekit as an addition. Using Svelte in astro even feels nicer to me.
I strongly recommend vanilla html, js, and css. For me the benefits of having no npm and related ecosystem tools and no dependencies far outweigh any benefits you get from switching to specific framework. It took me just as long to learn modern css, html, and basically all the browser APIs as it did to learn how to setup+build+modify+deploy my svelte-vscodeextension-webview project without getting bogged down in the tooling.
All those tools and packages are constantly making breaking changes or introducing incompatibility issues or becoming obsolete, and there is so much maintenance. I went pretty deep on CSR/SSG/browser automation over the past two years and realized that everything you get out of these tools is probably 20-400 lines of javascript you could just ask an LLM to implement when you need it. I’ve seen people waste so many hours, days, and weeks on tailwind ui crap (solvable in minutes with css), vitest and object lifecycle crap (use the browser debugger, do e2e tests) and major version upgrades (there’s about 95% less of this in the browser and >99% less outside experimental APIs).
I think for Facebook/Github sized web applications, with really big teams and lots of custom tooling (eg React) these frameworks make sense. Most websites just need basic file serving/rendering, to send and respond to http requests, and some javascript to run on the client (but html and css can actually handle many core UI patterns). I’ve been much happier not using frameworks because my projects just work and the knowledge I build doesn’t constantly churn.
We had an existing sveltekit application and its components, tooling, etc and used statue to develop the landing page/legals/docs/marketing portion of our site as an SSG, deployed separately but with shared logic.
Our application was behind a proxy that requires auth, and we could host our SSG on Cloudflare pages, so we didn’t have to expose any application server/compute (besides auth) to the public Internet. To me this was very desirable for security and devex: we could develop the two applications independently and be pretty lax with the static site.
> and decided I'd rather just use vanilla css/js for new projects.
So is the rise of AI coding, the end of frameworks?
Frameworks were created to reduce boiler plate ( at the expense of new abstractions which occasionally leak ) - boiler generation is less of an issue for AI, and the underlying platform is very well specified?
I guess the only problem with vanilla is if the sheer volume of text overwhelms the context?
Even more fundamentally, frameworks were created to reduce the developer skill required to build applications. This has been a pipe dream many have chased since COBOL replaced assembly language.
LLMs are probably the first technology that actually approaches doing that. And yes, they don't need frameworks, they're indifferent to the amount of code or boilerplate needed, don't care about the developer "experience," and will write vanilla JS and HTML just as well as anything else you ask them to do, maybe better.
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
I insist on certain ways to use CSS (this, I realized, is where most of the untapped "alpha" is. There are a lot of patterns, like the css checkbox trick and using selectors/tags to pull data from html element attrs, that can introduce a lot of interactivity and generality without JS) and specific design+page contents. Then I typically look at the output visually and make sure the structure doesn't do anything stupid. To fix things I often will just start editing the html and css manually until the page looks exactly like I want it, then save the temp state and pass it back into the model to make the code changes.
But I'm working towards training my own preference set and training pipeline/tools so that I can get models to output things the way I like without all the process/styling/etc. steering that is mostly shared between sessions. This is basically why I think coding agents are long-term only going to be used for vibe coding or to replace less skilled SWEs. You can't get them to consistently do things the way you want or build new devtools/abstractions that get fully internalized and baked into the weights unless you trian them. And a very useful thing about vanilla css/html is that they are much more easily verifiable and something you can generated/search synthetically vs SSR-npm style output.
i'd expect the fact that svelte doesn't have a shadow dom that gets recomputed all the time that it would be a significant performance and memory benefit for most apps. i'm not an expert though so idk if that's 100% accurate
I 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 experience was amazing. Hoping models close the gap fully so I can stay w Svelte -- I do still like reading and tweaking the 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.
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.
> Honest question? Whatever the agent is best at programming out to achieve a high quality outcome works for me. Just write the acceptance tests and be done with it
Even under your premise, the framework that helps agents get there faster is the better framework, programming capabilities notwithstanding.
Yup, LLMs can just write Python scripts that can just do the same thing for you without frameworks, NPM, Yarn, dependencies, sneaky bugs, random packages needing updates.
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.
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 decide to move away from Svelte.
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.
fwiw our whole company has multiple large Svelte/Kit apps and I've found DeepSeek Flash Latest to be really capable with it as well if anyone's looking for an open weight model to work on Svelte code.
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.
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.
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.
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.
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.
I just hated React with passion and then I spent significant time with Svelte a few years basically to appreciate how much better React is.
Svelte had one edge - compiled code making surgical DOM updates. React has a compiler too and if you ever have opened Facebook or Instrgram, all that UI is compiled by a React compiler already.[0]
I also find arguments like this quite weak. YouTube, Facebook et al work like absolute horseshit compared to other websites and web apps. If anything, they proof that these big companies manage to make simple web applications as bloated and slow as possible.
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.
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.
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.
172 comments
[ 0.27 ms ] story [ 20.6 ms ] threadI've had to work on a Next.js for work and much prefer Sveltekit. Excited to try this release!
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).
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.
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.
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.
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 and any backend you have.
I tried Svelte a couple times over the years, never really clicked for me though.
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.
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 do think react (without a framework) is the beat option though.
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.
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.
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.
[???] 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.
So is the rise of AI coding, the end of frameworks?
Frameworks were created to reduce boiler plate ( at the expense of new abstractions which occasionally leak ) - boiler generation is less of an issue for AI, and the underlying platform is very well specified?
I guess the only problem with vanilla is if the sheer volume of text overwhelms the context?
Even more fundamentally, frameworks were created to reduce the developer skill required to build applications. This has been a pipe dream many have chased since COBOL replaced assembly language.
LLMs are probably the first technology that actually approaches doing that. And yes, they don't need frameworks, they're indifferent to the amount of code or boilerplate needed, don't care about the developer "experience," and will write vanilla JS and HTML just as well as anything else you ask them to do, maybe better.
I’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
And if you are looking at it - do you insist on certain patterns or structure to allow yourself to more easily navigate it?
But I'm working towards training my own preference set and training pipeline/tools so that I can get models to output things the way I like without all the process/styling/etc. steering that is mostly shared between sessions. This is basically why I think coding agents are long-term only going to be used for vibe coding or to replace less skilled SWEs. You can't get them to consistently do things the way you want or build new devtools/abstractions that get fully internalized and baked into the weights unless you trian them. And a very useful thing about vanilla css/html is that they are much more easily verifiable and something you can generated/search synthetically vs SSR-npm style output.
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 experience was amazing. Hoping models close the gap fully so I can stay w Svelte -- I do still like reading and tweaking the code.
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.
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.
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.
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.
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?
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.