Show HN: Nue – Apps lighter than a React button

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

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.

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.

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.

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

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

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.

[flagged]

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!

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.

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.

Downloading 60kb of compressed javascript takes way longer than executing it.

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

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

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.

It's both. The majority of web developers today suck, plain and simple. They thought they could make a lot of money doing web dev and don't approach engineering as an art form or a science. They just scrape by and do not level up on their own outside of or during work.

I've had to come in and rewrite apps before where the developers had full leeway and still produced an unmaintainable behemoth of third-party components loosely taped together.

Also, React is a nightmare. An absolute minefield with zero cohesive vision, with an ever-changing API and a culture of shaming developers who haven't switched to the new React paradigm-of-the-year. For a framework meant for serious adults, I'd check out mithril. It's small, API-stable and intuitive, and gets right out of your way.

I've seen this happen many times:

Dev: Hey, I added that screen you asked for- take a look and tell me what you think- any layout changes, wording, etc.

PM: Looks great! Okay, the next thing is...

Dev: Hold on! I need to go back and clean up some of the code I put in there to test a few ideas, and there's a loop in there that has some side effects if some if the timing is off.

PM: This looks fine. Let's move on to the next thing..

That's a good point. I didn't mean to demean React developers: I've been one for years and I can't say I optimized everything I could've.

The blame for not caring enough about performance and UX is on the whole industry. That does include developers, but not just them.

How can you close the ticket without "taking any time to optimize, lazy load, cache, minimize dependencies..." if that is in the AC/DoD?

Why don't those developers that care put important things the AC/DoD?

I’ve worked with plenty of developers who will argue that it’s fine on their development environment and their machine on the same network with test data and that it must be $OTHER_TEAM who is causing it. Arguably more of them than ones who really care. The problem is it only takes 2-3 of those people to bring the whole thing crashing down.

Exactly. If it's a common enough occurrence that most React SPA's are slow and bloated, it may not be the framework's fault, but if changing to a simpler framework makes it better, then it's just a semantic argument

We built a document management system as React SPA which is very performant.

Key: when user clicks on something, this causes 0 to 1 HTTP requests.

We didn’t do lazy loading or caching either.

EU has laws that give back control to users.

But for this to be effective, the browser should be cooperating and working on the user’s behalf to limit tracking. (You know, the whole reason why WWW calls it “user agent” — it should be on the user’s side.)

Unfortunately >90% of browsers use an engine made by the greatest beneficiary of user tracking. Hundreds of billions in future profits might be endangered by giving users actual control. The proverbial fox guarding the hen house.

Where do these 1600 trackers even come from? Does every text writer add their own in the CMS? Is it not managed centrally? Or does every web component load their own flavour?

I didn’t even know there were 1600 different distinct trackers around.

The reason we still have 300 scripts is that ad-tech companies want direct control over their tracking rather than relying on an intermediary.

So they make it harder or more limited to integrate with tools like Segment.

> why cant we have ONE scripts to rule them all

Because those tracking scripts are provided by competing advertising platforms and they want to own the data.

Why would React be bigger and slower than it needs to be? It's a very mature project with a professional development team behind it, I'm sure we can trust them to tackle whatever unnecessary bloat they may have. I think we should be able to trust that anything that is in there serves a purpose, and that it serves hundreds of niche edge-cases that someone will eventually run into but are non-obvious until it's widely used.

These kinds of statements are only true if you're willing to sacrifice in other areas such as maintainability, security, stability, compatibility, accessibility, extensibility or something similar.

Well, the post I replied to said "on a 10G connection peered within 5ms of the host" so I think it's fair to assume they also were in a sterile environment. I'm even on a lower connection with 20ms+ ping!

The thing is, enterprise web applications are not built for phones. This would be like telling someone to run the latest Ubisoft game on a PC from 2-3 generations ago, and expecting it to perform well.

Today's applications are more complex than ever, bloated perhaps, but the demand for features, complex visualizations, etc. rise with the patterns of seeing them more in other applications.

5 year old mobile isn't as slow as you make it out to be. Cheap 2025 phones is significantly slower than my 8 years old iPad. Also 3G could be fast and it isn't the protocol that makes the speed to <1Mbps.

It's not just 2 MB of JS. I'm describing ALL traffic, also the JSONs received, CSS, images, everything.

Besides, we show many charts, and believe me when I say: financial people are PICKY when it comes to chart functionality. It needs to have EVERYTHING or you're not considered serious.

Heh, I just literally built a toy dashboard in dioxus that loads just about 2MB of code, and then 700KB of css (tailwind, not optimized) and 1.5MB of payload data to visualize. Then again the 2MB includes ~1.7MB of just static data that I included in the wasm build for convenience since it will always be needed. :D

(this was a learning project in my free time, no I'm not defending this in any way, although I'm actually quite happy with the solution of including static data in my binary)

> but worse in every conceivable way

