Show HN: Nue – Apps lighter than a React button
(nuejs.org)730 points by tipiirai 3 days ago
730 points by tipiirai 3 days ago
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.
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.
> 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.
> 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.)
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.
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.
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?
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.
Isn’t using compressed numbers pretending that network bandwidth is the only cost of bloat?
All that JS, once decompressed, needs to be parsed and actually evaluated. That is where it hurts even people on gigabit connections.
I think frontend bloat has arrived at such an absurd level that it kind of makes me wish broadband and mobile speeds, and JS engine speeds, had paused their advancement for 15 years so that FE developers would have had to learn to write good code. Presently there is a whole generation of developers who built their whole careers in this era where you can get acceptably mediocre performance even with wildly inefficient code and an absurd amount of dependencies, most of them barely used on a given page. They’ve never been challenged to do any better, so i don’t really blame them.
> The bloat isn't coming from "huge frameworks" like React.
I agree. This is such a familiar cycle. People still blame Java for things that were really the fault of the average "enterprise Java developer".
The reality is that these frameworks don't automatically lead to bloated code shipping everything.
> You can create that kind of garbage with any framework, or without framework
I would think it would be quite a challenge to accomplish the given task without a framework?
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?
> 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.
> 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.
> a) developers don't taking any time to optimize, lazy load, cache, minimize dependencies... > ... > b) the 300 tracking scripts every site has to try to squeeze as much revenue as possible
Having seen the dynamics up close, I'd say it's far closer to the truth to say that the reason developers don't have time for a) is because they are having to spend all their time on things like b). I've not met a developer who doesn't want to build a better experience. I have met many developers who can't do so, for reasons outside their control.
Characterising it as "if the developer cares" puts the blame in entirely the wrong place.
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.
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.
I would go farther and say it's not even a lack of "optimization", it's a bloat of spaghetti logic that no sane person would ever write, driven by teams that don't talk to each other and are constantly pushed by stakeholders to add more layers instead of cleaning anything up
It has nothing to do with the frameworks. Except maybe that they empowered developers, including the ones cranking out bad code
> developers don't taking any time to optimize, lazy load, cache, minimize dependencies...
I built much more performant apps without lazy loading or caching when using html and a sprinkle of JS.
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
> the 300 tracking scripts every site has to try to squeeze as much revenue as possible
Just the other day I was appalled by a new record, 1604.
I'm increasingly of the opinion this stuff needs to just be banned outright by law. None of the businesses I've talked to seem to be aware of how dishonest it looks to say "we value your privacy" while trying to get users to agree to get more companies than there were pupils in my secondary school to analyse them.
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.
>the 300 tracking scripts every site has to try to squeeze as much revenue as possible
Let's say tracking for revenue is required and not an argument to be made. The question I never quite understand is why cant we have ONE scripts to rule them all? I remember there was a company / services that may be called Segment? And quick google search doesn't have anything familiar, that offers something like that.
> 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.
Yeah, I think both these are true:
1. React is bigger and slower than it needs to be. There are likely better choices today. 2. Most websites will be bigger and slower than they need to be due to the endless September of new devs, and the rarity of being given space to focus on size/performance. As React is popular, it means even if React was tiny and fast, these websites would still be slow.
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.
I get what you're trying to say, but aren't you blowing it a little out of proportion? At my job we have an SPA that loads a dashboard with 20+ widgets, all doing their own requests, transferring 2+ MB (compressed) of JS. It loads in two seconds, with all caches disabled. And I mean full load, not "ready for interaction". It runs on Vue 3.
I agree that the web could be lighter, but "finding one that will do a first load under 10s is close to impossible" sounds like exaggeration - it might not be due to the framework or lack thereof.
Btw, the webapp I'm describing is NOT built by the best of the best.
Now test it again on a 5 year old mobile device on a 3g connection with some packet loss, not in the sterile environment that is your office with a last-gen i7 processor.
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.
This. So many people—both on the dev side and the annoyed HN commenter side—act as though all websites have the same requirements. They don't. The usage profile varies enormously, and if you treat every website as just a website without considering the context it's used in you're going to either waste a lot of time optimizing things that don't matter or you're going to make your app suck by not adjusting properly for your users.
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.
I know I'm weird because I grew up in the 90s, but 2 MB of JS to show a dashboard with widgets still doesn't quite compute in my brain.
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)
It's interesting. I believe many of the people here know how it goes. There's no possibility of shrinking this further. It will only expand; we just have too much going on. We do have a genuine use for SPA, though - our webapp IS as complex a web-app can get, we offer no mobile version (for that, get the app).
Transfer's only part of the story (and 2MB is a ton on anything but a great connection)—the rest is memory use, which will tend to be some multiple of the transfer size, plus whatever your code initializes, and processor cycles.
> I see a lot of people angry at "Nue" in various ways
Interesting. I see people making overlay-broad claims without evidence or justification.
> I deal as DevOps/SRE daily with these services, and finding one that will do a first load under 10s is close to impossible
Nobody is going to call in for your help unless something is wrong, so don't be surprised you haven't seen anything right. That just means people are keeping the good stuff secret (and/or they don't work for your company)
> I can't help but think these are people heavily relying on React and missing the overall issue.
That's too bad.
I think that everyone who works on a slow project knows it's ultimately Management's fault, and when a codebase gets so big that nobody feels like they can fix it anymore, that's Management's fault too.
Maybe you can think if Management called you in earlier you could've designed a better thing, but guess what: I think that would be Management's fault too.
> but I can at least root for them
Can you imagine if any of what you said was really True, everybody believed you, and everybody actually stopped using these "huge frameworks [that] have made the web a horrible slow mess", and that actually solved "the overall issue" so that all software is perfect and reliable? What exactly do you think a SRE does in this case? Do you think that's even a job?
I really suggest trying to look at things differently, because I think for your skills there's a huge opportunity sitting right in front of you if you can see it.
The real question is, do we actually need "frameworks"? Pure JS works pretty well, and no JS at all even better.
I recently worked on an SAP project where there was a whole Java layer in front of SAP, and then a huge Angular app on top of it all; but since the point of the application was to manage b2b sales of physical things and it mattered very much whether those things were in stock, almost every screen did a full request to the SAP layer. The need for a thick "rich" client was unclear, and PHP would probably have worked much better.
Hype aside, it seems big organizations are using frameworks as a mean to ensure uniform coding practices and make developers more easily replaceable; but surely there are better ways to achieve that.
Not every page or app needs framework. But building complex app without one would be very hard and time consuming, and your team would need to come up with ways to solve problems like architecture, code structure, routing, data management, state management, etc. So you would basically reinvent all the wheels on your own cost, and you will have a non standard solution, that would not be compatible with libraries out there (for example UI components) and neither with new devs. Before Angular and React came I was building apps with plain JS with jQuery (not a framework, just a lib) and I would never go back there.
I agree. In a recent small project, I ran an experiment: first, I built the app in React, then in Vue, and finally in vanilla JS. In the end, I stuck with the vanilla JS version because it was significantly smaller, easier to deploy, and much simpler to maintain long-term.
I worked at a startup where one of the original devs had “strong opinions” on JavaScript frameworks. “It’s all bloat!!! We don’t need that crap”. So consequently all the new engineers had to learn this dude’s codebase, which turned into to be… A framework! Only instead of a documented one that had plenty of support it was an unholy mess that required extra time to build all the stuff missing from the it’s-not-a-bloated-framework-but-pure-JavaScript-framework.
Guess what happened the day after the dude left the company? All the engineers immediately started to replace the unholy mess of “totally not a framework” framework with an actual one.
Guess what happened to development productivity and product quality? They went up dramatically.
As someone who's worked on web apps with and without frameworks, yes, we need frameworks, especially if it's a large one or if there's a team of more than a few people involved.
The good ones these days like Vue or especially Svelte are barely any different to how you'd do things the "vanilla" way except they provide some sane QoL features like components (anyone who says web components are the answer has very obviously never used web components) and sane data flow management to and from said components.
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, even for apps that aren't that complex. And at that point you're just doing React or Angular or Vue, but worse in every conceivable way. Yay for going at it vanilla, I guess?
> 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 real question is, do we actually need "frameworks"?
Yes. The advantage of having a common API across thousands of web apps shouldn't be a point of discussion.
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.
Anything that forces React off its boring throne of forced ubiquity is a good thing in my book, not only for its lack of optimization, but its unwillingness to move past its outdated APIs and state management patterns. The amount of limitations I've faced using it compared to other libraries / ecosystem is enough to drive anyone mad.
I will say these claims about 10-second load times are highly exaggerated though. I've built several large applications with Vue and React, and once compiled, load within 2-3 seconds, with any remaining time spent requesting data at the mercy of your servers, which is going to happen in any client-side application, including native apps; so this isn't browser technology's fault.
Once cached, loads instantly -- and anyone complaining about cold starts can take their criticism to native app makers for phones, or motherboard manufacturers for long boot times. It's hardly an issue because of caching, and I tend to think the complainers about the modern web are forgetting how much more complex our applications are these days. Raw speed for lack of features? Or a little bloat for more capabilities? Pick one, and accept the tradeoffs. Maybe one day browser tech won't force us to choose.
While there is a case to be made for slow internet connections (this is where Svelte and other compiled runtimes come in with SSR), for the average enterprise using a private SaaS, or home internet customers using public SaaS apps on the web, by-and-large the experience is going to be just fine, unless the team who built the app didn't optimize.
All that aside, it's refreshing to see more ground being broken in the area of speed — I'm all for it.
IMO, this framework is built for use cases normally handled by React-based static site generators. For instance, a simple marketing site for a company. In these use cases, React is obviously an overkill. You wouldn't want your users to download, parse, and execute 2.8 kB of the React runtime just for simple buttons, tabs, and routing.
However, I don't find this framework suitable for more complex state-driven applications. If you want to build X's front end with this framework, you're just shooting yourself in the foot. It won't take an hour before you hit the framework's design limitations.
Just choose the right tool for the right job.
Author here: You’re right that Nue shines for simpler sites—like marketing pages, blog, and documentation. But calling it just a static site generator misses the mark. This latest release (check mpa.nuejs.org/app/?rust) handles a Rust-powered SPA with event sourcing over 150k records—far beyond ‘simple.’ For state-driven apps, Nue’s model-first approach keeps things clean and scalable—limitations are there, sure, but they’re not the foot-shooter you might think. Right tool, right job—totally agree—just saying Nue’s toolbox is bigger than it looks!
> 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.
> Web SaaS companies just wanting to use "common" frameworks
Companies obviously want to use what works well and been tested and tried in production. If Nue achieves that with significant benefits outweighting the migration costs it will become the new common.
The "problem" with React is that it improved developer experience and efficiency by a ton compared to what was there before it, and not because of anything else.
I often hear it said that devs should use slow machines and connections for development. That's a great idea (and it can be simulated) in theory, but in practice very few people are going to buy old ThinkPads to test on. So a solution should probably be done in software, i.e. at the level of compilers and runtimes.
i.e. if JS engines weren't so fast, bloated frameworks would be impossible, even on dev hardware.
So I'm wondering if just like C++ compilers have optimization levels, perhaps there should be negative optimization levels, where all your code runs 10x slower by inserting dummy instructions (or perhaps a browser for testing that uses a naively implemented JS engine).
This would allow you to directly experience the pain you're causing without leaving the comfort of your fancy dev machine.
Then again by the sound of it, the release build of the app running on v8 already takes 10 sec to load, so we have already achieved the goal of gross lag without special tooling, so clearly people just don't care (or are working in systems where they feel powerless to fix it)?
> So a solution should probably be done in software
In Chrome you can simulate a slow connection on a slow device via the dev tools. Firefox has a similar feature.
It's not entirely what you're suggesting (which is sort of like Chaos Monkey but for web apps I guess?)
The context of what the application does matters. I'm extremely cautious when people hype up "download sizes", when such size is less than 1MB, because this is usually a sign of cosmetic obsession and/or disassociation from the real world value offered.
A 200-300kb "bloated" single page app which does the job of a 10MB "minimalistic" downloaded store app – is IMHO pretty incredible. It's doing the same work at nearly 1/50th the size, all else being similar (externally loaded images and stuff). Heck, even a 1MB page load size is still 1/10th smaller.
Sure, it can be argued that the browser does most of the heavylifting. The same can be said of Android or iOS too, definitely the OS offers _even more_ heavylifting than the browser.
Rarely is that a problem with react itself. Poorly written applications exist in every flavor of language, framework and library.
Some frameworks though make it easy to fall into a good default, and others don't.
Yep, the more complex an app can be, the more complex the app will be
As I wrote in my comment it's a cool project but the way it's presented as a takedown of React is so ironically wrong. People pick React when they need a rendering layer and want to write the rest themselves. People who need a monolith SSG that is optimized for this thing choose Vue/Astro/Next and the like and that is Nue's niche. If you write a rendering library that beats React at its use cases then be my guest please brag about it
Thanks for the take—glad you think the project’s cool. I get where you’re coming from: React’s a rendering layer for folks who want control, while Nue’s tackling a broader scope, closer to Vue/Astro/Next combo. The ‘takedown’ vibe isn’t the goal, though—more like highlighting how web standards can slash bloat across the board, even for something as ‘simple’ as a button. Nue’s not here to just beat React at rendering; it’s rethinking the whole stack to avoid needing so many layers in the first place. Fair point on use cases—definitely food for thought as we push forward
So far this "re-thinking" is just dumping loads of innerHtml's and trashing the entire DOM.
The only reason it's fast is because browsers have been optimized beyond any sane reason.
E.g. your table demo removes and re-adds all rows on every button press. This is not re-thinking. This is throwing all we've learned out of the window and starting from scratch.
Cool, good luck! Building on top of Web standards is definitely a great idea and your (non-Rust) demo is pretty good. If I wanted to build a static webapp and was in the mood to play with something new I might try it.
> I deal as DevOps/SRE daily with these services, and finding one that will do a first load under 10s is close to impossible
I am currently in Indonesia on extremely flimsy and slow wifi at 1-2 bars that maybe tops out at 50mbps on a good day if no one else is on it and the gods align to grace me with a decent speed. Day-to-day, it's around 25mbps.
Doing a hard refresh of Linear (not affiliated in any way other than using them for work, but I know they use React), a complex project view that includes many graphs and other things like that, the full load time for everything on screen is 5.6 seconds with ~15MB of content loaded (this includes images and interactive graphs). DOMContentLoaded finishes at 360ms and the full interactive load is finished at 600ms, with me being able to click on tickets and navigate to them at the roughly 1s mark or less. Back home Linear load instantly for me with full interactivity, and the cached version of it even here in Indonesia is similarly fast.
It's not the frameworks slowing things down, it's usually all the bullshit that the business forces on its users that the devs have 0 say over. The app I work on loads really, really fast on dev builds that don't have any of the idiotic tracking BS enabled (for example on staging builds, which aren't even fully optimized builds compared to regular prod builds), but because the marketing, data and sales teams want their google analytics and 7 other tracking softwares, the whole thing slows to an unbearable crawl as we load in dozens of MB of packages each bigger than the Vue library controlling the whole thing.
A 10-second load time on a 10G connection??? That’s a peak throughput of 1.25 gigabytes per second. Even if we’re being conservative and assuming you’re only getting a quarter of that speed, that’s still around 3 GB downloaded in 10 seconds.
There’s no legitimate way a dashboard or notes app should be anywhere near that size. That’s not “just a bit of JS bloat” — it’s multiple orders of magnitude beyond what would be reasonable. The claim is not just exaggerated — it’s wildly misleading for anyone unfamiliar.
> 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.
If you make a React page you will see that it is absolutely instant to do things. React isn't a huge framework. It's a very fast library. Even if you add in all the extras such as routing, it's all instant. It's almost jarring how instant it is.
A dashboard taking ages to load isn't going to be React.
"Instant" can mean different things to different people.
I have an HTMX/Flask/Bootstrap app that feels instant for most requests on the LAN, except when it doesn't.
Often React apps are pretty snappy, but if you want to do complex data validation on controlled forms, where the state updates for every keystroke, it can drag you down. There are good frameworks for doing uncontrolled forms in a disciplined way
but it's another thing to add to your bundle. React is also not fast enough to do animations so you have a lot of .show/.hide (or display: none) CSS has facilities to do transitions and animations that are pretty good but I always find it a little nervewracking for a JS application to have state in React state variables and any other kind of state. Some ImGUI frameworks have components that look superficially like React components but are fast enough to animate every frame, which makes me feel like I am in control and get the animation to look exactly what I want.
> I always find it a little nervewracking for a JS application to have state in React state variables and any other kind of state. Some ImGUI frameworks have components that look superficially like React components but are fast enough to animate every frame, which makes me feel like I am in control and get the animation to look exactly what I want
I know what you mean there. I had the same feeling back when I was doing frontend things.
I dislike the disingenuous discussion around it.
Last time this was posted, the author called out headlessui for being too complex, and presented a half-broken, non-accessible Select component as alternative.
Digging around the code, I found questionable decisions such as throwing away the entire dom when re-rendering a list.
I want framework authors to be clear about the tradeoffs they make. The Svelte and HTMX devs openly discuss the weaknesses of their solutions vs industry standards and are open about previous mistakes.
I'm a lot more open to "coding in untyped strings" these days, but if you ship yet another syntax on top of html without proper tools (lsp or whatever way for it to play nicely with typescript), then I find it rather lame. I'd rather just write truly vanila js and html, instead of using another "framework", for no apparent benefit.
Nue indeed looks interesting. I could not immediately understand whether it uses a one-way data binding. Without it, and without a reactive model of some sort, building large UIs becomes a pain.
The React-based button from some framework is either over-engineered, or does way more than just a button. Using or not using such a component is a choice.
React may be a bit large (like 30-50 kB for a "hello world"), but preact is below 6 kB and gives you 90% of the React power for lighter-weight apps.
Also, the point of React is building huge and hugely complex dynamic UIs. There are much lighter-weight tools to add small bits of interactivity to mostly static pages, which are still the majority of the Web. (Ironically, HTMX is 14 kB, 2.5 timex larger than preact.)
We also created fixi, which is sort of preact to htmx’s react:
https://github.com/bigskysoftware/fixi
a goal of fixi is to be smaller uncompressed than preact is compressed, to force us to be minimalist
Qwik has the right idea for speeding time to interactive for complex web applications. This seems to be doing the same old thing as every other framework.
Generally, the thing that slows down "bloated" pages (a somewhat broad term) is either chained API calls, or GTM
Swapping out your render layer won't change that
Well said. The average person these days is mostly buying faster computers and phones so they can run more and more bloated web pages that just get in the way of getting to the text, images or video they want.
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.