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.
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
Does the ShadCN button work without paying that cost?
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.
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.
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?