18 ms·

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 is

by fcpk 2y ago

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.

martinsnow 2y ago
Rarely is that a problem with react itself. Poorly written applications exist in every flavor of language, framework and library.
- mentalgear 2y ago
  Some frameworks though make it easy to fall into a good default, and others don't.
  - jack_riminton 2y ago
    Yep, the more complex an app can be, the more complex the app will be
jeffhuys 2y ago
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.
- _Algernon_ 2y ago
  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.
  - jeffhuys 2y ago
    Well, the post I replied to said "on a 10G connection peered within 5ms of the host" so I think it's fair to assume they also were in a sterile environment. I'm even on a lower connection with 20ms+ ping!
  - YetAnotherNick 2y ago
    5 year old mobile isn't as slow as you make it out to be. Cheap 2025 phones is significantly slower than my 8 years old iPad. Also 3G could be fast and it isn't the protocol that makes the speed to <1Mbps.
    - PaulHoule 2y ago
      Could be a desktop PC with 25/3 ADSL where somebody is streaming Netflix and a game console is updating itself.
  - docmars 2y ago
    The thing is, enterprise web applications are not built for phones. This would be like telling someone to run the latest Ubisoft game on a PC from 2-3 generations ago, and expecting it to perform well. Today's applications are more complex than ever, bloated perhaps, but the demand for features, complex visualizations, etc. rise with the patterns of seeing them more in other applications.
    - lolinder 2y ago
      This. So many people—both on the dev side and the annoyed HN commenter side—act as though all websites have the same requirements. They don't. The usage profile varies enormously, and if you treat every website as just a website without considering the context it's used in you're going to either waste a lot of time optimizing things that don't matter or you're going to make your app suck by not adjusting properly for your users.
throwaway290 2y ago
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
- tipiirai 2y ago
  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
  - throwaway290 2y ago
    Cool, good luck! Building on top of Web standards is definitely a great idea and your (non-Rust) demo is pretty good. If I wanted to build a static webapp and was in the mood to play with something new I might try it.
  - troupo 2y ago
    So far this "re-thinking" is just dumping loads of innerHtml's and trashing the entire DOM. The only reason it's fast is because browsers have been optimized beyond any sane reason. E.g. your table demo removes and re-adds all rows on every button press. This is not re-thinking. This is throwing all we've learned out of the window and starting from scratch.
    - tipiirai 2y ago
      Nue JS reactive library is based DOM diffing. The next version also has keyed rows.
ellinoora 2y ago
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.
zero_shift 2y ago
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
ikurei 2y ago
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?
- brundolf 2y ago
  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
- regularfry 2y ago
  > 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.
mapcars 2y ago
> 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.
bambax 2y ago
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.
- selfmodruntime 2y ago
  > 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.
  - TickleSteve 2y ago
    Pure JS is that interface... you're arguing for multiple unnecessary abstraction layers piled on top of each other. More abstraction != easier to use.
    - tipiirai 2y ago
      Spot on. HTML, JS, and CSS deliver a clean separation of concerns—a perfect blank slate for killer products. You just need a few key pieces to tie it all together: templating with loops for repeating HTML chunks and a way to stitch in headers, footers, or sidebars. For apps, a routing system is a must. And HMR to supercharge your dev workflow. That’s Nue in a nutshell.
      - troupo 2y ago
        > HTML, JS, and CSS deliver a clean separation of concerns There's nothing clean about this separation, and concerns are never as neatly separated as people pretend they are. > For apps, For apps you need actual app-like things where your separation of concerns looks like the right image here: https://x.com/simonswiss/status/1664736786671869952 https://x.com/simonswiss/status/1664736786671869952
selfmodruntime 2y ago
> 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.
geocar 2y ago
> 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.
- zwnow 2y ago
  Well most stuff going wrong in apps is actually managements fault. At least in my experience. Either directly or hidden in their decision making.
nsonha 2y ago
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.
andai 2y ago
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)?
- johneth 2y ago
  > 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?)
  - timando 2y ago
    Some way to simulate a slow CPU
    - Klaster_1 2y ago
      Chrome DevTools have that too.
- thunderfork 2y ago
  [dead]
