alt Hacker NewsThe bloat isn't coming from "huge frameworks" like React.
To give some concrete numbers: a barebones react project created with `pnpm create vite -t react-ts` clocks in at ~60KB compressed:
dist/index.html 0.46 kB │ gzip: 0.30 kB
dist/assets/react-CHdo91hT.svg 4.13 kB │ gzip: 2.14 kB
dist/assets/index-D8b4DHJx.css 1.39 kB │ gzip: 0.71 kB
dist/assets/index-9_sxcfan.js 188.05 kB │ gzip: 59.16 kB
dist/index.html 0.46 kB │ gzip: 0.30 kB
dist/assets/index-1byZ3dr3.css 1.27 kB │ gzip: 0.65 kB
dist/assets/index-CKXNvRRZ.js 60.77 kB │ gzip: 24.44 kB
> When a simple home page dashboard or a notes page takes more than 10s to load on a 10G connection peered within 5ms of the host, and 95% of this is spent in JS.
You can create that kind of garbage with any framework, or without framework. You can actually do worse with the traditional way of using third party dependencies wholesale (the jQuery way), you can be downloading 200KB for 1KB of actually used code.
Edit: Also, the comparison in the article is pretty stupid. A full view in React is not much larger than "a React button", it's upfront cost + marginal cost.
Replies
Downloading =/= executing. Downloading 60 kb of compressed JavaScript isn't the problem, the problem is running that JavaScript, and all the resulting web calls that JavaScript will do, and all the resulting compute it will take to... I dunno, make the button round or whatever. Load time is no longer a solid metric for a good experience, that's very late 00's of anyone to say, the metric now is how long until the page is laid out, and the controls on it are responsive?
Edit: Also how hot is my phone?
Isn’t using compressed numbers pretending that network bandwidth is the only cost of bloat?
All that JS, once decompressed, needs to be parsed and actually evaluated. That is where it hurts even people on gigabit connections.
I think frontend bloat has arrived at such an absurd level that it kind of makes me wish broadband and mobile speeds, and JS engine speeds, had paused their advancement for 15 years so that FE developers would have had to learn to write good code. Presently there is a whole generation of developers who built their whole careers in this era where you can get acceptably mediocre performance even with wildly inefficient code and an absurd amount of dependencies, most of them barely used on a given page. They’ve never been challenged to do any better, so i don’t really blame them.
> The bloat isn't coming from "huge frameworks" like React.
I agree. This is such a familiar cycle. People still blame Java for things that were really the fault of the average "enterprise Java developer".
The reality is that these frameworks don't automatically lead to bloated code shipping everything.
Just to add Svelte (`pnpm create vite -t svelte-ts`) ~8KB
dist/index.html 0.46 kB │ gzip: 0.30 kB
dist/assets/index-yJpzg09Q.css 1.26 kB │ gzip: 0.63 kB
dist/assets/index-CxtJFQC8.js 17.91 kB │ gzip: 7.72 kB> You can create that kind of garbage with any framework, or without framework
I would think it would be quite a challenge to accomplish the given task without a framework?
>You can create that kind of garbage with any framework, or without framework.
The whole point of the framework is to make even absolute garbage stick together. (While making the developer replaceable.)
Author here: Fair point—React’s baseline isn’t a monster. ~60KB compressed for a barebones Vite/React setup, or even ~25KB with Vue. Medium projects at 200-300KB are definitely workable.
But here’s the point: a single React/ShadCN button, straight from their official docs, still outweighs Nue’s entire SPA demo. Add more widgets—tabs, modals, whatever—and that gap only widens. Nue is flipping the script. Web standards let us start lean and stay lean—smaller codebases, faster HMR, quicker builds. That’s the win: efficiency that scales without piling complexity.