7 ms·

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

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.

oefrha 2y ago
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.
- sgc 2y ago
  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.
- troyvit 2y ago
  > 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 Is 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.
  - yuskii 2y ago
    > 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
    - troyvit 2y ago
      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.
senordevnyc 2y ago
This sounds like ChatGPT’s voice :)
- balamatom 2y ago
  ChatGPT learned that voice from actual people, you know.
  - senordevnyc 2y ago
    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 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.
    - balamatom 2y ago
      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.
nicce 2y ago
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.
- hombre_fatal 2y ago
  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 https://nuejs.org/docs/interactivity.html
  - mvdtnz 2y ago
    > 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?
    - jmaw 2y ago
      Are you really going to build a site which just consists of a button?
      - mvdtnz 2y ago
        If I'm working with a payload budget and I'm using React I guess so?
PaulHoule 2y ago
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.
- kylecordes 2y ago
  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.
  - fijiaarone 2y ago
    You’ll add at least 100kb of text for class names styling each HTML element using tailwind.
    - troupo 2y ago
      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-2024/ https://infrequently.org/2024/01/performance-inequality-gap-...
a022311 2y ago
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.
jeffhuys 2y ago
[flagged]
- zerocrates 2y ago
  Some people just really like em dashes.
schwartzworld 2y ago
> a single React/ShadCN button So 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.
- 9question1 2y ago
  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?
  - deleted 2y ago
    [deleted]
- mvdtnz 2y ago
  > 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.
  - deleted 2y ago
    [deleted]
  - bobthepanda 2y ago
    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.
eastbound 2y ago
> 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.)
- code_biologist 2y ago
  I'm old enough to remember when this simplified model was why people thought React was better than alternatives.
  - lastdong 2y ago
    I know, right? And where is Preact, Inferno and others sped-up React-like now?
    - teg4n_ 2y ago
      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.
- fijiaarone 2y ago
  Yeah, react developers don’t even realize that there is execution time as well as download time for an app.
- lucsky 2y ago
  > It’s not size That's what TFA is complaining about: size. But nice pivot, hope your head isn't spinning too much.
ouraf 2y ago
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 it

oefrha 2y ago

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.

sgc 2y ago
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.
troyvit 2y ago
> 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 Is 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.
- yuskii 2y ago
  > 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
  - troyvit 2y ago
    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.

senordevnyc 2y ago

This sounds like ChatGPT’s voice :)

balamatom 2y ago
ChatGPT learned that voice from actual people, you know.
- senordevnyc 2y ago
  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 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.
  - balamatom 2y ago
    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.

nicce 2y ago

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.

hombre_fatal 2y ago
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 https://nuejs.org/docs/interactivity.html
- mvdtnz 2y ago
  > 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?
  - jmaw 2y ago
    Are you really going to build a site which just consists of a button?
    - mvdtnz 2y ago
      If I'm working with a payload budget and I'm using React I guess so?

PaulHoule 2y ago

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.

kylecordes 2y ago
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.
- fijiaarone 2y ago
  You’ll add at least 100kb of text for class names styling each HTML element using tailwind.
  - troupo 2y ago
    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-2024/ https://infrequently.org/2024/01/performance-inequality-gap-...

a022311 2y ago

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.

jeffhuys 2y ago

[flagged]

zerocrates 2y ago
Some people just really like em dashes.

schwartzworld 2y ago

> a single React/ShadCN button So 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.

9question1 2y ago
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?
- deleted 2y ago
  [deleted]
mvdtnz 2y ago
> 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.
- deleted 2y ago
  [deleted]
- bobthepanda 2y ago
  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.

eastbound 2y ago

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

code_biologist 2y ago
I'm old enough to remember when this simplified model was why people thought React was better than alternatives.
- lastdong 2y ago
  I know, right? And where is Preact, Inferno and others sped-up React-like now?
  - teg4n_ 2y ago
    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.
fijiaarone 2y ago
Yeah, react developers don’t even realize that there is execution time as well as download time for an app.
lucsky 2y ago
> It’s not size That's what TFA is complaining about: size. But nice pivot, hope your head isn't spinning too much.

ouraf 2y ago

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 it