robertlagrant 2y ago
> 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.
- PaulHoule 2y ago
  "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/ 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.
  - robertlagrant 2y ago
    > I always find it a little nervewracking for a JS application to have state in React state variables and any other kind of state. Some ImGUI frameworks have components that look superficially like React components but are fast enough to animate every frame, which makes me feel like I am in control and get the animation to look exactly what I want I know what you mean there. I had the same feeling back when I was doing frontend things.
maxloh 2y ago
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.
- tipiirai 2y ago
  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!
  - girvo 2y ago
    > Nue’s model-first approach keeps things clean and scalable Like I understand why you say this, but as someone who spent the 2000s building "model first" web apps (and desktop applications), I don't miss it in the slightest. Immediate mode-esque render loops didn't catch on just because it's a fad, it really does fit a lot of highly interactive things better. Of course the bigger problem is people using something that's great for heavily interactive web applications for building things that _don't need_ that interactivity... Nue looks great, and I think it stands on it's own two feet. The constant React bashing just turns me off it more than anything (and that's not about React specifically, I have no real love for it, just that kind of project marketing isn't my cup of tea)
    - deleted 2y ago
      [deleted]
sensanaty 2y ago
> 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.
- deleted 2y ago
  [deleted]
SebastianKra 2y ago
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.
oefrha 2y ago
The bloat isn't coming from "huge frameworks" like React. To give some concrete numbers: a barebones react project created with `pnpm create vite -t react-ts` clocks in at ~60KB compressed: dist/index.html 0.46 kB │ gzip: 0.30 kB dist/assets/react-CHdo91hT.svg 4.13 kB │ gzip: 2.14 kB dist/assets/index-D8b4DHJx.css 1.39 kB │ gzip: 0.71 kB dist/assets/index-9_sxcfan.js 188.05 kB │ gzip: 59.16 kB A vue project (`pnpm create vite -t vue-ts`) is even smaller at ~25KB: dist/index.html 0.46 kB │ gzip: 0.30 kB dist/assets/index-1byZ3dr3.css 1.27 kB │ gzip: 0.65 kB dist/assets/index-CKXNvRRZ.js 60.77 kB │ gzip: 24.44 kB 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.
- tipiirai 2y ago
  Author here: Fair point—React’s baseline isn’t a monster. ~60KB compressed for a barebones Vite/React setup, or even ~25KB with Vue. Medium projects at 200-300KB are definitely workable. But here’s the point: a single React/ShadCN button, straight from their official docs, still outweighs Nue’s entire SPA demo. Add more widgets—tabs, modals, whatever—and that gap only widens. Nue is flipping the script. Web standards let us start lean and stay lean—smaller codebases, faster HMR, quicker builds. That’s the win: efficiency that scales without piling complexity.
  - oefrha 2y ago
    An extra 100-200KB compressed is a ~100ms one time cost once in a while for the majority of my users, and ~1s for 95%+ of users. At that point I'm going to optimize for developer productivity (which includes breadth of ecosystem). I can be both productive and respectful to my users with these common frameworks. Note that I'm very mindful of web performance, and I've been quite vocal on this site about some alarming trends like calling for the end of bundling (native esm) and roundtrips for everything (liveview and co., or at least the abuse of them). In my experience waterfalls and roundtrips are the number one thing hated by people on slow and/or unreliable networks; 100KB added to a flat bundle at load is almost nothing.
maelito 2y ago
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.
rdsubhas 2y ago
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.
docmars 2y ago
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.
lern_too_spel 2y ago
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.
nine_k 2y ago
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.)
- recursivedoubts 2y ago
  We also created fixi, which is sort of preact to htmx’s react: https://github.com/bigskysoftware/fixi https://github.com/bigskysoftware/fixi a goal of fixi is to be smaller uncompressed than preact is compressed, to force us to be minimalist
  - nine_k 2y ago
    This is really nice and simple. I wonder how would the Web develop if something like this appeared in 1997 along with DHTML.
sheepscreek 2y ago
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.
- scsh 2y ago
  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."
chidam333 2y ago
[dead]
CyberDildonics 2y ago
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.
CodeCrusader 2y ago
I think with necessary effort websites with most of the frameworks could be loaded quite fast (with some obviously it is easier), the thing is it's rarely the priority compared to the business needs that are getting addressed.

