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.

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...

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.

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.

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.

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.

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.

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)?

svelte is like go, and react is like javascript. alot easier to write non-performant javascript then non-performant go.

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)

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.

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?

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.

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.

LLMs are great at Svelte

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?

svelte is way more performant than react.

LLMs don't struggle with Svelte. Why wouldn't you use it?

What's the point of anything?