I always had an issue with that sentence (and I heard it a lot). Why would experienced software developers always come with a solution worse in "every conceivable way" when implementing logic answering a problem they're having, which would have the huge advantage of being tailored for their own needs?

I'm more of a library developer than an application one but I've seen that many JS webdevs have an aversion toward trying things themselves - instead always going for the most huge/"starred" dependency when they can. I'm not sure the impact of this philosophy is always better for a project's health than the total opposite where you would just re-invent your own wheel.

I do have seen multiple attempts at doing a specific homemade architecture that worked out well for some applications with very specific needs even 10 years later (For example I'm thinking about a 500k+ LOC JS webapp - not intended to be accessed on a desktop browser, but that's not the only successful long-lived JS project I know with their own archi). And I guess a lot of webapps do have their own specific needs where the "default framework" solution leads to some inefficiencies or hard-to-maintain / understand mess.

> I mean, more power to you if you want to handle complex states without the features a lib like Vue or Svelte provide you, but in my experience you eventually end up with a homecooked framework anyways

If state needs to be managed client-side (which is not always the case), then yes, a library is helpful. But a "framework" provides much more than state management, and those other things are usually dispensable, IMHO.

The advantage of having a common API across thousands of web apps shouldn't be a point of discussion.

We have one. It's called "the browser". The discussion is whether or not we need a higher level API than that. If we do, maybe that should also be a part of the browser's API.

Pure JS is that interface... you're arguing for multiple unnecessary abstraction layers piled on top of each other.

More abstraction != easier to use.

> Nue’s model-first approach keeps things clean and scalable

Like I understand why you say this, but as someone who spent the 2000s building "model first" web apps (and desktop applications), I don't miss it in the slightest. Immediate mode-esque render loops didn't catch on just because it's a fad, it really does fit a lot of highly interactive things better.

Of course the bigger problem is people using something that's great for heavily interactive web applications for building things that _don't need_ that interactivity...

Nue looks great, and I think it stands on it's own two feet. The constant React bashing just turns me off it more than anything (and that's not about React specifically, I have no real love for it, just that kind of project marketing isn't my cup of tea)

Thanks for your reply! The misconception might stem from the lack of clarity in the documentation regarding how islands (components) work.

- How do I declare local states (instance variables) in an island?

- How do I fetch and display data from an API?

- Where should we place data that is normally kept in contexts/stores in other frameworks?

These are common problems faced when developing an SPA, but missing in the documentation.

hmm, it looks like you've got a bug in the demo app. if you type too quickly into the search bar, the entire app slows to a halt.

seems like you'd want to move the filtering logic off the main thread, or you'd want to reinvent React's "Fiber" suspendable rendering architecture.

This is a silly take. There were certainly plenty of large projects written in JS before Typescript existed or became popular, some maintained by small teams or single individuals. There are plenty of large projects written in Python pre-typing, in PHP, etc.

I personally choose to work with typed languages most of the time, and I’m thoroughly convinced of their value, but acting like it is literally impossible to write a large project without types is just inaccurate.

For the record, author is not crazy.

Svelte team also switched to JS with JSDoc a few months back[0].

You can see the majority of their repo is JS and not TS[1]

The cited reason[2]:

    > As a Svelte compiler developer, debugging without a build step greatly simplifies compiler development. Previously, debugging was complicated by the fact that we had to debug using the build step. In addition, using JSDoc does not affect compiler’s development safety because the type is almost equivalent to TS.

As long as author ships type def, it should behave just like a TypeScript library for all intents and purposes.

[0] https://news.ycombinator.com/item?id=35932617

[1] https://github.com/sveltejs/svelte

[2] https://github.com/sveltejs/svelte/pull/8569

[3] https://news.ycombinator.com/item?id=35892250

Author coming out here: Types matter, and Nue’s take is to use them where they truly shine. Adding them to naturally untyped spots like HTML or CSS? That’s just extra weight we can skip.

I agree. It's far too easy to make a change to your model that removes/renames some property, but not update one template that you forgot uses it too. Without screendiff testing, that sort of bug will easily make it into prod.

This is one of the reasons I like C#'s .cshtml (Razor) syntax. The entire file is compiled to C#, so when you do `<div>@Model.Foo</div>` the build will fail if Foo doesn't exist. String-based (rather than compiled) view templating is, IMO, a mistake.

Making zero sense of your own take of the argument makes absolutely zero sense

Vue 3 has 6 years at this point.

Also, could you expand on the fact that types are "still not as good" as React?

Can you make an example?

You could always massively reduce the frontend by not duplicating half the backend business logic in the browser. By not having isolated backend/frontend teams off in their own worlds and only using fancy JS where fancy JS is actually needed.

Server rendering of JS only gets you partially in a better state when the fundamental idea is based around generating a massive amount of JS for the browser.

If you want an alternative view, I like the confrontational tone. You know what you excel at and attack your competitors with it.

I really dislike how all the other JS UI libraries are basically the same and espouse the same ideas.

Svelte was way better when Rich Harris was straight up attacking react devs at conferences and shaming them for poor performance.

