I love the hands-on developer experience of programming in Svelte. But since we're in October of 2026 I have to ask, is the vibe-coding experience in Svelte any different than in React? Can anyone with experience in both comment?
Yes. We open sourced an SSG based off SvelteKit about a year ago and were starting building AI tooling and product workflows around it, <a href="https://statue.dev" rel="nofollow">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: <a href="https://svelte.dev/docs/ai/prompts/llms.txt" rel="nofollow">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?
> Frameworks were created to reduce boiler plate
Even more fundamentally, frameworks were created to reduce the developer time and skill required to build applications. This has been a pipe dream many have chased since COBOL replaced assembly language.
LLMs are probably the first technology that actually approaches doing that. And yes, they don't need frameworks, they're indifferent to the amount of code or boilerplate needed, don't care about the developer "experience," and will write vanilla JS and HTML just as well as anything else you ask them to do, maybe better.
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
stillatit · · focus · HN ↗
weitendorf · · focus · HN ↗
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: <a href="https://svelte.dev/docs/ai/prompts/llms.txt" rel="nofollow">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.
tonyoconnell · · focus · HN ↗
sureglymop · · focus · HN ↗
weitendorf · · focus · HN ↗
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.
pelagicAustral · · focus · HN ↗
[???] Why the hell would I use SvelteKit for a static site?
weitendorf · · focus · HN ↗
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.
DrScientist · · focus · HN ↗
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?
SoftTalker · · focus · HN ↗
Even more fundamentally, frameworks were created to reduce the developer time and skill required to build applications. This has been a pipe dream many have chased since COBOL replaced assembly language.
LLMs are probably the first technology that actually approaches doing that. And yes, they don't need frameworks, they're indifferent to the amount of code or boilerplate needed, don't care about the developer "experience," and will write vanilla JS and HTML just as well as anything else you ask them to do, maybe better.
weitendorf · · focus · HN ↗
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
DrScientist · · focus · HN ↗
And if you are looking at it - do you insist on certain patterns or structure to allow yourself to more easily navigate it?