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.
I've created plenty of medium-sized projects with React/Vue clocking in at 200-300KB compressed (excluding image assets). You can still realistically use those on 2G — yes I've tried, not just in dev tools, but when I was actually rate limited to 2G.
> 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.
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?
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.
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.
> 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.
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
> 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.
>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.
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.
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.
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?
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.
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!
> 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)?
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.
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
> 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.
fwiw, I did not have the same take away as you from that part of the comment. I think the intent, and the way I read it, was, "Even when eliminating bandwidth and latency as a factor it still takes 10 seconds to load."
Indeed. This button comparison is quite telling, ragardless of the exact details. Definitely going to look what Nue is made of. It's refreshing to take a closer look at modern web standards — Nue or not.
> 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.
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.)
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.
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.
It's an untyped view layer kind of along the lines of early angular 2.0.
The model files are plain javascript.
So no typings anywhere. Which is fine, I guess this is targeting the vuejs crowd. Maybe their marketing should pivot a little bit in that direction, most react people now use TypeScript because first class types in your view layer are super useful
Author here: It’s true—Nue’s view layer is untyped. That’s by design. React’s ecosystem has devs slapping TypeScript on everything—even CSS—which is overkill. Nue flips it: presentation stays clean and semantic, web standards do the heavy lifting, and real static typing (like Rust or Go) shines in business logic where it counts. Thoughts on this?
This seems incredibly shortsighted. If you're building an application by yourself you're gonna remember the relations and dependencies - but even on a small team (say ~4 devs) or even if you don't pick it up after a while, there is going to be stuff you forget.
It's also nice when you move stuff around, you can rely on the LSP to rename and fix everything that breaks. If you have a simple website it's fine, but when you start to have multiple components... Losing typing is a huge deal.
Personally, I consider it a strike against a frontend framework if I can't type check my templates. They're entirely data-driven — exactly the kind of place where type checking is the least effort but still a a big help.
In any nontrivial project, templates become a large fraction of my LOC, and it's already challenging to confirm they work right and don't break. Type checking that I'm passing in the data they expect, and that they're reading valid properties, is a cheap way to get a big win.
Web standards are great, but I'm not sure what "heavy lifting" they do that would make me feel like type checking was unnecessary.
I am not on the React bandwagon, currently using HTMX
But I would very much prefer to see TypeScript in a framework. Optional TS is ok but "untyped by design" feels like an anti-pattern, even HTMX has TS types available.
> React’s ecosystem has devs slapping TypeScript on everything—even CSS—which is overkill
"We don't use Typescript because there are people that exist who use it for CSS when using React" is one hell of an argument that makes absolutely zero sense.
I probably have nearly the exact opposite opinion of where static typing is the most beneficial. I think it’s precisely at the UI rendering layer, because that tends to be where you’re dealing with the data types with the largest number of properties, deep nesting, etc.
I pretty much enjoy using MaterialUI with React (MUI) and have statically typed CSS: `<Stack sx={{ alignItems: "center"}}></Stack>` - I get full IntelliSense/autocompletion for the sx props (i.e. alignItems when typing 'al') and their value (i.e. 'center' when typing 'c') etc. Sx-props are composable, so you can centralize common used sx/css etc.
Any typos or invalid props/value will result in a compiler error.
I agree with most other commenters: Type safety is a great feature to have. And to intentionally dismiss it or only grant it to certain aspects of the application (where does business logic start and end anyway?) is a really bad sign for me.
how can "not typed" be "by design" and presented to us as a feature. Your project looked interesting but your presentation here makes me have big doubts
I worked with react before typescript, react with flow, angular 1 (large projects), and these days I mostly use react with typescript.
I don’t use it for css, but for the view components and code I find typescript actually makes me both faster and my code is more reliable. To me this is one of the killer features of react that other libraries are in various stages of catching up to: full static type checking end to end. (Also through the API to the backend with a little more work).
Typed JSX is one of the handful of key innovations that made React successful, IMO. I think you need to really understand what you're replacing before you can replace it.
Nothing in your view is "web standards". And nothing in web standards can do the heavy lifting of showing things like "`nam` is not defined on object `user`"
Frankly that's a good reason to never give Nue serious consideration. It's all fine when you're building small apps one view at a time. When you have an application with hundreds of views and you need to refactor, that's when you need the types, otherwise you'll never see the tail end of oh we missed that this needed to be renamed there too.
I honestly can't see what's wrong with using TypeScript anywhere in place of JavaScript. Unless you're making a simple script or a throwaway prototype, then you're pretty much always better off with it. It's invaluable during development and it's compiled away at build time.
Jesus, this is a regression not a feature, for christ sake.
Typed CSS via emotion/styled-components is an amazing feature to call it overkill. This alone is enough to dismiss nue.
Last time, I promise: please, PLEASE don't use ChatGPT (or others) on us. It's _extremely_ obvious, and it takes away 90% of your credibility. I'd much rather read a bit of broken English than read this kind of slop. It's a huge reason why I can't take this seriously.
ALL your docs are chatgpt. All of them. All your issues. Your comments here. Are you even real? Yes? Then TALK to us.
There’s a lot of negativity around this so I just thought I’d chip in and mention my appreciation for it. Projects are allowed to not be typescript, and I actively stay away from it as much as possible when working with browsers.
I don’t work in TypeScript, I don’t write in typescript, and I (along with everyone) don’t deploy typescript. I have multiple different build processes in my project to remove different types from different dependencies that are incompatible with one another just to untype them.
So personally I find standard js a huge selling point :)
I mean a rapidly changing front end codebase is always going to be entangled mess no matter if it’s react, plain JavaScript or even “native app code”. Front ends are where the rubber meets the road and have to deal with fuzzy weird human shit and miles of edge cases. That is just the nature of the beast.
Even if you attempt to tame it and make “the prefect codebase” it’s still gonna be a mess.
If anything React and typescript help it from being an even larger mess full of homegrown idioms that are normally baked into the framework.
There is no such thing as not using a framework. You either pick an existing one or build your own. Very often the sensible choice is to pick an existing one.
Typescript support and usage with Vue is very large. Vue itself is written in TS and most large libs are also written in TS. According to /r/vuejs and my personal experience also most new apps.
This is great. But I went for Svelte. Invested in Svelte and SvelteKit. Wrote a decent sized app (not toy example, pretty feature right, tens of forms and screens if you will) and later I looked back at React.
And I discovered that:
- React is not that hard if you understand the hooks.
- React is lightweight too. For my use case at least.
- React is boring technology at this point which is good.
- The ecosystem is huge. You cannot have React Query like library and that's just one example.
So I'm sticking to React for next few years especially when the React compiler is already being used inside Facebook and Instagram and released as public beta.
Even React Native supports React compiler and I don't see this support going away rather getting better.
PS Edit: React compiler leaves not much for runes in Svelte or its compiled nature. I don't like Svelte much after runes because it feels like you're not writing Javascript rather a notation that looks like Javascript. Post React compiler, much of the hooks hell is not needed in complex scenarios.
Svelte is definitely much less verbose and requires less code. Performance is also way better but it might not matter for many use cases.
The drawback is that since Svelte is really a language[1] you now need a compiler and custom dev tools to make it all work. This requires some serious effort to maintain and evolve.
I love Svelte and have been using it almost daily for years... but the team really needs more resources to accomplish their vision and maintain it for the foreseeable future. It's amazing that huge companies like Apple are adopting Svelte (eg: Apple Music) and not investing in it.
I work with react for a decade now, and with Svelte for past 3 years. Svelte is obviously a newer generation of framework, and works for me a lot better than React. But I agree there are some rough edges, mostly around the ecosystem
I learned React back in the class component days. I recently picked it back up and found functional components and hooks to be absolutely baffling. Does anyone know why they went down this route?
Trust me, the function based components are way too simpler. Just a function that returns HTML. That's it. compose your UI as those functions. These functions can take arguments to customise their output (rendered HTML) as arguments (called props) or can call special functions from React (called hooks) such as asking the React to "remember" a value for you (state) or cache something for you (useMemo) so as to not compute it every time or trigger rendering if value of certain variables change (useEffect) or at the component start (useEffect with no dependencies mentioned) and that's all the React that you need to know for I would say your 95% of the needs.
React compiler (already used for Facebook and Instragram code base) further renders the use of certain hooks unncessary thus making React a lot more simpler.
Nue’s a web framework I’m building to slice through modern web dev bloat. When a Vite/ShadCN/Tailwind button is 40% heavier than a full-blown SPA, it’s time to do things differently. We’re retooling from the ground up—web standards first, no bloat. It’s for frontend architects, design engineers, and UX folks craving simpler, saner workflows. Still in progress, but the shift’s coming. Curious to hear your thoughts!
At this point I don't even understand why everything has to be a SPA. It's complicated and inefficient and should probably be only used with highly interactive applications like some kind of Photoshop or Ableton live for the web, which means very few apps should use this paradigm. Granted, I'm not much of a frontend dev... but what I know is that if "instant search and other operations over 150,000 records" is a problem then it's probably best to re-think the paradigm.
With SPA, all your backend has to do is spit out data and sometimes validate it, leaving your front-end completely in charge of presentation and user interaction. You can even have completely separate teams working on it. It feels a lot less complicated than the alternative.
SPAs are great for the hordes of B2B SaaS apps out there, which for the most part are just some fancy variants of a table. They're not a Photoshop, but they're still highly interactive.
If you look at the documentation at nuejs.org/docs, you'll see how Nue is really more about apps that focus on content rather than single-page apps (SPAs). However, this release is all about SPAs.
I recently thought about just using ASP.NET MVC with Razor pages for a quite simple app at work. But I'm already familiar with SPAs, so with that background I chose to "just use Vue as always (or Solid or Svelte, I like all three of them)" as SPAs have some advantages, e.g. separation of concerns, easier integration of libs like agGrid or eCharts.
Without that knowledge, I agree that good old SSR (MPA) is easier and more maintainable. And more robust.
Both way can work fine, enough great examples out there. The real problem is, imho, we shouldn't need a (graphical) UI at all. That's where all this discussion comes from. When the whole "frontend" disappears in a year or 10, it will make a lot more sense.
This happened to a team I know. They built a flashy SPA dashboard because it was easy to copy-paste from templates. It worked great—until a real-world requirement, like a data grid, came along.
IMO, most SPAs are bloated. MPAs are cleaner and more forgiving.
The only reason to still stick to an SPA instead of an MPA is that the app is so bloated you want the user to only have to load it once.
And people say "lazy loading!" but by the time you've implemented lazy loading in a SPA, you could have just used an MPA to keep things modular and memory efficient.
SPAs became popular at a time when companies thought everyone was going to move to progressive web apps. Then the bloated frameworks came along, PWA interest has faded, and here we are.
The above are all my opinions, apologize in advance if they come off as speaking objectively.
I don't think the "a button in X is 40% heavier than an SPA" is a fair comparison; including a framework will add weight, but these frameworks are not intended for single components. Compare apples to apples, then we can make a fair comparison.
That said, how does Nue compare to htmx and other frameworks leveraging the modern web standards?
There is no such things as a true apples to apples comparison for libraries such as this. They all cherry pick something and ignore a ton of things such as:
- accessibility
- amount of libraries with plug-and-play solutions to common problems
- security
- scalability
- rendering performance
- maintainability
- browser support
- browser extension interference
- hundreds of other niche edge-cases that someone will eventually run into but are non-obvious until it's widely used
React is really well-thought out and well made by hundreds of professional contributors that have worked on it for years. The premise that hobbyists can make a better overall solution in less than 8 months is strange. At best they can make a smaller solution, but it will have to sacrifice in other areas.
I resonate with what you're saying so I'm mostly just curious how long you've been developing front end code. I think those who have had had to run the gauntlet of naked JS in the 90s developed the discipline to intuitively code untyped.
I've been enjoying JS since it was first added to Netscape and I also loathe the creeping bloat that is endemic to web development these days.
In the event that I want an "intellisense" dropdown capability in a project, I'm a big fan of JSDoc. I think the bootcamp kiddies these days just don't have enough experience to get by without the intellisense crutch.
What do you mean by "lighter than a React button"? Do you mean lighter than the entire React runtime, plus a React button?
If so, that's somewhat disingenuous because even though a page with a single button would require the entire runtime, a second React button would be significantly cheaper than that.
flawed example for a framework. Tell me...are 2 buttons going to be 80% heavier? why use react if all you build is a button? you need a tractor to pick your groceries from store?
I wish instead of this marketing article there were technical details, for example: what method of change tracking is used (proxies Vue-style or recomputing everything React-style).
Also I didn't understand the phrase about JS "overflowing stack" with 150 000 objects. I created a list of 150 000 objects with the following code:
var list = [];
for (var i = 0; i < 150000; i++) { list.push({ id: i, name: `Name ${i}`, weight: i * 100 }); }
According to profiler, this array (with objects) uses 14 Mb, where 2 Mb is array and the rest are objects and strings. Running list.find() without any indexes also doesn't overflow the stack. With indexes it would probably be lightning fast and won't need any WASM and complications.
JS is not that slow. And if you do numeric computations (i.e. multiplication of numbers in large arrays) the code gets compiled and runs pretty fast.
The author uses something like `list.push(...objects)` in his demo code, and I believe this is the culprit. Passing many (~100,000) arguments to a method at once using the spread operator is known to cause a stack overflow, because, in JavaScript, each argument is placed on the call stack.
I see a number of issues, but don't have time to look into them.
1. Spreading when you probably don't need a copy: sortEntries. Sorting is probably where the overflow happens. Just sort in place or use Array.from or slice.
2. Excessive use of array functions. In my experience, a C style for loop performs better when you need performance. Create an empty array before, perform your business logic inside the block, and push to the array.
3. I don't know how filter is called, but it potentially loops through all of the events three times in the worst case.
4. paginate manually creates a JSON string from the returned entries. I don't know why, it seems inefficient.
So, nothing is worthy of discussion or can claim any benefits over the incumbents until it has become an incumbent itself? How is it supposed to attract the necessary users to get bloated if they can’t talk about it in relation to the established players?
JS frameworks have often valued DX first over what it outputs. Frontend devs also frequently care more about a) their own tooling and b) how it looks, to a much higher priority than the performance and stability of their output. At least from my own experience in the community :)
Solid.js is doing amazing w/re to its bundle size. Its been in development for something between 6-9 years depending on how you count and it is still very very slim.
- Why is the demo impressive https://mpa.nuejs.org/app/ I believe someone can do the same web-app in React with the same performance.
- I'd like to quickly see some code samples on the home page. I had to dig the documentation to find some code samples (https://nuejs.org/docs/view.html#clean-html-templating), is it inspired from Svelte ?
- How is new faster and lighter compared to other tech? Specifically, compared to raw HTML/js.
To convince me that Nue is a framework worse using, please show that Nue:
1. Is simpler than HTML+JS (or at least simpler than react): like https://alpinejs.dev/
2. Is easy to understand: maybe the markup and logic are close to HTML or something else I already know
3. Has a better DX with good build time and HMR: you nailed this one
4. The tech is better: low overhead? highly based on WASM? virtual DOM? Server islands?
5. Show me metrics: https://esbuild.github.io/ nailed this one
> Why is the demo impressive https://mpa.nuejs.org/app/ I believe someone can do the same web-app in React with the same performance
Weren't the main points on the main page that it was small ("lighter than a React button"), and could handle large amounts of records ("far past where JavaScript (and React) would crash with a stack overflow error")?
Those points are only true if you're comparing to a React app that uses bloated frameworks and inefficient list manipulation (as other commenters pointed out, `list.push(...items)` causes problems)
If the authors of this project mean to say that a button in react wouldn’t work without including the react library (which is why the button is supposed to be 73kb), it’s a weak point, because the react library would be reused by other parts of the app bundle at this point.
This is misleading to people and the promise is so shallow that it almost feels insulting.
I’m the author. To clarify: a button installed via ShadCN/Vite’s official docs (https://ui.shadcn.com/docs/installation/vite) ends up way heavier than a full Nue SPA. It’s not a jab at React devs—just showing how web standards can flip the script on bloat. Any thoughts on framing this comparison better?
Can you give some examples of some of these standards that make Nue stand out and other frameworks don't use? It seems that if other frameworks make use of these standards we would get a similar performance boost across the ecosystem.
Mention that you know you are missing dozens of features instead of blaming it on “web standards” would definitely help frame it better. Do you think Vite doesn’t know about web standards? It reads pretty naively.
Also I recommend just not making a web framework. There are many of them, some very similar to Nue. Your effort could be placed on improving what is out there. I suspect that is a lot harder and less fun than just making something new. But if you manage to contribute then you’ll be helping an entire community of people whereas a new web framework will likely see almost no adoption before it is abandoned.
It's like someone making a hello world in C using the std, then one hand crafting the console print but losing literally everything else. Of course, if my goal was to just write hello world then it would make sense but 99.9% of people in the world will use something else, invalidating the point.
I really like the approach but the demo [0] doesn’t really work on iOS Safari (although might be my outdated 16.7.8 version).
Scrolling doesn’t work, the layout and buttons have weird line breaks, the native search button is embedded in the custom designed one, leading to 2 icons…
The author is using a trick they've used in almost every past submission: They implement much less than the component they compare themselves to, and then show how much smaller their own solution is.
- `nue create simple-blog`
This highlights content-driven websites.
- `nue create simple-mpa`
This is today’s SPA demo, where 'MPA' stands for multi-page applications. It shows how client-side routing and view transitions can seamlessly connect content-heavy pages with app-like views.
IMO talking about the “heaviness” of popular web frameworks is way too simplistic to be actually meaningful.
How light or heavy an app feels, in my experience, has very little to do with initial bundle size, and far more to do with how adeptly the developers have solved the distributed systems problems of their app.
Are images compressed and cached on a CDN? Is linked content pre-fetched? Does the app avoid unnecessary roundtrips to the server?
These are the questions that truly matter, IMHO. They’re also things that junior devs are likely to get wrong.
All that said, I agree that you tend to see far more sluggish websites written in React than in any other framework. But personally, I think that’s a consequence of React being popular, and attracting a larger proportion of devs who miss important details.
And importantly, does the app have clear loading states when it has to block on something? Making sure something happens immediately can make things feel fast even if you're waiting on the network.
> Does the app avoid unnecessary roundtrips to the server?
Guess what, using server-rendered pages avoids all unnecessary roundtrips by definition, because the entire page is loaded in one go. You can augment a server-rendered site with client-side SPA features for seamless interaction within the page, but that's not a key requirement either.
Yes, React is huge, but I also see it used for everything and everyone when it's really not the right tech-stack in many situations.
Just need a simple interaction free site? Use Astro.
Need some interaction? Use Svelte. Larger project? SvelteKit.
Need a more established solution? Use Vue.
Working in a huge team and need a highly opinionated framework with strict conventions? Use Angular.
More than 99% of websites would be sufficient with Astro though. And when just some interactivity is needed it is always possible to add Svelte / Vue / Solid / Alpine / HTMX on top of Astro.
Weird that the current state of things for a simple, noninteractive site is some kind of framework and not just “write the HTML with a little JS where needed,” which works perfectly well and requires no additional baggage.
> frontend architect, design engineer, and UX engineers
Damn should I update my resume again? I’ve used webmaster, web developer, full stack developer in the past. Can I use "internet creationist" to leap directly to the next call phrase?
More seriously, I’m lost when using a search bar in a job listing. Now I just type "JavaScript" but that miss the posts only mentioning the higher stack and/or typescript.
Author here. No need to update the resume yet—titles do keep shifting! React’s monolithic style has muddied the waters, making it tough to build clean business logic, prioritize performance, craft CSS design systems, or just focus on user experience. Nue’s here to unblock that—giving each role room to shine with leaner tools, not cramming everyone into the same heavy stack.
I really like how Nue is shaping up! Having a clear MVC separation, leveraging modern web standards, semantic markup—all great things. Kudos!
Seeing the .dhtml extension certainly brings back memories... One thing I dislike is that the HTML is still parsed and converted into JS, which is then evaluated at runtime, correct? I realize that this is required to support templating and a nicer syntax for binding and such, but my ideal "framework" would support plain HTML files that are not converted to JS, but used very lightweight syntax (essentially custom data attributes, and `<template>` elements) to make the page dynamic. In fact, I'm experimenting with such a library right now[1]. This approach is likely more difficult to manage when building large web apps, but for simple UIs as used in browser extensions, it's fairly sufficient.
Frontend web development has been stuck in a pit of complexity for well over a decade now, and it's about time we go back to basics. There are new generations of frontend developers who only know this way of working, which is a shame. They're not really _web_ developers, but React, Vue, or whatever the popular framework is, developers. Web standards are far along now that there is very little additional glue and sugar needed to build modern web applications. React ushered in a new way of building UIs, but it also spawned dozens of copycats and frameworks that are downright developer-hostile beyond their shiny exterior. Not to mention the security nightmare of an incomprehensibly large dependency tree. Let's actively reject this madness.
> Using Rust and Event Sourcing for instant UX over 150,000 records — far past where JavaScript crashes with a stack overflow error.
Nit: while I fully support making the web more efficient and hope that Nue is successful in promoting that, I'm skeptical of the "crashing" JS claim here. You can do amazingly efficient things with TypedArrays, the forgotten middle child between JavaScript and WASM.
Having said that, this requires building a few clever data structures on top (I've gotten a lot of mileage out of "typed" dequeues, and (sparse) bitmaps myself), often emulating structs in a language unable to express them properly. So the resulting code is not exactly idiomatic JavaScript — which I presume is what they implied here. Plus in this case it probably still wouldn't be as fast as a well-written WASM implementation, since almost all of the work is likely spent searching with only a little bit of DOM manipulation at the end.
So I'm both agreeing and feeling like it slightly overgeneralizes. I guess my point is: yes, let's be critical of bloated web frameworks, but let's not equate React with JavaScript either.
Author here. You’re spot on. I took away the React association and added a direct link to the JS code [1] that hit the ‘Maximum call stack size exceeded’ wall. TypedArrays can do wild stuff, no doubt, but yeah, it’s not exactly vanilla JS—and still lags a tight WASM setup. Appreciating the nuance here!
The new wording is much more nuanced, appreciated! Also the fact that you link to the actual code that broke down, making it possible to verify the claim. Less ammunition for the people who actually are skeptical of the project instead of just nitpicky like me ;)
Speaking of the code in question, it looks pretty sensible - there's a bit of low-hanging fruit where one could avoid creating redundant arrays by turning chained calls to map and filter into one for-loop and such, but that's about it.
What confuses me is that there's no point in the code where I see any recursion, here or in the other JS files that seem relevant, so how does one end up with a call stack overflow?
(not questioning that it crashed for you, it's just that I don't see any obvious flaws in the implementation, so I'm curious to lean what the "gotcha" is in case I ever bump into something like it myself)
Its not big frameworks making the web big/slow. Its...
Yes, its absolutely the big fucking frameworks. In most cases it is the actual literal use of the frameworks, but even that isn't the real problem. The real problem is deeper. You can call it second order consequences.
Its developers that cannot optimize and cannot program without something like React. If you took React away would you suddenly not be able to do your job at all? That's horrible problem to have. The result is a bunch of toxic defensive posturing by people who suddenly appear not qualified to do the work.
If you cannot dig deeper you certainly cannot optimize deeper. That makes the assumption you are actually measuring things and optimizing things in the first place, which many developers aren't. Again, if a given developer lacks the capabilities to dive deeper they may also lack the capabilities to measure things, as is quite common.
Most IRL software failures like poor performance, lack of stability, unmanageable technical debt, etc are going to be systems and human failures 90%+ of the time, not the individual tool or framework choices.
It’s human failure 100%. Big frameworks just lower the baseline such that this failure becomes more acceptable, less immediately aware, and masks candidate selection.
If you want to achieve something smaller or faster you have to measure for it. Odds are if you cannot execute without a big framework telling you how to proceed you will not be able to measure it either way.
Fair point—new tools pop up constantly, often just piling more layers on React’s bloated stack. Nue’s not that. It’s a fresh start, built on web standards and closer to the metal, not another abstraction treadmill. That’s why a button can be lighter than a whole app—less cruft, not more boilerplate. Tomorrow’s Olde might still fight yesterday’s bloat; Nue’s dodging that trap from day one
Yes. On that version, Chrome 134.0.6998.89's devtools on my Macbook (M2 Max) are indicating 100 to 250 millisecond interaction times and a 160 ms frame when entering text into the search field.
Loading the page on Fast 4G connection takes 9,61 seconds before I see _any_ content on the screen. This is loading the "all contacts" page that shows 12 items with a title, excerpt, time stamp and user name. Is this expected performance? Network shows the app downloading huge 4/1 megabyte chunks.
If you just use an html button with simple styling the size is around 58kB (not the quoted 73kB, which is from other libs that they built with like ShadCN than just react), so its still impressively smaller than react.
That said, using Preact instead (a smaller and more modular react-style library) the file size is less than 5kB. Its almost a drop-in replacement for React too: https://preactjs.com/guide/v10/differences-to-react
If i make a similarly minimal app with Nue (the lib the article is about), export as production, and remove the favicon it seems to want to add automatically, the filesize is 28kB. I couldn't see a way to meaningfully reduce that in their docs, as its clearly exporting things that arent being used.
Its pretty disingenuous for them to compare an app to a single button, given their own single button implementation is massively overinflated too. It does appear to be a full app framework rather than just a view library though. So I'll definitely give it a whirl.
To the OP: From a lot of the comments here, including my own, comparing yourself in this way is only going to result in people calling you out on it. Its clear the lib has merit in its own right, but you aren't comparing like to like, and if the focus is on "button" apps, then you are still WAY behind some other libs in terms of export size.
Nue seems to be in an odd space. It's an untyped framework, built on top of "web standards".
But if you wanted web standards + web component, Lit already fills that space.
If you want untyped JS or little/no JS at all, there's HTMX.
Or if you're just tired of React, and want something faster + simpler, there's Svelte/Solid.
I'm not sure what problem Nue is uniquely solving.
I like the philosophy so much, I myself am working on a minimalist theory to explain human psychology and strongly against specialized therapy and bloated productivity systems. We have specialized rules for everything which I feel repeatative and we are not using the full potential of human mind.
Anyways, here are my initial observations on NueJS
1. In the age of AI we need to support it for broader adoption. One of the reasons people choose NextJs and Tailwind over other frameworks is that LLMs understand them well. We need some minified doc to pass onto LLM to make it understand the framework.
2. What do you think about the unstyled components like Radix UI? Accessibility issue are important for components like Model.
3. What do you think about server components? I like them personality as we don't need to pay for separate NodeJS server as a small team.
4. How much Rust is required to use it properly? It's not an easy language to learn as far I heard.
5. How do it compared to AlpineJS who also focuses on performance?
Absolutely brilliant I've been following Nue for a while and every release gets more and more impressive.
Thank you so much for putting in the hard work by making it and I hope others can understand why this is important and use it instead of cargo culting React and making the web worse every single year.
The FAQ (https://nuejs.org/docs/faq.html) describes pain points that seem pretty foreign to me, the exact thing I appreciate about React is that I can focus on the domain and the tech MOSTLY does fade into the background. It has been an improvement in that regard, to all the frontend MVC I've done before and the architectural pattern has been adopted for good reason by all the native platforms.
TBC in React and its offspring, you can still model business logic outside of components, we just learned that most UI development is better served by keeping UI and its state closer.
"mostly" for sure; it's a good mental model and allows me to build modular applications etc, but I hate that a nontrivial amount of code and headspace is spent on things like re-renders, memoization, useCallback, dependency arrays, etc. I hope the React compiler will finally solve this, because the competition (apparently?) has (I haven't had the time to look into e.g. vue yet).
Absolutely, it would be nice if we found the right abstraction to get rid of that part as well. Basically every non-React framework's answer to that is Signals (aka change tracking), where React is doubling down on unidirectional data flow and thus dependency arrays. React Compiler indeed solves the 99% of performance related memo-s.
For effects you still will have to understand the mental model (which I'd argue is inherent in the domain and not incidental to the tech).
From reading Nue's docs on Interactivity, it seems to opt-out of the discussion by going back to good old manual UI refreshs. I personally would not choose that, too many pre-React debugging nights spent on chasing state<->UI desynchronization bugs.
Very catchy landing page, like it. And I've read the documentation. Unfortunately not convincing me. I mean, writing larger web apps means nothing else then dealing with a lot of _state_, really a lot of asynchronous _state_. Clicks, notifications, mouse movement events, push messages, navigation changes and so on and on. Larger web apps are state monsters. That's why I choose a framework that is good a state management in the first place. React is one of those proven. Nue does not look trustworthy in regard to good state management tbh. For smaller apps that might not be a problem, but there I tend to use vanillajs anyway.
This framework is a good example of something I call, "there's plenty of room in the middle." (In analogy to Feynman's "plenty of room at the bottom" about nanotechnology.)
Much like how Cosmic Inflation in the early universe left the imprint of microwave background radiation written exponentially large across the sky, I believe the exponential expansion of computing during the era of Moore's law left whole sections of scale in software not-fully-explored.
Specifically, as "average app sizes" went from 1K - 10K - 100K - 1M - 10M - 100M+, you could imagine the 1K-10K got fully explored because the space wasn't that big to begin with, and the 1M - 10M range got, if not explored at least inhabited, but it could be that that middle range of "neat applications that weigh in ~100K+ but less than 1M" didn't get completely explored because we didn't spend enough time in that era of computing.
A similar thing may be playing out in AI scaling, where we went from tiny to medium to huge model sizes, but now some new participants are going back and doing neat things with medium sized models.
Honestly, after playing around with your example and tweaking a JavaScript example, I feel that my plain JS example is faster than the one with WASM/Rust on Nue (possibly due to the animations). Please disable animations; I think they make your WASM example feel slower than it probably is.
It sounds cool and all but the single button thing just irks me. The point of React is for making a system of components with potentially complex relationships between them/when they’re displayed, etc… Nobody is using React to put a single button on their website. It’d be nice if there was a more useful, practical “benchmark” that your entire marketing of the library is centered on.
1. It's an SSG and competes with projects like Astro or Solid or Next. Comparing to React is apples to oranges.
2. Benchmarks are just numbers without details. React+ReacDOM gzipped/minified is 40 kb in 2025. I doubt a button adds 30 kb. But if you really want to make small SPAs, Preact is just 4 kb and it doesn't require to learn a new bespoke templating DHTML-style thing.
3. From FAQ
> The WebAssembly example in our demo isn't about raw performance — it demonstrates something far more important: what becomes possible when your business logic is properly separated from presentation.
> But when your business logic lives in its own pure layer, entirely new possibilities emerge. Rust is just one example — you could model complex financial calculations, build sophisticated data visualization engines, or create real-time collaboration systems. Your logic can evolve independently of the interface, enabling the kind of architectural advances that the React monolith prevents.
The writer was high or delusional or bad at explaining the point. Nothing prevents you from putting logic into "its own pure layer" in any language. You can make it messy and impure with Rust/WASM/... just as you can keep it pure with pure JS. And it's not "entirely new" because people separated business logic for literally decades (and believe it or not many of them even did it while using React at the same time)
And meanwhile the Rust version is slower and bigger. "What becomes possible" is a mystery.
"React monolith" just takes the cake. React literally doesn't care how you separate your business logic, it's just a rendering layer. This ironically is a monolith SSG that does routing, YAML frontmatter, Markdown extensions, syntax highlighting and what not. Again, you are thinking about something like MarkoJS or QwikJS. Before you are trying to take something down you should probably understand the basics.
Don't get me wrong, it's a cool project. But it could be more humble because authors don't seem to fully understand themselves what exactly they are proposing.
The videos. The very first video. Animations like this are done to hide the fact it’s slow by hiding it behind a fancy animation. Used to do this when we were stuck on 3g connections…
If I felt strongly about going lightweight I would (do) use plain js. I trust myself to know when I'm following basic principles of performance and when the line has been crossed warranting the use of a framework
React is the most used frontend framework, but not a good reference as React is outdated, slow and big.
Take Solid, Svelte or Vue (with or without Vapor mode) as reference and the picture looks different. Additionally when using custom components instead of large UI libs based on HTML elements like <dialog> or the recently announced stylable <select> element you have a very powerful, small and simple stack.
Still, they catched my interest. A lot. I'll dive into the docs to learn more. Maybe I'll be convinced to change my go-to stack to Nue ... damn, I had so many happy weeks with Vue. Maybe till Vue Vapor is out.
So many people are obsessed with Web application size. But there are other important factors as well. First of all, the UI must be functional even it's slow and heavy. If it does the job then it's already a win. I don't actually care how long I'll wait while I'm downloading the JS bundles. I've been waiting 5-10 mins GTA to load back in 2008, waiting seconds is totally ok.
Based on work done by svelte and solid, I think it is possible to shave base react down to half its current size, but it appears nobody (inside or outside of Meta) is willing to take on this challenge.
Unfortunately, the tradeoffs are still in favor of react and will continue to be in favor of react for the foreseeable future.
Most importantly it is next to impossible to get developers to give up DX (and muscle memory) for smaller JS bundles.
I think there is an issue with the implementation of search and filtering.
When I open https://mpa.nuejs.org/ and type "kind of rate limit" in the search box, I get 383 search results, and the URL updates to include the query: /app/search/?query=kind+of+rate+limit.
However, when I paste that URL directly into a new tab, I only see one result instead of 383.
Seems to be no support for TypeScript in the frontend? I mean, it is mentioned, but only together with Rust and Go for "computation engines".
No TypeScript = No deal with me.
I wrote my first Javascript application back in the spring of 2025, and I am not aware of anyone who is willing to pay me enough money to voluntarily write Javascript again in a project of meaningful size.
So is there a book that I could read that would allow me to write applications with just HTML/CSS some js and rust? I don't want Nue so much as I want "The art of writing lightweight, feature complete, responsive applications on the modern web."
Google decides what goes in a browser these days. Since React came out of Facebook there is approximately (checks notes) -ZERO chance in hell- of that happening
The tagline says a lot more about React than it does Nue, but I'm always interested in less bloat when it comes to front-end. I'll try this out, one small thing I don't like is in the demo there is a weird pulsating effect that actually modifies the layout when clicking, throwing me off a little.
This doesn’t square with most of my experience with React, especially if use it to generate static code hosted by nginx. I’ve found my personal site to always be wicked fast, even though it’s not that complex.
Congrats, Nue seems to be an impressive and well-thought-out design system & framework. It feels like a strong candidate to become the "Web Standards Stack" —finally freeing developers from the complexity and bloat of modern frontend tooling.
I've been following Nue for a while now, and I'm eager to use it for real world apps. Any updates on when the design system will be released? I know you're ambitious, but I'd suggest launching a single design system first to test the waters, gather feedback, and gain traction — rather than waiting to release everything at once (but losing out to the ecosystem).
I'm eager to dive into the design systems, definitely coming. But first, I wanted this release to prove Nue isn’t just for ‘hobby projects,’ a label plain website generators often get stuck with. This SPA demo was key—showing how working closer to web standards really shines for complex apps, not just simple sites.
Regarding Rust, are we talking about a Rust backend with RPC/REST or is it simply WebAssembly compiled from Rust? If the latter, how is the data synced for CRUD?
this is why inertia.js is a positive path forward.
it relegates React, Vue etc to be view layers - purely view layers. all models / state etc handled by your monolith Rails, Laravel server. this simplifies a lot of things.
frameworks like Vue & Svelte have scoped styles which preserve knowledge of CSS. While Tailwind is convenient - a lot of people won't know the capability of CSS
and why it was named cascading & the customability of CSS for the user.
But what if it is not the frameworks that are bloated but the application developers that make bloated applications? Then how would this fix anything ...
Here's the react-table example app with 112,500 records, just like your example. I am not really seeing much of a performance difference (and this is in dev mode - it would be faster if built for production):
The main benefit React is giving my app is just the ability to update the DOM automatically and efficiently, without me worrying about doing anything but updating the state variables. I have a feeling some very well crafted prompt to the best AI in the world could just about generate something that can also do this in like 500 lines of JS, in a single file. Once we have that, we can get rid of React maybe?
I also hate JSX, and have my app setup so I create GUI elements programatically like "button = new Button("Save", db.save)". Templating has so many friction points I find it to not even be worth the complexity, expecially once you have templates containing other templates with looping and conditionals, etc, and you end up with just an extra layer of cognitive load. No thanks. We can do better. With the capabilities of modern JS (classes, imports, etc) we can phase out React and Vue.
> 150,000 records — far past where JavaScript (and React) would crash with a stack overflow error
I think react-virtualized and stack tables can easily handle 1 million rows client-side without a problem (I saw the demo somewhere).
Web development is about convenience, and the speed of development is far more important than ultra optimizations. People simply don't care about super optimizations because servers are so fast these days, and bandwidth is cheap, almost free.
> People simply don't care about super optimizations
Could be, but some optimizations in Nue really stand out. Check out bundle size, HMR speed, build speed, and especially repository size. An empty Next.js project weighs over 300MB, a Vite button is around 150MB, while a Nue SPA clocks in at just 2MB.
I would love to check out the bundle size! Will you ever create a fair comparison, where your Nue implementation has all the same features as the versions you compare it to? All the comparisons I've seen so far are deceitful since they implement much less. If Nue actually produces smaller bundles, why not create an actually fair comparison?
A Vite button? You mean Vue? Vite is just a bundler lol.
Also, would like to see some comparisons to Preact, as that's an (almost) drop-in replacement for React with SUPER small bundles. I'd be impressed if you manage to beat that.
Make a demo with react-virtualized[0] and see if it crashes. Hint: It will not[1]. React can easily render 1 million rows with high performance without relying on WASM [2]
Here is the demo of react-virtualized[3], in which I entered 10m as the row count and scrolled to the bottom without crashing.
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.
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:
A vue project (`pnpm create vite -t vue-ts`) is even smaller at ~25KB:
I've created plenty of medium-sized projects with React/Vue clocking in at 200-300KB compressed (excluding image assets). You can still realistically use those on 2G — yes I've tried, not just in dev tools, but when I was actually rate limited to 2G.
> 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.
57 replies →
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?
8 replies →
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.
Just to add Svelte (`pnpm create vite -t svelte-ts`) ~8KB
> 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?
1 reply →
>You can create that kind of garbage with any framework, or without framework.
The whole point of the framework is to make even absolute garbage stick together. (While making the developer replaceable.)
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.
8 replies →
> 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.
28 replies →
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.
2 replies →
> 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.
5 replies →
>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.
5 replies →
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.
17 replies →
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.
5 replies →
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.
8 replies →
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.
Well most stuff going wrong in apps is actually managements fault. At least in my experience. Either directly or hidden in their decision making.
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?
2 replies →
> 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.
21 replies →
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!
4 replies →
> 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?)
2 replies →
[dead]
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.
1 reply →
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
4 replies →
> 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.
fwiw, I did not have the same take away as you from that part of the comment. I think the intent, and the way I read it, was, "Even when eliminating bandwidth and latency as a factor it still takes 10 seconds to load."
Indeed. This button comparison is quite telling, ragardless of the exact details. Definitely going to look what Nue is made of. It's refreshing to take a closer look at modern web standards — Nue or not.
> 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
https://react-hook-form.com/
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.
1 reply →
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
1 reply →
Most websites are fast before the marketing departments comes to bloat it with ads.
10s of site loading time without ads or videos is crazy, none of the 100 websites I'm using daily are way faster than that.
> I deal as DevOps/SRE daily with these services, and finding one that will do a first load under 10s is close to impossible
Come on. That can't possibly be true.
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.
[dead]
This is what they're replacing react with: https://nuejs.org/docs/view.html
It's an untyped view layer kind of along the lines of early angular 2.0.
The model files are plain javascript.
So no typings anywhere. Which is fine, I guess this is targeting the vuejs crowd. Maybe their marketing should pivot a little bit in that direction, most react people now use TypeScript because first class types in your view layer are super useful
Author here: It’s true—Nue’s view layer is untyped. That’s by design. React’s ecosystem has devs slapping TypeScript on everything—even CSS—which is overkill. Nue flips it: presentation stays clean and semantic, web standards do the heavy lifting, and real static typing (like Rust or Go) shines in business logic where it counts. Thoughts on this?
> ... slapping TypeScript on everything—even CSS—which is overkill
Yikes, this framework will never fare well in any decent sized or above project.
Even Typescript is problematic sometimes, as it has several forms of coercion.
I manage 2 large scale production apps using Typescript (Along with the rest of the infrastructure) with a small team.
This simply would not be possible, had I not been guaranteed that things at least type check when reading diffs from PRs.
12 replies →
This seems incredibly shortsighted. If you're building an application by yourself you're gonna remember the relations and dependencies - but even on a small team (say ~4 devs) or even if you don't pick it up after a while, there is going to be stuff you forget.
It's also nice when you move stuff around, you can rely on the LSP to rename and fix everything that breaks. If you have a simple website it's fine, but when you start to have multiple components... Losing typing is a huge deal.
1 reply →
Having the author come out and say that being untyped is a feature, is definitely one way to kill of any potential interest for that framework.
44 replies →
Personally, I consider it a strike against a frontend framework if I can't type check my templates. They're entirely data-driven — exactly the kind of place where type checking is the least effort but still a a big help.
In any nontrivial project, templates become a large fraction of my LOC, and it's already challenging to confirm they work right and don't break. Type checking that I'm passing in the data they expect, and that they're reading valid properties, is a cheap way to get a big win.
Web standards are great, but I'm not sure what "heavy lifting" they do that would make me feel like type checking was unnecessary.
1 reply →
I am not on the React bandwagon, currently using HTMX
But I would very much prefer to see TypeScript in a framework. Optional TS is ok but "untyped by design" feels like an anti-pattern, even HTMX has TS types available.
> React’s ecosystem has devs slapping TypeScript on everything—even CSS—which is overkill
"We don't use Typescript because there are people that exist who use it for CSS when using React" is one hell of an argument that makes absolutely zero sense.
5 replies →
I probably have nearly the exact opposite opinion of where static typing is the most beneficial. I think it’s precisely at the UI rendering layer, because that tends to be where you’re dealing with the data types with the largest number of properties, deep nesting, etc.
I pretty much enjoy using MaterialUI with React (MUI) and have statically typed CSS: `<Stack sx={{ alignItems: "center"}}></Stack>` - I get full IntelliSense/autocompletion for the sx props (i.e. alignItems when typing 'al') and their value (i.e. 'center' when typing 'c') etc. Sx-props are composable, so you can centralize common used sx/css etc.
Any typos or invalid props/value will result in a compiler error.
I agree with most other commenters: Type safety is a great feature to have. And to intentionally dismiss it or only grant it to certain aspects of the application (where does business logic start and end anyway?) is a really bad sign for me.
how can "not typed" be "by design" and presented to us as a feature. Your project looked interesting but your presentation here makes me have big doubts
I worked with react before typescript, react with flow, angular 1 (large projects), and these days I mostly use react with typescript.
I don’t use it for css, but for the view components and code I find typescript actually makes me both faster and my code is more reliable. To me this is one of the killer features of react that other libraries are in various stages of catching up to: full static type checking end to end. (Also through the API to the backend with a little more work).
That's one way to find a niche audience.
Typed JSX is one of the handful of key innovations that made React successful, IMO. I think you need to really understand what you're replacing before you can replace it.
Nothing in your view is "web standards". And nothing in web standards can do the heavy lifting of showing things like "`nam` is not defined on object `user`"
2 replies →
> slapping TypeScript on everything—even CSS—which is overkill
Nope. Hard disagree. I want the developer experience of autocompletion of CSS variables, and I want build errors when someone makes a mistake.
Type everything.
Frankly that's a good reason to never give Nue serious consideration. It's all fine when you're building small apps one view at a time. When you have an application with hundreds of views and you need to refactor, that's when you need the types, otherwise you'll never see the tail end of oh we missed that this needed to be renamed there too.
At that point, why not just use vanilla JS and no framework? Literally zero build time and zero bytes of framework code. And it's fast as hell.
I honestly can't see what's wrong with using TypeScript anywhere in place of JavaScript. Unless you're making a simple script or a throwaway prototype, then you're pretty much always better off with it. It's invaluable during development and it's compiled away at build time.
1 reply →
Uh oh, you've summoned the typesetters
Jesus, this is a regression not a feature, for christ sake. Typed CSS via emotion/styled-components is an amazing feature to call it overkill. This alone is enough to dismiss nue.
Last time, I promise: please, PLEASE don't use ChatGPT (or others) on us. It's _extremely_ obvious, and it takes away 90% of your credibility. I'd much rather read a bit of broken English than read this kind of slop. It's a huge reason why I can't take this seriously.
ALL your docs are chatgpt. All of them. All your issues. Your comments here. Are you even real? Yes? Then TALK to us.
/rant.
2 replies →
There’s a lot of negativity around this so I just thought I’d chip in and mention my appreciation for it. Projects are allowed to not be typescript, and I actively stay away from it as much as possible when working with browsers.
I don’t work in TypeScript, I don’t write in typescript, and I (along with everyone) don’t deploy typescript. I have multiple different build processes in my project to remove different types from different dependencies that are incompatible with one another just to untype them.
So personally I find standard js a huge selling point :)
> I guess this is targeting the vuejs crowd
Vue is written in TS and has first-class support for it, even at the template layer.
Vue with SFCs is not actually typescript because typescript can not parse the SFC syntax, you need a forked typescript called `vue-tsc` for that.
Shows what a hack vue really is.
Only since Vue 3 though, and the types are still not as good as React.
6 replies →
> most react people now use TypeScript because first class types in your view layer are super useful
Most people use TypeScript because React apps have grown to 200k lines of mostly entangled code with business logic and are unmanageable without it.
If one goes in a different direction there's less need for it.
I mean a rapidly changing front end codebase is always going to be entangled mess no matter if it’s react, plain JavaScript or even “native app code”. Front ends are where the rubber meets the road and have to deal with fuzzy weird human shit and miles of edge cases. That is just the nature of the beast.
Even if you attempt to tame it and make “the prefect codebase” it’s still gonna be a mess.
If anything React and typescript help it from being an even larger mess full of homegrown idioms that are normally baked into the framework.
There is no such thing as not using a framework. You either pick an existing one or build your own. Very often the sensible choice is to pick an existing one.
1 reply →
Most of the Vue devs I know, also use TypeScript for the same reasons.
> I guess this is targeting the vuejs crowd
Typescript support and usage with Vue is very large. Vue itself is written in TS and most large libs are also written in TS. According to /r/vuejs and my personal experience also most new apps.
This is great. But I went for Svelte. Invested in Svelte and SvelteKit. Wrote a decent sized app (not toy example, pretty feature right, tens of forms and screens if you will) and later I looked back at React.
And I discovered that:
So I'm sticking to React for next few years especially when the React compiler is already being used inside Facebook and Instagram and released as public beta.
Even React Native supports React compiler and I don't see this support going away rather getting better.
PS Edit: React compiler leaves not much for runes in Svelte or its compiled nature. I don't like Svelte much after runes because it feels like you're not writing Javascript rather a notation that looks like Javascript. Post React compiler, much of the hooks hell is not needed in complex scenarios.
Svelte is definitely much less verbose and requires less code. Performance is also way better but it might not matter for many use cases.
The drawback is that since Svelte is really a language[1] you now need a compiler and custom dev tools to make it all work. This requires some serious effort to maintain and evolve.
I love Svelte and have been using it almost daily for years... but the team really needs more resources to accomplish their vision and maintain it for the foreseeable future. It's amazing that huge companies like Apple are adopting Svelte (eg: Apple Music) and not investing in it.
[1] https://gist.github.com/Rich-Harris/0f910048478c2a6505d1c321...
TanStack Query (formerly known as React Query) is absolutely compatible with Svelte. https://tanstack.com/query/latest
I work with react for a decade now, and with Svelte for past 3 years. Svelte is obviously a newer generation of framework, and works for me a lot better than React. But I agree there are some rough edges, mostly around the ecosystem
No, the support is quit limited not as many features are supported.
I transitioned to svelte and I’m finding it around 3x to 2x times less complex than React
I learned React back in the class component days. I recently picked it back up and found functional components and hooks to be absolutely baffling. Does anyone know why they went down this route?
Trust me, the function based components are way too simpler. Just a function that returns HTML. That's it. compose your UI as those functions. These functions can take arguments to customise their output (rendered HTML) as arguments (called props) or can call special functions from React (called hooks) such as asking the React to "remember" a value for you (state) or cache something for you (useMemo) so as to not compute it every time or trigger rendering if value of certain variables change (useEffect) or at the component start (useEffect with no dependencies mentioned) and that's all the React that you need to know for I would say your 95% of the needs.
React compiler (already used for Facebook and Instragram code base) further renders the use of certain hooks unncessary thus making React a lot more simpler.
Hooks require less boilerplate to set up and reuse stateful logic across components
If you havent watched it yet, the talk that introduced hooks explains much better than I can: https://youtu.be/dpw9EHDh2bM
Nue’s a web framework I’m building to slice through modern web dev bloat. When a Vite/ShadCN/Tailwind button is 40% heavier than a full-blown SPA, it’s time to do things differently. We’re retooling from the ground up—web standards first, no bloat. It’s for frontend architects, design engineers, and UX folks craving simpler, saner workflows. Still in progress, but the shift’s coming. Curious to hear your thoughts!
Nue is a very cool project but if you want people to take the project seriously you should probably tone down your confrontational marketing :)
Also, I checked the demo and there's like 100kB of WASM code you're not taking into consideration in that React button comparison?
Anyway, congrats on the project. I'm really curious to see how the whole vision will turn out.
100% agree, I felt very put off by the tone, I think HTMX pull it off by not taking itself too seriously and also having good insights.
I wish the homepage talked more about how nue approach the problems rather than how better than other framework it is.
I think you're right on the marketing. I'll tone down.
The comparison uses the non-wasm version at mpa.nuejs.org
3 replies →
At this point I don't even understand why everything has to be a SPA. It's complicated and inefficient and should probably be only used with highly interactive applications like some kind of Photoshop or Ableton live for the web, which means very few apps should use this paradigm. Granted, I'm not much of a frontend dev... but what I know is that if "instant search and other operations over 150,000 records" is a problem then it's probably best to re-think the paradigm.
With SPA, all your backend has to do is spit out data and sometimes validate it, leaving your front-end completely in charge of presentation and user interaction. You can even have completely separate teams working on it. It feels a lot less complicated than the alternative.
4 replies →
SPAs are great for the hordes of B2B SaaS apps out there, which for the most part are just some fancy variants of a table. They're not a Photoshop, but they're still highly interactive.
3 replies →
If you look at the documentation at nuejs.org/docs, you'll see how Nue is really more about apps that focus on content rather than single-page apps (SPAs). However, this release is all about SPAs.
1 reply →
I recently thought about just using ASP.NET MVC with Razor pages for a quite simple app at work. But I'm already familiar with SPAs, so with that background I chose to "just use Vue as always (or Solid or Svelte, I like all three of them)" as SPAs have some advantages, e.g. separation of concerns, easier integration of libs like agGrid or eCharts.
Without that knowledge, I agree that good old SSR (MPA) is easier and more maintainable. And more robust.
Both way can work fine, enough great examples out there. The real problem is, imho, we shouldn't need a (graphical) UI at all. That's where all this discussion comes from. When the whole "frontend" disappears in a year or 10, it will make a lot more sense.
This happened to a team I know. They built a flashy SPA dashboard because it was easy to copy-paste from templates. It worked great—until a real-world requirement, like a data grid, came along.
IMO, most SPAs are bloated. MPAs are cleaner and more forgiving.
The only reason to still stick to an SPA instead of an MPA is that the app is so bloated you want the user to only have to load it once.
And people say "lazy loading!" but by the time you've implemented lazy loading in a SPA, you could have just used an MPA to keep things modular and memory efficient.
SPAs became popular at a time when companies thought everyone was going to move to progressive web apps. Then the bloated frameworks came along, PWA interest has faded, and here we are.
The above are all my opinions, apologize in advance if they come off as speaking objectively.
There's a crossover with crossplatform apps (like React Native), which is a force multiplier for some applications / orgs / etc.
Not the discussion, but SPAs are fundamentally safer against XSS, in the sense that data and code have different paths.
I don't think the "a button in X is 40% heavier than an SPA" is a fair comparison; including a framework will add weight, but these frameworks are not intended for single components. Compare apples to apples, then we can make a fair comparison.
That said, how does Nue compare to htmx and other frameworks leveraging the modern web standards?
There is no such things as a true apples to apples comparison for libraries such as this. They all cherry pick something and ignore a ton of things such as:
React is really well-thought out and well made by hundreds of professional contributors that have worked on it for years. The premise that hobbyists can make a better overall solution in less than 8 months is strange. At best they can make a smaller solution, but it will have to sacrifice in other areas.
11 replies →
htmx for "easy" html, solid for reactivity. Don't know how much more Nue provides; but, there you go for numbers.
Is there a full-blown SPA demo made with htmx?
How is Vite relevant to the discussion? It's like saying the UI based on Visual Studio is lighter.
Because Vite emphasizes "Optimized build" in their marketing
2 replies →
I resonate with what you're saying so I'm mostly just curious how long you've been developing front end code. I think those who have had had to run the gauntlet of naked JS in the 90s developed the discipline to intuitively code untyped.
I've been enjoying JS since it was first added to Netscape and I also loathe the creeping bloat that is endemic to web development these days.
In the event that I want an "intellisense" dropdown capability in a project, I'm a big fan of JSDoc. I think the bootcamp kiddies these days just don't have enough experience to get by without the intellisense crutch.
Incredible marketing blurb! Not a single bit of detail about how this works
What do you mean by "lighter than a React button"? Do you mean lighter than the entire React runtime, plus a React button?
If so, that's somewhat disingenuous because even though a page with a single button would require the entire runtime, a second React button would be significantly cheaper than that.
Yes. React runtime included. Benchmark and details here: https://nuejs.org/docs/react-button-vs-nue.html
3 replies →
flawed example for a framework. Tell me...are 2 buttons going to be 80% heavier? why use react if all you build is a button? you need a tractor to pick your groceries from store?
I wish instead of this marketing article there were technical details, for example: what method of change tracking is used (proxies Vue-style or recomputing everything React-style).
Also I didn't understand the phrase about JS "overflowing stack" with 150 000 objects. I created a list of 150 000 objects with the following code:
According to profiler, this array (with objects) uses 14 Mb, where 2 Mb is array and the rest are objects and strings. Running list.find() without any indexes also doesn't overflow the stack. With indexes it would probably be lightning fast and won't need any WASM and complications.
JS is not that slow. And if you do numeric computations (i.e. multiplication of numbers in large arrays) the code gets compiled and runs pretty fast.
The author uses something like `list.push(...objects)` in his demo code, and I believe this is the culprit. Passing many (~100,000) arguments to a method at once using the spread operator is known to cause a stack overflow, because, in JavaScript, each argument is placed on the call stack.
Spreading arrays and objects is such a common performance hit. It works fine for small instances but falls over in large instances.
Here's the JS CRM engine https://github.com/nuejs/nue/blob/master/packages/examples/s...
I see a number of issues, but don't have time to look into them.
1. Spreading when you probably don't need a copy: sortEntries. Sorting is probably where the overflow happens. Just sort in place or use Array.from or slice.
2. Excessive use of array functions. In my experience, a C style for loop performs better when you need performance. Create an empty array before, perform your business logic inside the block, and push to the array.
3. I don't know how filter is called, but it potentially loops through all of the events three times in the worst case.
4. paginate manually creates a JSON string from the returned entries. I don't know why, it seems inefficient.
Most new frameworks start as the "lightweight" option to whatever more mature options exist at the time. This is no argument for adoption.
Please post again 10 years from now after you have added all the bloat your users request and handled all the edge cases you don't yet understand.
If you are still lighter than a react button...that will be news worthy.
So, nothing is worthy of discussion or can claim any benefits over the incumbents until it has become an incumbent itself? How is it supposed to attract the necessary users to get bloated if they can’t talk about it in relation to the established players?
All I am saying is that being lightweight, when you have been around for less time than a mature solution, is a mute point.
It's a cop out way to differentiate because you are clearly not comparing apples to apples.
You have a fraction of the features and a fraction of the bug fixes. You are trying to make it sound like you are a 1:1 replacement, when you are not.
2 replies →
I don’t think React has ever been considered lightweight, judging from the mostly negative reactions from this website when it first came out.
JS frameworks have often valued DX first over what it outputs. Frontend devs also frequently care more about a) their own tooling and b) how it looks, to a much higher priority than the performance and stability of their output. At least from my own experience in the community :)
1 reply →
Solid.js is doing amazing w/re to its bundle size. Its been in development for something between 6-9 years depending on how you count and it is still very very slim.
I feel the same. I started using svelte to build widgets with few requirements that were deployed as web components, it was great for that.
Looking at the project:
To convince me that Nue is a framework worse using, please show that Nue:
> Why is the demo impressive https://mpa.nuejs.org/app/ I believe someone can do the same web-app in React with the same performance
Weren't the main points on the main page that it was small ("lighter than a React button"), and could handle large amounts of records ("far past where JavaScript (and React) would crash with a stack overflow error")?
Those points are only true if you're comparing to a React app that uses bloated frameworks and inefficient list manipulation (as other commenters pointed out, `list.push(...items)` causes problems)
If the authors of this project mean to say that a button in react wouldn’t work without including the react library (which is why the button is supposed to be 73kb), it’s a weak point, because the react library would be reused by other parts of the app bundle at this point.
This is misleading to people and the promise is so shallow that it almost feels insulting.
I’m the author. To clarify: a button installed via ShadCN/Vite’s official docs (https://ui.shadcn.com/docs/installation/vite) ends up way heavier than a full Nue SPA. It’s not a jab at React devs—just showing how web standards can flip the script on bloat. Any thoughts on framing this comparison better?
Can you give some examples of some of these standards that make Nue stand out and other frameworks don't use? It seems that if other frameworks make use of these standards we would get a similar performance boost across the ecosystem.
1 reply →
Mention that you know you are missing dozens of features instead of blaming it on “web standards” would definitely help frame it better. Do you think Vite doesn’t know about web standards? It reads pretty naively.
Also I recommend just not making a web framework. There are many of them, some very similar to Nue. Your effort could be placed on improving what is out there. I suspect that is a lot harder and less fun than just making something new. But if you manage to contribute then you’ll be helping an entire community of people whereas a new web framework will likely see almost no adoption before it is abandoned.
It's like someone making a hello world in C using the std, then one hand crafting the console print but losing literally everything else. Of course, if my goal was to just write hello world then it would make sense but 99.9% of people in the world will use something else, invalidating the point.
Maybe don't compare apples to oranges at all. No one is using react for a single button.
I really like the approach but the demo [0] doesn’t really work on iOS Safari (although might be my outdated 16.7.8 version). Scrolling doesn’t work, the layout and buttons have weird line breaks, the native search button is embedded in the custom designed one, leading to 2 icons…
[0] https://mpa.nuejs.org/app/
Scrolling works now on iOS safari! That was a quick fix. Thanks to the author (and bug reporter!)
Now do macOS Safari......
The author is using a trick they've used in almost every past submission: They implement much less than the component they compare themselves to, and then show how much smaller their own solution is.
How is the SPA less than the button?
6 replies →
Page height/vertical scrolling is also broken in both Chrome and Firefox on Android. On FF the comment box gets hidden under the menu bar.
Probably the page height gets forced with percentage or vh, which should be usually avoided. If forcing is wanted, svh or dvh should be used.
Are there any code examples? I've looked for a bit but haven't found any. That should IMO be the first thing on any blog post about new frameworks.
There are currently two examples:
- `nue create simple-blog` This highlights content-driven websites.
- `nue create simple-mpa` This is today’s SPA demo, where 'MPA' stands for multi-page applications. It shows how client-side routing and view transitions can seamlessly connect content-heavy pages with app-like views.
Source code here:
https://github.com/nuejs/nue/tree/master/packages/examples
Is there any documentation about them?
For example what is this 200kb binary for?
https://github.com/nuejs/nue/blob/master/packages/examples/s...
1 reply →
I also spent five minutes clicking around and couldn't find a sample of what the code looks like
IMO talking about the “heaviness” of popular web frameworks is way too simplistic to be actually meaningful.
How light or heavy an app feels, in my experience, has very little to do with initial bundle size, and far more to do with how adeptly the developers have solved the distributed systems problems of their app.
Are images compressed and cached on a CDN? Is linked content pre-fetched? Does the app avoid unnecessary roundtrips to the server?
These are the questions that truly matter, IMHO. They’re also things that junior devs are likely to get wrong.
All that said, I agree that you tend to see far more sluggish websites written in React than in any other framework. But personally, I think that’s a consequence of React being popular, and attracting a larger proportion of devs who miss important details.
I share this opinion of Electron, BTW.
And importantly, does the app have clear loading states when it has to block on something? Making sure something happens immediately can make things feel fast even if you're waiting on the network.
> Does the app avoid unnecessary roundtrips to the server?
Guess what, using server-rendered pages avoids all unnecessary roundtrips by definition, because the entire page is loaded in one go. You can augment a server-rendered site with client-side SPA features for seamless interaction within the page, but that's not a key requirement either.
Rendering and loading an entire new page just to open a dialog seems pretty unnecessary to me.
Yes, React is huge, but I also see it used for everything and everyone when it's really not the right tech-stack in many situations.
Just need a simple interaction free site? Use Astro.
Need some interaction? Use Svelte. Larger project? SvelteKit.
Need a more established solution? Use Vue.
Working in a huge team and need a highly opinionated framework with strict conventions? Use Angular.
More than 99% of websites would be sufficient with Astro though. And when just some interactivity is needed it is always possible to add Svelte / Vue / Solid / Alpine / HTMX on top of Astro.
Weird that the current state of things for a simple, noninteractive site is some kind of framework and not just “write the HTML with a little JS where needed,” which works perfectly well and requires no additional baggage.
React itself is not huge
> frontend architect, design engineer, and UX engineers
Damn should I update my resume again? I’ve used webmaster, web developer, full stack developer in the past. Can I use "internet creationist" to leap directly to the next call phrase?
More seriously, I’m lost when using a search bar in a job listing. Now I just type "JavaScript" but that miss the posts only mentioning the higher stack and/or typescript.
"internet creationist" make you sound like God either chose you to be a content creator, or ordained the internet into being...
I know a guy whose middle name is "Almighty God".
I've actually wondered how that looks on a resume :D
Author here. No need to update the resume yet—titles do keep shifting! React’s monolithic style has muddied the waters, making it tough to build clean business logic, prioritize performance, craft CSS design systems, or just focus on user experience. Nue’s here to unblock that—giving each role room to shine with leaner tools, not cramming everyone into the same heavy stack.
If you still use webmaster, perhaps updating is a good idea. Haven't seen that term used in the wild since the early? 2000s
it is time for a comeback
Don't forget to mention "vibe coding" somewhere too
I really like how Nue is shaping up! Having a clear MVC separation, leveraging modern web standards, semantic markup—all great things. Kudos!
Seeing the .dhtml extension certainly brings back memories... One thing I dislike is that the HTML is still parsed and converted into JS, which is then evaluated at runtime, correct? I realize that this is required to support templating and a nicer syntax for binding and such, but my ideal "framework" would support plain HTML files that are not converted to JS, but used very lightweight syntax (essentially custom data attributes, and `<template>` elements) to make the page dynamic. In fact, I'm experimenting with such a library right now[1]. This approach is likely more difficult to manage when building large web apps, but for simple UIs as used in browser extensions, it's fairly sufficient.
Frontend web development has been stuck in a pit of complexity for well over a decade now, and it's about time we go back to basics. There are new generations of frontend developers who only know this way of working, which is a shame. They're not really _web_ developers, but React, Vue, or whatever the popular framework is, developers. Web standards are far along now that there is very little additional glue and sugar needed to build modern web applications. React ushered in a new way of building UIs, but it also spawned dozens of copycats and frameworks that are downright developer-hostile beyond their shiny exterior. Not to mention the security nightmare of an incomprehensibly large dependency tree. Let's actively reject this madness.
[1]: https://github.com/hackfixme/miu
> Using Rust and Event Sourcing for instant UX over 150,000 records — far past where JavaScript crashes with a stack overflow error.
Nit: while I fully support making the web more efficient and hope that Nue is successful in promoting that, I'm skeptical of the "crashing" JS claim here. You can do amazingly efficient things with TypedArrays, the forgotten middle child between JavaScript and WASM.
Having said that, this requires building a few clever data structures on top (I've gotten a lot of mileage out of "typed" dequeues, and (sparse) bitmaps myself), often emulating structs in a language unable to express them properly. So the resulting code is not exactly idiomatic JavaScript — which I presume is what they implied here. Plus in this case it probably still wouldn't be as fast as a well-written WASM implementation, since almost all of the work is likely spent searching with only a little bit of DOM manipulation at the end.
So I'm both agreeing and feeling like it slightly overgeneralizes. I guess my point is: yes, let's be critical of bloated web frameworks, but let's not equate React with JavaScript either.
Author here. You’re spot on. I took away the React association and added a direct link to the JS code [1] that hit the ‘Maximum call stack size exceeded’ wall. TypedArrays can do wild stuff, no doubt, but yeah, it’s not exactly vanilla JS—and still lags a tight WASM setup. Appreciating the nuance here!
[1]: https://github.com/nuejs/nue/blob/master/packages/examples/s...
The new wording is much more nuanced, appreciated! Also the fact that you link to the actual code that broke down, making it possible to verify the claim. Less ammunition for the people who actually are skeptical of the project instead of just nitpicky like me ;)
Speaking of the code in question, it looks pretty sensible - there's a bit of low-hanging fruit where one could avoid creating redundant arrays by turning chained calls to map and filter into one for-loop and such, but that's about it.
What confuses me is that there's no point in the code where I see any recursion, here or in the other JS files that seem relevant, so how does one end up with a call stack overflow?
(not questioning that it crashed for you, it's just that I don't see any obvious flaws in the implementation, so I'm curious to lean what the "gotcha" is in case I ever bump into something like it myself)
6 replies →
What does event sourcing have to do with searching or "instant keypresses"? It's a storage pattern for recording events, not a way to search.
Like, you're searching a single table for text messages, not a stream of events.
Its not big frameworks making the web big/slow. Its...
Yes, its absolutely the big fucking frameworks. In most cases it is the actual literal use of the frameworks, but even that isn't the real problem. The real problem is deeper. You can call it second order consequences.
Its developers that cannot optimize and cannot program without something like React. If you took React away would you suddenly not be able to do your job at all? That's horrible problem to have. The result is a bunch of toxic defensive posturing by people who suddenly appear not qualified to do the work.
If you cannot dig deeper you certainly cannot optimize deeper. That makes the assumption you are actually measuring things and optimizing things in the first place, which many developers aren't. Again, if a given developer lacks the capabilities to dive deeper they may also lack the capabilities to measure things, as is quite common.
Most IRL software failures like poor performance, lack of stability, unmanageable technical debt, etc are going to be systems and human failures 90%+ of the time, not the individual tool or framework choices.
It’s human failure 100%. Big frameworks just lower the baseline such that this failure becomes more acceptable, less immediately aware, and masks candidate selection.
If you want to achieve something smaller or faster you have to measure for it. Odds are if you cannot execute without a big framework telling you how to proceed you will not be able to measure it either way.
1 reply →
Today it’s Nue. Tomorrow it’ll be Olde and we’ll complain about all the boilerplate or repetitive update logic we now have to write.
Fair point—new tools pop up constantly, often just piling more layers on React’s bloated stack. Nue’s not that. It’s a fresh start, built on web standards and closer to the metal, not another abstraction treadmill. That’s why a button can be lighter than a whole app—less cruft, not more boilerplate. Tomorrow’s Olde might still fight yesterday’s bloat; Nue’s dodging that trap from day one
The animations makes it feel slow, the lack of any throttling/debouncing means that my input feels slow too.
The animations are always a deal breaker. And then WASM.
Are you talking about this 150,000 record Rust version?
https://mpa.nuejs.org/app/?rust
Yes. On that version, Chrome 134.0.6998.89's devtools on my Macbook (M2 Max) are indicating 100 to 250 millisecond interaction times and a 160 ms frame when entering text into the search field.
2 replies →
Loading the page on Fast 4G connection takes 9,61 seconds before I see _any_ content on the screen. This is loading the "all contacts" page that shows 12 items with a title, excerpt, time stamp and user name. Is this expected performance? Network shows the app downloading huge 4/1 megabyte chunks.
If you just use an html button with simple styling the size is around 58kB (not the quoted 73kB, which is from other libs that they built with like ShadCN than just react), so its still impressively smaller than react.
That said, using Preact instead (a smaller and more modular react-style library) the file size is less than 5kB. Its almost a drop-in replacement for React too: https://preactjs.com/guide/v10/differences-to-react
If i make a similarly minimal app with Nue (the lib the article is about), export as production, and remove the favicon it seems to want to add automatically, the filesize is 28kB. I couldn't see a way to meaningfully reduce that in their docs, as its clearly exporting things that arent being used.
Its pretty disingenuous for them to compare an app to a single button, given their own single button implementation is massively overinflated too. It does appear to be a full app framework rather than just a view library though. So I'll definitely give it a whirl.
To the OP: From a lot of the comments here, including my own, comparing yourself in this way is only going to result in people calling you out on it. Its clear the lib has merit in its own right, but you aren't comparing like to like, and if the focus is on "button" apps, then you are still WAY behind some other libs in terms of export size.
Nue seems to be in an odd space. It's an untyped framework, built on top of "web standards".
But if you wanted web standards + web component, Lit already fills that space. If you want untyped JS or little/no JS at all, there's HTMX. Or if you're just tired of React, and want something faster + simpler, there's Svelte/Solid.
I'm not sure what problem Nue is uniquely solving.
I like the philosophy so much, I myself am working on a minimalist theory to explain human psychology and strongly against specialized therapy and bloated productivity systems. We have specialized rules for everything which I feel repeatative and we are not using the full potential of human mind.
Anyways, here are my initial observations on NueJS
1. In the age of AI we need to support it for broader adoption. One of the reasons people choose NextJs and Tailwind over other frameworks is that LLMs understand them well. We need some minified doc to pass onto LLM to make it understand the framework.
2. What do you think about the unstyled components like Radix UI? Accessibility issue are important for components like Model.
3. What do you think about server components? I like them personality as we don't need to pay for separate NodeJS server as a small team.
4. How much Rust is required to use it properly? It's not an easy language to learn as far I heard.
5. How do it compared to AlpineJS who also focuses on performance?
Absolutely brilliant I've been following Nue for a while and every release gets more and more impressive.
Thank you so much for putting in the hard work by making it and I hope others can understand why this is important and use it instead of cargo culting React and making the web worse every single year.
Looks interesting!
Regarding the code examples in the docs:
It would be great if the examples for models and views would be from the same example.
Currently, the view example is something about users and the model is something about customers?
The interesting part for me is not how the individual components of the architecture work but how they connect...
They are from the same example. Here's the source code:
https://github.com/nuejs/nue/tree/master/packages/examples/s...
Look for "view" and "model" folders
The FAQ (https://nuejs.org/docs/faq.html) describes pain points that seem pretty foreign to me, the exact thing I appreciate about React is that I can focus on the domain and the tech MOSTLY does fade into the background. It has been an improvement in that regard, to all the frontend MVC I've done before and the architectural pattern has been adopted for good reason by all the native platforms.
TBC in React and its offspring, you can still model business logic outside of components, we just learned that most UI development is better served by keeping UI and its state closer.
"mostly" for sure; it's a good mental model and allows me to build modular applications etc, but I hate that a nontrivial amount of code and headspace is spent on things like re-renders, memoization, useCallback, dependency arrays, etc. I hope the React compiler will finally solve this, because the competition (apparently?) has (I haven't had the time to look into e.g. vue yet).
Absolutely, it would be nice if we found the right abstraction to get rid of that part as well. Basically every non-React framework's answer to that is Signals (aka change tracking), where React is doubling down on unidirectional data flow and thus dependency arrays. React Compiler indeed solves the 99% of performance related memo-s.
For effects you still will have to understand the mental model (which I'd argue is inherent in the domain and not incidental to the tech).
From reading Nue's docs on Interactivity, it seems to opt-out of the discussion by going back to good old manual UI refreshs. I personally would not choose that, too many pre-React debugging nights spent on chasing state<->UI desynchronization bugs.
Very catchy landing page, like it. And I've read the documentation. Unfortunately not convincing me. I mean, writing larger web apps means nothing else then dealing with a lot of _state_, really a lot of asynchronous _state_. Clicks, notifications, mouse movement events, push messages, navigation changes and so on and on. Larger web apps are state monsters. That's why I choose a framework that is good a state management in the first place. React is one of those proven. Nue does not look trustworthy in regard to good state management tbh. For smaller apps that might not be a problem, but there I tend to use vanillajs anyway.
I can’t find a single example of what a Nue app looks like. All I can find is pretentious claims about how Tailwind sucks and other outlandish claims.
This framework is a good example of something I call, "there's plenty of room in the middle." (In analogy to Feynman's "plenty of room at the bottom" about nanotechnology.)
Much like how Cosmic Inflation in the early universe left the imprint of microwave background radiation written exponentially large across the sky, I believe the exponential expansion of computing during the era of Moore's law left whole sections of scale in software not-fully-explored.
Specifically, as "average app sizes" went from 1K - 10K - 100K - 1M - 10M - 100M+, you could imagine the 1K-10K got fully explored because the space wasn't that big to begin with, and the 1M - 10M range got, if not explored at least inhabited, but it could be that that middle range of "neat applications that weigh in ~100K+ but less than 1M" didn't get completely explored because we didn't spend enough time in that era of computing.
A similar thing may be playing out in AI scaling, where we went from tiny to medium to huge model sizes, but now some new participants are going back and doing neat things with medium sized models.
Honestly, after playing around with your example and tweaking a JavaScript example, I feel that my plain JS example is faster than the one with WASM/Rust on Nue (possibly due to the animations). Please disable animations; I think they make your WASM example feel slower than it probably is.
Here is a 1 million rows table in JS with filtering, sorting, and pagination: https://htmlpreview.github.io/?https://gist.githubuserconten...
It sounds cool and all but the single button thing just irks me. The point of React is for making a system of components with potentially complex relationships between them/when they’re displayed, etc… Nobody is using React to put a single button on their website. It’d be nice if there was a more useful, practical “benchmark” that your entire marketing of the library is centered on.
1. It's an SSG and competes with projects like Astro or Solid or Next. Comparing to React is apples to oranges.
2. Benchmarks are just numbers without details. React+ReacDOM gzipped/minified is 40 kb in 2025. I doubt a button adds 30 kb. But if you really want to make small SPAs, Preact is just 4 kb and it doesn't require to learn a new bespoke templating DHTML-style thing.
3. From FAQ
> The WebAssembly example in our demo isn't about raw performance — it demonstrates something far more important: what becomes possible when your business logic is properly separated from presentation.
> But when your business logic lives in its own pure layer, entirely new possibilities emerge. Rust is just one example — you could model complex financial calculations, build sophisticated data visualization engines, or create real-time collaboration systems. Your logic can evolve independently of the interface, enabling the kind of architectural advances that the React monolith prevents.
The writer was high or delusional or bad at explaining the point. Nothing prevents you from putting logic into "its own pure layer" in any language. You can make it messy and impure with Rust/WASM/... just as you can keep it pure with pure JS. And it's not "entirely new" because people separated business logic for literally decades (and believe it or not many of them even did it while using React at the same time)
And meanwhile the Rust version is slower and bigger. "What becomes possible" is a mystery.
"React monolith" just takes the cake. React literally doesn't care how you separate your business logic, it's just a rendering layer. This ironically is a monolith SSG that does routing, YAML frontmatter, Markdown extensions, syntax highlighting and what not. Again, you are thinking about something like MarkoJS or QwikJS. Before you are trying to take something down you should probably understand the basics.
Don't get me wrong, it's a cool project. But it could be more humble because authors don't seem to fully understand themselves what exactly they are proposing.
Nue still continues to advertise with clickbait?
The animation makes it look so incredibly slow…
Yeah, they should remove all animations so it feels instant and really snappy instead.
Disable the "appears" class in chrome inspector, and it's all instant. (faster than the macos mail.app)
Which animation exactly?
All of them? It should feel instant. A UI does not benefit from artificial delays.
1 reply →
The videos. The very first video. Animations like this are done to hide the fact it’s slow by hiding it behind a fancy animation. Used to do this when we were stuck on 3g connections…
Fade in/out animation.
If I felt strongly about going lightweight I would (do) use plain js. I trust myself to know when I'm following basic principles of performance and when the line has been crossed warranting the use of a framework
React is the most used frontend framework, but not a good reference as React is outdated, slow and big.
Take Solid, Svelte or Vue (with or without Vapor mode) as reference and the picture looks different. Additionally when using custom components instead of large UI libs based on HTML elements like <dialog> or the recently announced stylable <select> element you have a very powerful, small and simple stack.
Still, they catched my interest. A lot. I'll dive into the docs to learn more. Maybe I'll be convinced to change my go-to stack to Nue ... damn, I had so many happy weeks with Vue. Maybe till Vue Vapor is out.
So many people are obsessed with Web application size. But there are other important factors as well. First of all, the UI must be functional even it's slow and heavy. If it does the job then it's already a win. I don't actually care how long I'll wait while I'm downloading the JS bundles. I've been waiting 5-10 mins GTA to load back in 2008, waiting seconds is totally ok.
It would be nice if the standard JS library was more feature complete like Python. Then devs wouldn't have to bundle third party libraries.
Or perhaps the caching could be better. e.g. if your'e using Tailwind CSS version XXX, why does the browser have to reload it every single time?
Local persistent storage isn't exactly at premium these days even for "lightweight" mobile devices.
> if your'e using Tailwind CSS version XXX, why does the browser have to reload it every single time?
Security: https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca...
This refers more to tracking, not security directly, though I suppose there is some overlap
This is also doesn't explain why the browser would constantly need to redownload the same files assuming the original requester was the same.
The browser could also introduce an ersatz delay to throw off the tracking.
BTW preact + hooks + router (preact-iso) is 10 kb. It's a good starting point.
And SVG icons should use svg `<use>` tag and shouldn't be counted in code size.
I'm a novice, I chose to learn dart/flutter rather than deal with, and attempt to figure which, web framework to use.
If forced I would likely go with htmx.
Regards nue: do I need to know rust?
Based on work done by svelte and solid, I think it is possible to shave base react down to half its current size, but it appears nobody (inside or outside of Meta) is willing to take on this challenge.
Unfortunately, the tradeoffs are still in favor of react and will continue to be in favor of react for the foreseeable future.
Most importantly it is next to impossible to get developers to give up DX (and muscle memory) for smaller JS bundles.
That post didn’t explain what it actually is. Is it a JavaScript framework? A WASM library? Something else?
Comparing a JavaScript app to anything wasm is false equivalence because wasm can’t do the DOM.
I find the blurring/fade-in effect jarring. It makes it feel slower rather than faster. Feels like fade-in is used to hide the performance.
Please add a button or something to disable that effect.
I think there is an issue with the implementation of search and filtering.
When I open https://mpa.nuejs.org/ and type "kind of rate limit" in the search box, I get 383 search results, and the URL updates to include the query: /app/search/?query=kind+of+rate+limit.
However, when I paste that URL directly into a new tab, I only see one result instead of 383.
Not an April fool's joke btw!
I thought it was an April fools joke, glad I'm not the only one.
Seems to be no support for TypeScript in the frontend? I mean, it is mentioned, but only together with Rust and Go for "computation engines".
No TypeScript = No deal with me.
I wrote my first Javascript application back in the spring of 2025, and I am not aware of anyone who is willing to pay me enough money to voluntarily write Javascript again in a project of meaningful size.
So is there a book that I could read that would allow me to write applications with just HTML/CSS some js and rust? I don't want Nue so much as I want "The art of writing lightweight, feature complete, responsive applications on the modern web."
Would love a pointer to THAT.
I feel like some of react’s innovations should be built into browsers. Jquery got built in with document.queryselect.
Google decides what goes in a browser these days. Since React came out of Facebook there is approximately (checks notes) -ZERO chance in hell- of that happening
The tagline says a lot more about React than it does Nue, but I'm always interested in less bloat when it comes to front-end. I'll try this out, one small thing I don't like is in the demo there is a weird pulsating effect that actually modifies the layout when clicking, throwing me off a little.
React is fine. Next.js is evil.
This doesn’t square with most of my experience with React, especially if use it to generate static code hosted by nginx. I’ve found my personal site to always be wicked fast, even though it’s not that complex.
https://dayssincelastjavascriptframework.com/
Interesting, on that page using Safari, clicking on the home/nue logo or most other links/buttons results in a null error :)
I would hope React buttons work when people click on them though.
I really like the use of markdown and extending it. I think this is the way to go.
Also how you are thinking about app theme and design is really good.
This button demo... really ambivalent about it.
Congrats, Nue seems to be an impressive and well-thought-out design system & framework. It feels like a strong candidate to become the "Web Standards Stack" —finally freeing developers from the complexity and bloat of modern frontend tooling.
I've been following Nue for a while now, and I'm eager to use it for real world apps. Any updates on when the design system will be released? I know you're ambitious, but I'd suggest launching a single design system first to test the waters, gather feedback, and gain traction — rather than waiting to release everything at once (but losing out to the ecosystem).
I'm eager to dive into the design systems, definitely coming. But first, I wanted this release to prove Nue isn’t just for ‘hobby projects,’ a label plain website generators often get stuck with. This SPA demo was key—showing how working closer to web standards really shines for complex apps, not just simple sites.
Regarding Rust, are we talking about a Rust backend with RPC/REST or is it simply WebAssembly compiled from Rust? If the latter, how is the data synced for CRUD?
Replace N in Nue with V for Vue, and it will be perfection.
this is why inertia.js is a positive path forward.
it relegates React, Vue etc to be view layers - purely view layers. all models / state etc handled by your monolith Rails, Laravel server. this simplifies a lot of things.
frameworks like Vue & Svelte have scoped styles which preserve knowledge of CSS. While Tailwind is convenient - a lot of people won't know the capability of CSS
and why it was named cascading & the customability of CSS for the user.
But what if it is not the frameworks that are bloated but the application developers that make bloated applications? Then how would this fix anything ...
In the meanwhile on the App/Play store some native apps like YouTube weight around half a GB... but only the web is bloated
Would you be able to hook this up to https://www.convex.dev/?
Couldn't switch to docs from the page linked here, Chrome on macOS. Refresh and it works. Big hopes killed in an instant.
Just do VanillaJS...the W3C is your framework.
This is cool. Though I think what could be improved is using folder routing, it works surprisingly well.
Do the AI's generate slow and bloated React, or lean React that works well with the new compiler?
Is it trying to sell Backbone.js-style MVC as a replacement for React?
No thanks, JSX is fine.
why would 150,000 records break React and throw overflow exception ?
Because that demo crashes with vanilla JavaScript at around 110,000 records
Here's the react-table example app with 112,500 records, just like your example. I am not really seeing much of a performance difference (and this is in dev mode - it would be faster if built for production):
https://n9vr4n-5173.csb.app/
it doesn't make sense.
I like this. Cant wait to see it being released.
How does it involve Rust? Server side or wasm?
If React is good enough to power Facebook, it's good enough for your <1k users app.
love the demo and overall reason for this, hope it gets the following and support it deserves!
Nah this is crazy
imo the primary benefit of react is the nice component library.
> What's next We're improving the developer experience in three distinct phases: Framework -> Design -> Cloud
So the "cloud" part is where the enshittification will begin. Been there, done that, switched away from next.js :|
The main benefit React is giving my app is just the ability to update the DOM automatically and efficiently, without me worrying about doing anything but updating the state variables. I have a feeling some very well crafted prompt to the best AI in the world could just about generate something that can also do this in like 500 lines of JS, in a single file. Once we have that, we can get rid of React maybe?
I also hate JSX, and have my app setup so I create GUI elements programatically like "button = new Button("Save", db.save)". Templating has so many friction points I find it to not even be worth the complexity, expecially once you have templates containing other templates with looping and conditionals, etc, and you end up with just an extra layer of cognitive load. No thanks. We can do better. With the capabilities of modern JS (classes, imports, etc) we can phase out React and Vue.
A React comparison is a straw man when there are already popular alternatives that are considerably smaller than React.
> 150,000 records — far past where JavaScript (and React) would crash with a stack overflow error
I think react-virtualized and stack tables can easily handle 1 million rows client-side without a problem (I saw the demo somewhere).
Web development is about convenience, and the speed of development is far more important than ultra optimizations. People simply don't care about super optimizations because servers are so fast these days, and bandwidth is cheap, almost free.
But it's an interesting project. Good luck.
> People simply don't care about super optimizations
Could be, but some optimizations in Nue really stand out. Check out bundle size, HMR speed, build speed, and especially repository size. An empty Next.js project weighs over 300MB, a Vite button is around 150MB, while a Nue SPA clocks in at just 2MB.
I would love to check out the bundle size! Will you ever create a fair comparison, where your Nue implementation has all the same features as the versions you compare it to? All the comparisons I've seen so far are deceitful since they implement much less. If Nue actually produces smaller bundles, why not create an actually fair comparison?
A Vite button? You mean Vue? Vite is just a bundler lol.
Also, would like to see some comparisons to Preact, as that's an (almost) drop-in replacement for React with SUPER small bundles. I'd be impressed if you manage to beat that.
This exact demo will crash with vanilla JavaScript (in Chrome 134.0). This React would also crash — unless the computation relies on WASM
Make a demo with react-virtualized[0] and see if it crashes. Hint: It will not[1]. React can easily render 1 million rows with high performance without relying on WASM [2]
Here is the demo of react-virtualized[3], in which I entered 10m as the row count and scrolled to the bottom without crashing.
[0] https://github.com/bvaughn/react-virtualized
[1] https://www.youtube.com/watch?v=1JoEuJQIJbs
[2] https://medium.com/@priyankadaida/how-to-render-a-million-ro...
[3] https://bvaughn.github.io/react-virtualized/#/components/Lis...
*Update: Here I made a table with 1 million rows with search, filtering, and pagination. In plain Javascript:
https://htmlpreview.github.io/?https://gist.githubuserconten...
Could you give a code example? Also, by crash, do you mean the mentioned stack overflow error?
If so, why would the stack be involved when talking element count?
10 replies →
No. Back when supporting ie 9 we had tables with a million rows and dozens of columns and it runs fine.
>People simply don't care about super optimizations because servers are so fast these days, and bandwidth is cheap, almost free.
Sigh.
[dead]
[dead]