4/1/2025 at 8:03:02 AM
I see a lot of people angry at "Nue" in various ways, and I can't help but think these are people heavily relying on React and missing the overall issue. The issue is that these huge frameworks have made the web a horrible slow mess. I deal as DevOps/SRE daily with these services, and finding one that will do a first load under 10s is close to impossible. 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, that's when you know the typical current webapp has reached a massive state of bloat only supported by fast browser engine, and people not having expectations.I'm not hopefully Nue would revolutionize this since there are plethora of Web SaaS companies just wanting to use "common" frameworks... but I can at least root for them.
by fcpk
4/1/2025 at 12:09:05 PM
The 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.
by oefrha
4/1/2025 at 12:39:28 PM
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.
by tipiirai
4/1/2025 at 4:53:56 PM
> a single React/ShadCN buttonSo don't use ShadCN? It's so weird to put up this strawman app and then be like "see what's wrong with React"? Like showing two boards nailed together and being like "can you believe I needed all those power tools just to do this?"
> Add more widgets—tabs, modals, whatever—and that gap only widens
This is the benchmark I want to see. Two full-featured apps built with minimal prod dependencies. There's a pretty good chance that the various ShadCN modules share many of their dependencies so that importing more doesn't necessarily mean a linear increase in bundle size. It could be that once you build something full-featured, React projects come in smaller, or at least not big enough to invalidate the other upsides of choosing it.
by schwartzworld
4/1/2025 at 5:19:45 PM
But the OP did implement a fully featured app as the Nue comparison half of the benchmark. I have never used Nue and don't know if I ever would. I just think to be fair to the OP, even if incremental cost declines as you keep adding stuff in React, there's no way it is negative, which means the benchmark you asked for logically must have a similar result?by 9question1
4/1/2025 at 6:20:14 PM
> Two full-featured apps built with minimal prod dependencies.This isn't what you see in the real world. I'd rather see comparisons to real life (where 99.9% of web apps are bloated garbage) than nonsense synthetic benchmarks like that.
by mvdtnz
4/2/2025 at 11:16:50 AM
Does an ecosystem like that exist for Nue? If not, it’s the only fair comparison. The ShadCN button comes with styles and behavior that wasn’t implemented in the Nue demo.by schwartzworld
4/2/2025 at 1:09:21 AM
The problem is you could also just do that to Nue, there’s nothing really preventing that.If your team or company has bad dependency hygiene, changing a single framework is not going to help you.
by bobthepanda
4/1/2025 at 12:52:59 PM
An extra 100-200KB compressed is a ~100ms one time cost once in a while for the majority of my users, and ~1s for 95%+ of users. At that point I'm going to optimize for developer productivity (which includes breadth of ecosystem). I can be both productive and respectful to my users with these common frameworks.Note that I'm very mindful of web performance, and I've been quite vocal on this site about some alarming trends like calling for the end of bundling (native esm) and roundtrips for everything (liveview and co., or at least the abuse of them). In my experience waterfalls and roundtrips are the number one thing hated by people on slow and/or unreliable networks; 100KB added to a flat bundle at load is almost nothing.
by oefrha
4/1/2025 at 2:00:37 PM
> An extra 100-200KB compressed is a ~100ms one time cost once in a while for the majority of my users, and ~1s for 95%+ of users. At that point I'm going to optimize for developer productivityIs that 100ms on fiber? Cable? 5G? 4G?
Is that for the first button? Or each button? And what happens when you next need to manage dates as objects? Do you pull down dayjs or do you wrangle it yourself? What other libraries do you need to add? How's build speed? How much time to the linters take as they cascade through all that code? How are your Next.js (a pretty standard companion to react) version updates going? Keeping up with security alerts?
I'm biased against React because I manage a team trained in classic web design who now have to manage a giant React codebase and learn its special way of doing things, and it's a slog.
Agencies are going to keep building with React because they can get 90% of a project done in no time flat, and they don't have to deal with the infra challenges after they get their check. Small clients like us will continue to fall for it and slowly grind to a halt as the infrastructure pulls the team to a standstill.
by troyvit
4/1/2025 at 11:05:43 PM
No, adding another button does not duplicate the entire underlying libraries used to display said button.by anon7000
4/2/2025 at 12:15:59 AM
Yeah, I don’t even know why people who are that clueless about frameworks are commenting; it takes less than an hour of learning of modern web development, from scratch, to shut down that notion. And other libraries to manage dates and stuff? Excuse me? How does that have anything to do with the rendering framework? Completely orthogonal choices.And asking about basic math on download speed is golden. No idea how someone can “manage a team trained in classic web design” without that knowledge and then pretend to care about performance.
by oefrha
4/2/2025 at 3:00:26 PM
Eh, I'm clueless about this aspect of the framework (if you can call such a steaming pile of resume-driven-development such), and honestly I'm thankful for it.Libraries like dayjs add complexity to the overall codebase and it's another piece of code you need to keep track of, update, and repair when its makers decide to go a different direction with it or some script kiddie decides to introduce a backdoor into it.
I think your larger concern shouldn't be about the "clueless people" who are commenting on this thread and rather the number of upvotes my comment got (especially compared to your rant). Clearly it struck a chord.
People are commenting and upvoting because the choices that went into building React leaves a lot of room for frameworks like Nue, Vue, hell even HTMX. Just because (it sounds like) you've staked your career on thinking React, the McDonalds of frameworks, is awesome doesn't change that.
by troyvit
4/3/2025 at 9:03:12 AM
No I’ve not staked my career on React, I’m not even primarily a front end guy and React is my least favorite framework among popular ones, but thank you for your concern. I was debunking one ridiculously wrong comment criticizing my least favorite framework with solid, reproducible statistics, but that’s apparently a rant compared to your very insightful questions like “100ms to download 100KB, is that fiber? Cable? 5G? 4G?”, then okay. You clearly struck a chord with a large number of people so out of touch that they believe a copy of React is required for each button, and pride themselves on such ignorance because it’s “resume-driven-development”, so congratulations.(Another tip: Don’t bring votes into discussions, it’s both against site guidelines and laughable.)
by oefrha
4/1/2025 at 8:22:04 PM
> I'm biased against React because I manage a team trained in classic web design who now have to manage a giant React codebase and learn its special way of doing things, and it's a slog.What special way is that? One of the big draws of React is its minimal api surface, and the ability to write standard JS alongside of your presentational HTML.
I am also curious what "classic web design" actually means, I have a theory, but I am curious all the same
by yuskii
4/2/2025 at 3:09:09 PM
I was speaking directly to the reactive framework itself (which is a smart way to get around some limitations), the div salad it pushes developers to sustain, and the fact that they felt they had to rewrite HTML such that instead of typing <h2> devs have to type something like <Heading.HTML is a pretty simple markup language and abstracting from it doesn't seem to make any sense.
And I think your theory about what I mean by "classic web design" is probably right; keeping the JS separate from mark-up is one example of how I wish I could go back in time.
But I can't. So it's time to learn to manage people who want to go this direction.
Meta wrote React for Facebook mainly, and most other projects won't touch that scale. In my organization's case it's like we're water-skiing behind an aircraft carrier. It's the wrong tool for the job, and having three people manage 37k lines of code (excluding libraries) is tough.
by troyvit
4/2/2025 at 10:48:15 PM
> HTML such that instead of typing <h2> devs have to type something like <Heading....but they don't? Just use <h2> haha
by girvo
4/1/2025 at 1:32:17 PM
Although payload can be indicative of page load speed, there are many good reasons Lighthouse scores are more complex than that. Specifically, at the start of this thread the criticism was that the js work in modern web apps is slow. I have thus far managed to avoid using react so I don't know the actual numbers, but I don't think the conversation should be reduced to payload size, even if it is obviously important. When I profile problematic pages, other than sites that don't properly scale their images, it is not usually network that bogs them down, it is the rendering.Even focusing on Lighthouse score or similar for a basic app is totally missing the point of Nue as presented on the linked page. It about a framework designed for speed that can handle data at scale, that is easier to control and personalize, and easier to model and thus architect. And yes, of course, most any framework can be used for good work, but the relevant question here is which one promotes it the most from start to finish, and makes it the easiest to implement. Speaking only for myself, this focus is great to see.
by sgc
4/1/2025 at 2:26:05 PM
How much is it React/Nue and how much is everything else?HTML has evolved in the last 15 years to be a platform for applications. The early Bootstrap was a terrible Rube Goldberg machine because CSS didn't have civilized layout mechanisms such as grid and flexbox. Newer frameworks like Tailwind are more sensible, but still add 50k to your bundle, and if your app is complex and developed under deadlines you probably have components that use Tailwind and Bootstrap and emotion and styled-components and raw CSS and you still have to write some SCSS to get the styles just right in the end.
I've been investigating the accessibility of various <Modal> components and found that they all suck because they do complicated things with <Portal>(s) and various-aria-attributes. HTML has had a <dialog> component that properly hides the rest of the page since 2022 but barely anyone was using it.
If you stuck to using Tailwind or Bootstrap or raw CSS and used a minimal widget set you can make small applications with any framework. If you wrote raw CSS and made the most of the widgets that come in HTML5 (like the new stylable <select>) you can make tiny applications.
by PaulHoule
4/1/2025 at 4:29:27 PM
Tailwind, at least for the last couple major versions, only adds the classes you actually use (plus the resets). Baseline size of the resets is far below 50k.Great point about the dialog element. I used it in a project recently for the first time... It was very nice to not involve a framework-heavy "portal" scheme, etc.
by kylecordes
4/2/2025 at 12:21:00 AM
You’ll add at least 100kb of text for class names styling each HTML element using tailwind.by fijiaarone
4/2/2025 at 9:55:06 AM
Since those class names are repeated, they will be gzipped to a very small size. And on top of that browsers/devices are much happier about HTML sizes than about JS sizes. See Performance Inequality Gap: https://infrequently.org/2024/01/performance-inequality-gap-...by troupo
4/1/2025 at 2:34:05 PM
I think Nue just puts you in the mindset of trying to keep the codebase as small and lightweight as possible. I wanted to rebuild my website with Nue and there was something telling me to avoid Motion, Tailwind CSS, etc. This philosophy can actually prove very helpful in the long term, however I feel that by using Nue you're really compromising on DX (development is much slower), although that might be because I'm not so familiar with creating websites without a framework. In any case, it's definitely worth a try.by a022311
4/1/2025 at 7:10:20 PM
> React’s baseline isn’t a monster.Yes it is. It’s not size, it’s logic: Every time the component rerenders, the root loop is executed. Why? The root loop reassigns every useEffect, reruns every useState, every other hook (and useSearchParams is executed n times for n components that need it in the hierarchy) when only the HTML needs rerender.
(Yes the programmer can optimize/memoize, and yes “a hook’s execution time is very short” (but multiplied by every cell in the table, when needed)). Must be the fault of the programmer if the framework has a super-intensive concept at the root.)
by eastbound
4/1/2025 at 7:33:46 PM
I'm old enough to remember when this simplified model was why people thought React was better than alternatives.by code_biologist
4/1/2025 at 8:07:28 PM
I know, right? And where is Preact, Inferno and others sped-up React-like now?by lastdong
4/1/2025 at 10:44:41 PM
What do you mean where are they? They are still around. Preact especially is doing really cool work adding signals on top of a similar to react model.by teg4n_
4/2/2025 at 6:34:44 PM
> It’s not sizeThat's what TFA is complaining about: size. But nice pivot, hope your head isn't spinning too much.
by lucsky
4/2/2025 at 12:22:31 AM
Yeah, react developers don’t even realize that there is execution time as well as download time for an app.by fijiaarone
4/1/2025 at 11:50:34 PM
this means the example wasn't made to be lightweight. You'll need an apples to apples example to convince any detractor. Implement the same app using two different toolsets, document the process with each and then benchmark itby ouraf
4/1/2025 at 2:22:56 PM
To be honest, I am very confused with this benchmark. It is misleading.What is the actually size of the production build portion only for that button part? Because I think that the ShadCN button source code is not equal in size for the button that client downloads in production environment. Especially if you have SSR.
by nicce
4/1/2025 at 4:29:50 PM
If you look at the demo, all of the payload comes from react and the tailwindcss classes that the shadcn button refers to.It's dishonest to call this the payload of "one shadcn button" since it's basically all react/tailwindcss fixed cost and not literally a shadcn button.
But still, that's a decently broad demo to fit in a small payload, so the exaggeration kinda takes away from that.
The main thing I care about in client development is the state management solution since that's where most of the complexity comes from, and it's what makes or breaks an approach. In React, I use MobX which I see as the holy grail.
Whether Nue is nice to use or not for me is gonna come down to how nice this is to work with: https://nuejs.org/docs/interactivity.html
by hombre_fatal
4/1/2025 at 6:28:05 PM
> It's dishonest to call this the payload of "one shadcn button" since it's basically all react/tailwindcss fixed cost and not literally a shadcn button.Does the ShadCN button work without paying that cost?
by mvdtnz
4/1/2025 at 9:57:26 PM
Sure. If you just want the shadcn button by itself, it will generate this html: <button class="{tailwindcss classes}" />.And it has a dependency on some common tailwindcss classes that will get injected into your bundle.
Most shadcn components depend on tailwindcss classes, and how the whole shtick works is that tailwindcss only includes in your bundle the classes that your components use across your app. Which is kind of a clever integration for a ui component 'package manager' for reducing bundle size.
But most importantly, consider that OP's demo has very minimal CSS because they aren't using a CSS framework, and that has nothing to do with their Nue framework. It's not like their Nue framework comes with an optimized answer to tailwindcss/shadcn; you have to bring your own solution.
So if you use tailwindcss/shadcn with React, you'd certainly use it with Nue.
What Nue should do instead is add libraries to either side necessary to reach parity with the other side. Nue has built-in routing, so it would be fair to add react-router-dom to the React side. And they wouldn't have 100 people calling them out for the dumb benchmark.
by hombre_fatal
4/1/2025 at 8:03:40 PM
Are you really going to build a site which just consists of a button?by jmaw
4/1/2025 at 9:07:30 PM
If I'm working with a payload budget and I'm using React I guess so?by mvdtnz
4/2/2025 at 12:50:45 AM
Stop. You really do not need to be acting like this.by albedoa
4/1/2025 at 9:03:51 PM
Your question is, incredibly, more dishonest than the original claim. Truly impressive.by albedoa
4/1/2025 at 9:06:46 PM
What's dishonest about my question? Please keep your personal attacks to yourself.by mvdtnz
4/1/2025 at 4:31:39 PM
Seems like you should be correct. A shadcn button is just react, tailwind, and @radix/react-slot. But if you simply create a new shadcn Next.js template (i.e. pnpm dlx shadcn@latest init) and add a button, the "First Load JS" is ~100kB. Maybe you could blame that on Next.js bloat and we should also compare it to a Vite setup, but it's still surprising.by programmarchy
4/1/2025 at 5:02:12 PM
Yeah, but my point is that you download the runtime and core of React/Tailwind just once for the whole web page and those should be removed from the test, or at least there should be comparison which includes the both cases.You only need couple images on your webpage and that runtime size becomes soon irrelevant.
So the question is, that how much overhead are React/Tailwind CSS adding beyond that initial runtime size? If I have 100 different buttons, is it suddenly 10 000 kilobytes? I think it is not. This is the most fundamental issue on all the modern web benchmarking results. They benchmark sites that are no reflecting reality in any sense.
These frameworks are designed for content-heavy websites and the performance means completely different thing. If every button adds so much overhead, of course that would be a big deal. But I think they are not adding that much overhead.
by nicce
4/1/2025 at 9:17:58 PM
> Yeah, but my point is that you download the runtime and core of React/Tailwind just once for the whole web page and those should be removed from the test, or at least there should be comparison which includes the both cases.You think a test that is comparing the size of apps that use various frameworks should exclude the frameworks from the test? Then what is even being tested?
by mvdtnz
4/1/2025 at 9:34:16 PM
Actual overhead when the site is used in reality? How much ovearhead are those 100 different buttons creating? What is the performance of state managing? What is the rendering performance in complex sites? How much size overhead are modular files adding? Is .jsx contributing more than raw HTML for page size? The library runtime bundle size is mostly meaningless, unless you want to provide static website with just text. And then you should not use any of these frameworks.by nicce
4/1/2025 at 2:37:38 PM
[flagged]by jeffhuys
4/1/2025 at 2:45:18 PM
Some people just really like em dashes.by zerocrates
4/1/2025 at 1:01:12 PM
This sounds like ChatGPT’s voice :)by senordevnyc
4/1/2025 at 4:15:59 PM
It really doesn't sound like ChatGPT’s default voice, though it is pretty good at taking on different voices so in a sense you could say that about almost anything. It does use em-dashes, which people have recently started way over-indexing on as a ChatGPT tell, but lots of posters on HN have been using em-dashes for longer than ChatGPT has existed.It does read like marketing material, though.
by dragonwriter
4/1/2025 at 4:41:37 PM
It's not just the em-dashes for me. It's actually more these parts:But here’s the point:
That’s the win:
Those sound exactly like ChatGPT when I tell it to write in a more direct, opinionated style.
by senordevnyc
4/1/2025 at 5:06:27 PM
It reads like pretty much every piece of tech marketing/evangelism in the last several decades. Which, sure, ChatGPT nails pretty well if you tell it to do that, but... I don't think that has high specificity as a ChatGPT tell.Generic marketing speak is generic.
by dragonwriter
4/1/2025 at 6:05:58 PM
I agree with everybody else: it smells like ChatGPT. And I thought this before reading this chain.Actually, going through their entire profile, it makes it even more obvious:
> Author here. No need to update the resume yet—titles do keep shifting! React’s monolithic style has muddied the waters, making it tough to build clean business logic, prioritize performance, craft CSS design systems, or just focus on user experience. Nue’s here to unblock that—giving each role room to shine with leaner tools, not cramming everyone into the same heavy stack.
> Author here. React’s absolutely mature—no question there, with a skilled team behind it. But the button example highlights something off: a single component outweighing an entire app feels fundamentally broken. There’s clear room for fresh alternatives, especially now. You can see it here on HN—seasoned devs wrestling with React’s wild complexity. Nue’s a stab at fixing that.
Looks like they switch to ChatGPT-mode for most of their Nue replies.
by rob
4/1/2025 at 9:20:43 PM
I agree with you this is absolutely ChatGPT output. This should result in instant bans from HN in my opinion. I only come here to hear from human beings.by mvdtnz
4/1/2025 at 2:38:33 PM
It does, and it muddies the waters a lot. Why does it read like a sales pitch?by jeffhuys
4/1/2025 at 1:35:43 PM
ChatGPT learned that voice from actual people, you know.by balamatom
4/1/2025 at 4:12:09 PM
And yet, over the last year or two, people using ChatGPT to write their comments stand out like a sore thumb. The overall structure, the specific style of using em-dashes, semicolons, and colons...it's blindingly obvious.If you just go back a couple months and read OP's comments, they sound very different from everything they've posted today: https://news.ycombinator.com/item?id=42734300
To be clear, I don't really care, I use ChatGPT all day every day, but just letting OP know it's often pretty obvious when you have it write for you.
by senordevnyc
4/1/2025 at 4:47:21 PM
Yep, I read through some of their comments -- it is strange. I would certainly like to see people improve their grammar, punctuation, and general consistency; but, let's face it, people rarely care to.Call me paranoid (because, let's admit it, I am) but... after all, it's the Internet, and it's 2025! There's been enough controversy about the political power of speech over the past decade alone, that I can see people running their stuff through ChatGPT just to stay on the safe side and make things sound blandly "professional": just so they can avoid being taken the wrong way by a random reader who happens to strongly object to some particular aspect of their communication style.
(Goodness knows I've found myself on either side of all that at different times -- personally, I find it highly inauthentic to make noncommittal "positive" statements in lieu of plain observations. It's absolutely grating; while some other people seem to require it, and can be indeed quite self-contradictorily harsh about it.)
I can definitely see a major use case for LLMs there -- though I do find the implications quite terrifying. Call it political correctness, call it jamming stylometry, call it a day. Either way there's definitely some sort of power differential here that needs to be examined and I think the world is less prepared than ever to confront whatever its meaning turns out to be.
Which brings me to my other point:
>To be clear, I don't really care, I use ChatGPT all day every day, but just letting OP know it's often pretty obvious when you have it write for you.
Now this I don't quite understand. Pointing something out ("letting someone know") generally implies you want someone else to care about that something, even if you honestly don't. So, since you don't care -- why is it that you want others to? Honest question.
by balamatom
4/1/2025 at 5:05:20 PM
Would love to get some help on documenting Nue! Crazy amount of work for a non-native English speaker doing both coding and docs.by tipiirai
4/2/2025 at 1:04:47 AM
Yeah, that was ambiguous. I don’t care if people use ChatGPT to write for them, but don’t be so lazy with it that it’s so obvious and bland.by senordevnyc
4/2/2025 at 5:23:19 PM
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.
by xp84
4/1/2025 at 10:31:48 PM
> 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.
by jsight
4/1/2025 at 8:42:08 PM
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 kBby aubergene
4/1/2025 at 1:42:47 PM
> You can create that kind of garbage with any framework, or without frameworkI would think it would be quite a challenge to accomplish the given task without a framework?
by actinium226
4/1/2025 at 8:28:13 PM
before React took over, "SPAs" were written with jQuery and Bootstrap, and it was common to see a project with multiple copies of different versions of jQuery. Totally possible to bloat a website without a framework. just go old school!by floydnoel
4/1/2025 at 2:58:42 PM
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?
by ToucanLoucan
4/1/2025 at 3:58:34 PM
absolutely. page performance is the result of a hairball of initial asset loads, AJAX calls, ad-hoc roundtrips, telemetry bloat, ...It's so convoluted, and very app specific. Core web vitals provide the right framework to think about what is relevant, but in reality your app likely requires dedicated instrumentation to capture these phases accurately.
by trgn
4/1/2025 at 3:21:45 PM
I test my damn sites on a fucking iPhone 6 from 2014. Executing that JS is a breeze.React etc. runs just fine on absolute garbage kiosks. If you introduce 10MB of additional JS on top of 60KB of React, it's those 10MB's fault.
by oefrha
4/1/2025 at 6:13:45 PM
Downloading 60kb of compressed javascript takes way longer than executing it.by knubie
4/1/2025 at 6:55:05 PM
Executing 60kb of JS can take between 0s and infinity. You can't summarise it like this.by viraptor
4/1/2025 at 7:03:49 PM
It's gonna sound elitist but every one of these confident assertions on the part of, for the purposes of discussion I'm assuming are defensive React developers, reinforces that a sizable contingent of the aforementioned developer community has no grasp whatsoever on the fundamentals of programming.Hate me if you will, but holy fuck. "Downloading this code takes WAY more time than running it" with NO parameters whatsoever on what the code is doing is an absolutely ridiculous assertion.
by ToucanLoucan
4/1/2025 at 7:16:56 PM
Agreed. I don't think people realize that 5mb of a PNG is way different than 5mb of JS. The browser parsers that PNG way way faster than it parses JS.by azemetre
4/1/2025 at 10:02:12 PM
The PNG also doesn’t then go off and start pulling even more data down off the network.by FridgeSeal
4/1/2025 at 9:40:22 PM
No, it comes across as if y'all are having a bad faith argument about something outside of your field of expertise...Most React apps don't put an infinite loop in their components. The vast majority of the time it sets up initial state, maybe sets up a skeleton while loading some customer data, then shows a page with a few sections and a dozen inputs.
So "holy fuck" you should probably calm yourself down.
by Tadpole9181
4/1/2025 at 1:37:06 PM
>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.)
by balamatom
4/1/2025 at 8:18:47 AM
I'm not happy about how bloated most React sites are, and I've mostly stopped using it unless clients specifically request it after years of it being my main framework, but...> The issue is that these huge frameworks have made the web a horrible slow mess.
I don't think this is accurate. Most bloat in the web is caused by:
a) developers don't taking any time to optimize, lazy load, cache, minimize dependencies...
(This is partly on React, or may be on the culture around React that has made all of this normal and acceptable.)
b) the 300 tracking scripts every site has to try to squeeze as much revenue as possible
(I remember being shocked, some years ago, when I saw a site with 50 trackers. May be it was The Verge? Or some newspaper? Now I don't even bat an eye when the number is in the hundreds.)
React sites can be extremely fast if the developer cares, and the bloat it introduces is rarely relevant. The OP article describes a button as 78K, but that's because it's loading the whole of react for just a button.
If your page has hundreds of buttons, you don't bring 78K hundreds of times, and so complex sites built with React are not that inefficient.
As a Devops engineer, do you have stats on how much of that slowness is the framework or the actual app code?
by ikurei
4/1/2025 at 10:56:39 AM
> a) developers don't taking any time to optimize, lazy load, cache, minimize dependencies...> (This is partly on React, or may be on the culture around React that has made all of this normal and acceptable.)
Yes, that, too. But you are forgetting that React makes all that opimizing work necessary in the first place.
Networks are fast. Machines are crazy fast. Almost 30 years ago I was doing on-line adaptation of Postscript print files. So some form input and re-rendering the Postscript with the updates from the form values. Basically instantaneous.
by mpweiher
4/1/2025 at 4:35:58 PM
> Networks are fast.Well, it depends on what you mean by “fast”: bandwidth or latency? While the bandwidth has improved enormously over the years, latency… not so much. And it never will due to the simple fact that the speed of light is limited.
Most of the slowness seems to come about by treating latency as something that doesn’t matter (because the testing is done on a local, low-latency network) or will improve radically over time because bandwidth did (which it will not).
Unfortunately, React wants to be both a rendering library and also manage state by tying it to the component lifetime, which encourages cascaded fetching - exactly the kind of workload that is sensitive to latency.
by branko_d
4/1/2025 at 2:25:34 PM
> Yes, that, too. But you are forgetting that React makes all that opimizing work necessary in the first place.Isn't the runtime state optimization the only responsibility of React. It's a library. The rest goes for Vite, Deno et al.
by nicce
4/1/2025 at 12:21:00 PM
Low powered android devices are a thing. Networks outside of Metro US, EU, and parts of Asia, are also a thing.Check out google maps there’s more to the world than your open office.
by tmpz22
4/1/2025 at 12:33:12 PM
His point isn't "network/hardware is fast, so let's be inefficient": it is the opposite. "network/hardware is fast, so why is the page still slow?". On lower powered devices and slower networks, it's even more vital to author lean applications and web pages — but "things are slow even when the hardware and network are fast" is a simple canary that we are swimming through some problems.by HappMacDonald
4/1/2025 at 4:30:22 PM
How would you spec such a "lower powered" Android device?by mpweiher