Being "nice" just ensures entrenched players stay entrenched.

If you're actually doing something better and your results actually stack up under scrutiny I don't see the problem.

I think most people get uncomfortable because it's often untrue in marketing. So if it's true (to the best of your knowledge and after outside probing) then by all means.

Yes Conway's Law:

https://en.wikipedia.org/wiki/Conway%27s_law

The law is based on the reasoning that in order for a product to function, the authors and designers of its component parts must communicate with each other in order to ensure compatibility between the components. Therefore, the technical structure of a system will reflect the social boundaries of the organizations that produced it, across which communication is more difficult. In colloquial terms, it means complex products end up "shaped like" the organizational structure they are designed in or designed for. The law is applied primarily in the field of software architecture, though Conway directed it more broadly and its assumptions and conclusions apply to most technical fields.

That "backend" vs. "frontend" split is entirely artificial. That code you would run server-side to convert your data into a fully-rendered page is still very much part of your "frontend" organizationally, even though it might be hosted on the server.

(Strictly speaking you can have a web service that's purely about spitting out raw data in a form that other organizations can use, but that's the kind of thing that Semantic Web and Linked Data standards are intended to address. Not something that your garden-variety website has to be concerned with.)

OTOH you now need an API and glue code in the frontend. I'm not saying it's not worth it but it's definitely more work.

That's a debate spanning multiple decades. Your last sentence is not true all the time.

I think the exact opposite is true, B2B SaaS apps don't need to be an SPA to deal with fancy variants of a table. You can create highly interactive UI with things like Rails and Hotwire, sprinkles of JS or even HTMX. SPA's are bloat and often driven by designers who focus on flashiness rather than good UX.

Yes, sorry for venting on your thread. I do appreciate the idea of leveraging web standards though.

React and the react ecosystem fail at many of the criteria you’ve listed. You might argue “that’s not reacts fault” but when I look at a website that takes 15+ seconds to load its content on a gigabit connection , I’m never surprised when it’s react. Lots of sites have massive issues with rendering performance, scalability and maintainability even with react.

What react does do is give you a clean separation of concerns across team boundaries and allow for reusable components . But the cost you pay for that is a boat load of overhead, complexity, maintainability concerns, and react specific edge cases

Slower builds might make developers more thoughtful of the bloat, but I still think it’s tangential.

That said, how does Nue compare to, say, Svelte?

I'm not sure if I got this correctly, but it seems like you're misunderstanding what Vite actually is or does.

For having built what is essentially a bundler, I would've guessed you were more familiar with what it does, or, perhaps even have used it to build your tool.

Vite can bundle framework-less html files. It can create an SPA without any JS faff. You just have to point it to the right direction. When you instantiate a Vite app, you have to make the conscious decision to use React under the hood.

As for Nue, I think it's a cool idea, but I don't see what it does that I couldn't do with Astro, which has way larger community support and can work with pretty much all JS frameworks OOB.

BTW, I think it's really disingenuous to compare a React SPA bundle with an SSG output. You have essentially no functionality for handling state mutations beside events. You could achieve a much better middle ground by using a compiled framework like Svelte or Solid.

As the previous commenter said - you don't need a new runtime instance per button, so the comparison doesn't really work (for the smallest binary size, you could provide a native application doing the bare minimum to display the UI too, if the platform has an OS-provided UI framework).

It's still a neat toolkit, since not every website needs a big framework - but comparing runtime sizes is like choosing C over C++ because a `int main() { printf("Hello World\n"); }` binary is smaller.

This comparison is disingenuous and off-putting. When I read "a React button" I assume you are talking about `<button>` and the React runtime, not some third party libraries.

FYI, you probably meant to say “a moot point.”

https://www.grammarly.com/blog/vocabulary/moot-point/

Seems like it should be Meta with billon dollars that should be doing that. The whole point is framework like React are made for DX and dev flow at company of that size.

It’s not the button that’s big but the stack [0]

> Built with Vite, TypeScript, Tailwind, and Shadcn/UI, following the official ShadCN/Vite documentation exactly — no additions or removals.

Would be interesting to run Webpack Bundle Analyser [1] (or similar for vite bundler) to see if the proposed stack in the doc is bloated by some major dependencies.

0 https://nuejs.org/docs/react-button-vs-nue.html

1 https://www.npmjs.com/package/webpack-bundle-analyzer

Edit : seems the question I was responding for was a rhetoric question posted by the author. I guess the « smaller that a button » is a smart catchphrase but I wouldn’t use it for too long as soon a Nue becomes popular. Great work, I wish you much success and hope to use it in day to day work some time soon !

Does your button component implement all the functionality included in the Vite/shadcn bundle? E.g. the different variants, states, loading etc.?

I'm sorry if it does, then I'll take my accusation back, but I've seen this happen in almost all of your Nue submissions. People keep bringing up this criticism, and you never retract your misleading comparisons.

Here's the source, I believe: https://github.com/nuejs/nue/blob/master/packages/examples/s...