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.
> and decided I'd rather just use vanilla css/js for new projects.
So is the rise of AI coding, the end of frameworks?
Frameworks were created to reduce boiler plate ( at the expense of new abstractions which occasionally leak ) - boiler generation is less of an issue for AI, and the underlying platform is very well specified?
I guess the only problem with vanilla is if the sheer volume of text overwhelms the context?
Vanilla css/js are not really that voluminous. Actually, they tend to be smaller than the compiled targets you get from conventional web dev builds.
I’m not really sure that most web frameworks reduce boilerplate. There is a lot of boilerplate involved in setting up routes, and builds, and so on. As far as I can tell they only really make sense for very large teams (who need a uniform shared data model, design language, processes, etc.) and people who really want to run server side js/do a lot of SSR.
The thing about web “frameworks” is that they’re not that different in structure from what you’d build to do SSR and a repeatable way to add pages/dirs and shared assets, in any language. You can build a minimal version of something that does that in less than an hour, at least in Go. go:embed and a factory method for handlers :)
I think we’ll all end up with more bespoke “frameworks” (specialized web servers) with less gravitational pull towards dysfunctional (IMO, the node ecosystem) tooling, and still have many people using the best major frameworks. Truly large projects will still need to use react and svelte and co unless they can train a model on their own framework. But that’s really hard
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.
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?
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?