by fcpk 2y ago

martinsnow 2y ago

Rarely is that a problem with react itself. Poorly written applications exist in every flavor of language, framework and library.

mentalgear 2y ago
Some frameworks though make it easy to fall into a good default, and others don't.
- jack_riminton 2y ago
  Yep, the more complex an app can be, the more complex the app will be

jeffhuys 2y ago

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.

_Algernon_ 2y ago
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.
- jeffhuys 2y ago
  Well, the post I replied to said "on a 10G connection peered within 5ms of the host" so I think it's fair to assume they also were in a sterile environment. I'm even on a lower connection with 20ms+ ping!
- YetAnotherNick 2y ago
  5 year old mobile isn't as slow as you make it out to be. Cheap 2025 phones is significantly slower than my 8 years old iPad. Also 3G could be fast and it isn't the protocol that makes the speed to <1Mbps.
  - PaulHoule 2y ago
    Could be a desktop PC with 25/3 ADSL where somebody is streaming Netflix and a game console is updating itself.
- docmars 2y ago
  The thing is, enterprise web applications are not built for phones. This would be like telling someone to run the latest Ubisoft game on a PC from 2-3 generations ago, and expecting it to perform well. Today's applications are more complex than ever, bloated perhaps, but the demand for features, complex visualizations, etc. rise with the patterns of seeing them more in other applications.
  - lolinder 2y ago
    This. So many people—both on the dev side and the annoyed HN commenter side—act as though all websites have the same requirements. They don't. The usage profile varies enormously, and if you treat every website as just a website without considering the context it's used in you're going to either waste a lot of time optimizing things that don't matter or you're going to make your app suck by not adjusting properly for your users.

throwaway290 2y ago

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

tipiirai 2y ago
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
- throwaway290 2y ago
  Cool, good luck! Building on top of Web standards is definitely a great idea and your (non-Rust) demo is pretty good. If I wanted to build a static webapp and was in the mood to play with something new I might try it.
- troupo 2y ago
  So far this "re-thinking" is just dumping loads of innerHtml's and trashing the entire DOM. The only reason it's fast is because browsers have been optimized beyond any sane reason. E.g. your table demo removes and re-adds all rows on every button press. This is not re-thinking. This is throwing all we've learned out of the window and starting from scratch.
  - tipiirai 2y ago
    Nue JS reactive library is based DOM diffing. The next version also has keyed rows.

ellinoora 2y ago

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.

zero_shift 2y ago

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

ikurei 2y ago

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?

brundolf 2y ago
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
regularfry 2y ago
> 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.

mapcars 2y ago

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

bambax 2y ago

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.

selfmodruntime 2y ago
> 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.
- TickleSteve 2y ago
  Pure JS is that interface... you're arguing for multiple unnecessary abstraction layers piled on top of each other. More abstraction != easier to use.
  - tipiirai 2y ago
    Spot on. HTML, JS, and CSS deliver a clean separation of concerns—a perfect blank slate for killer products. You just need a few key pieces to tie it all together: templating with loops for repeating HTML chunks and a way to stitch in headers, footers, or sidebars. For apps, a routing system is a must. And HMR to supercharge your dev workflow. That’s Nue in a nutshell.
    - troupo 2y ago
      > HTML, JS, and CSS deliver a clean separation of concerns There's nothing clean about this separation, and concerns are never as neatly separated as people pretend they are. > For apps, For apps you need actual app-like things where your separation of concerns looks like the right image here: https://x.com/simonswiss/status/1664736786671869952 https://x.com/simonswiss/status/1664736786671869952

selfmodruntime 2y ago

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

geocar 2y ago

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

zwnow 2y ago
Well most stuff going wrong in apps is actually managements fault. At least in my experience. Either directly or hidden in their decision making.

nsonha 2y ago

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.

andai 2y ago

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

johneth 2y ago
> 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?)
- timando 2y ago
  Some way to simulate a slow CPU
  - Klaster_1 2y ago
    Chrome DevTools have that too.
thunderfork 2y ago
[dead]

robertlagrant 2y ago

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

