Hacker News Reader

Comment by 383toast | Hacker News Reader

what's the point of svelte in a world where the llm is much better at react due to massively more available training data?

View on HN

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.

Tells you something about the average React code

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.

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?

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.

Imo, it tells you how many footguns there are in regards to performance in React.

LLMs write bad code for everything, it isn't just React unfortunately.

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.

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.

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.

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.

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.

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)

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

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.

https://news.ycombinator.com/item?id=35631889

https://donhopkins.medium.com/the-x-windows-disaster-128d398...

https://www.youtube.com/watch?v=mg8xfl4L6HQ

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

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.

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

Also, Svelte is like Go, and React is like Checkers. ;)

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?

Reply on news.ycombinator.com