PaulHoule 2y ago
"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/ 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.
- robertlagrant 2y ago
  > I always find it a little nervewracking for a JS application to have state in React state variables and any other kind of state. Some ImGUI frameworks have components that look superficially like React components but are fast enough to animate every frame, which makes me feel like I am in control and get the animation to look exactly what I want I know what you mean there. I had the same feeling back when I was doing frontend things.

maxloh 2y ago

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.

tipiirai 2y ago
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!
- girvo 2y ago
  > Nue’s model-first approach keeps things clean and scalable Like I understand why you say this, but as someone who spent the 2000s building "model first" web apps (and desktop applications), I don't miss it in the slightest. Immediate mode-esque render loops didn't catch on just because it's a fad, it really does fit a lot of highly interactive things better. Of course the bigger problem is people using something that's great for heavily interactive web applications for building things that _don't need_ that interactivity... Nue looks great, and I think it stands on it's own two feet. The constant React bashing just turns me off it more than anything (and that's not about React specifically, I have no real love for it, just that kind of project marketing isn't my cup of tea)
  - deleted 2y ago
    [deleted]

sensanaty 2y ago

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

deleted 2y ago
[deleted]

SebastianKra 2y ago

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.

oefrha 2y ago

The bloat isn't coming from "huge frameworks" like React. To give some concrete numbers: a barebones react project created with `pnpm create vite -t react-ts` clocks in at ~60KB compressed: dist/index.html 0.46 kB │ gzip: 0.30 kB dist/assets/react-CHdo91hT.svg 4.13 kB │ gzip: 2.14 kB dist/assets/index-D8b4DHJx.css 1.39 kB │ gzip: 0.71 kB dist/assets/index-9_sxcfan.js 188.05 kB │ gzip: 59.16 kB A vue project (`pnpm create vite -t vue-ts`) is even smaller at ~25KB: dist/index.html 0.46 kB │ gzip: 0.30 kB dist/assets/index-1byZ3dr3.css 1.27 kB │ gzip: 0.65 kB dist/assets/index-CKXNvRRZ.js 60.77 kB │ gzip: 24.44 kB 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.

tipiirai 2y ago
Author here: Fair point—React’s baseline isn’t a monster. ~60KB compressed for a barebones Vite/React setup, or even ~25KB with Vue. Medium projects at 200-300KB are definitely workable. But here’s the point: a single React/ShadCN button, straight from their official docs, still outweighs Nue’s entire SPA demo. Add more widgets—tabs, modals, whatever—and that gap only widens. Nue is flipping the script. Web standards let us start lean and stay lean—smaller codebases, faster HMR, quicker builds. That’s the win: efficiency that scales without piling complexity.
- oefrha 2y ago
  An extra 100-200KB compressed is a ~100ms one time cost once in a while for the majority of my users, and ~1s for 95%+ of users. At that point I'm going to optimize for developer productivity (which includes breadth of ecosystem). I can be both productive and respectful to my users with these common frameworks. Note that I'm very mindful of web performance, and I've been quite vocal on this site about some alarming trends like calling for the end of bundling (native esm) and roundtrips for everything (liveview and co., or at least the abuse of them). In my experience waterfalls and roundtrips are the number one thing hated by people on slow and/or unreliable networks; 100KB added to a flat bundle at load is almost nothing.

maelito 2y ago

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.

rdsubhas 2y ago

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.

docmars 2y ago

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.

lern_too_spel 2y ago

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.

nine_k 2y ago

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

recursivedoubts 2y ago
We also created fixi, which is sort of preact to htmx’s react: https://github.com/bigskysoftware/fixi https://github.com/bigskysoftware/fixi a goal of fixi is to be smaller uncompressed than preact is compressed, to force us to be minimalist
- nine_k 2y ago
  This is really nice and simple. I wonder how would the Web develop if something like this appeared in 1997 along with DHTML.

sheepscreek 2y ago

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.

scsh 2y ago
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."

chidam333 2y ago

[dead]

CyberDildonics 2y ago

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.

CodeCrusader 2y ago

I think with necessary effort websites with most of the frameworks could be loaded quite fast (with some obviously it is easier), the thing is it's rarely the priority compared to the business needs that are getting addressed.