Comment by fcpk

> a single React/ShadCN button

So don't use ShadCN? It's so weird to put up this strawman app and then be like "see what's wrong with React"? Like showing two boards nailed together and being like "can you believe I needed all those power tools just to do this?"

> Add more widgets—tabs, modals, whatever—and that gap only widens

This is the benchmark I want to see. Two full-featured apps built with minimal prod dependencies. There's a pretty good chance that the various ShadCN modules share many of their dependencies so that importing more doesn't necessarily mean a linear increase in bundle size. It could be that once you build something full-featured, React projects come in smaller, or at least not big enough to invalidate the other upsides of choosing it.

An extra 100-200KB compressed is a ~100ms one time cost once in a while for the majority of my users, and ~1s for 95%+ of users. At that point I'm going to optimize for developer productivity (which includes breadth of ecosystem). I can be both productive and respectful to my users with these common frameworks.

Note that I'm very mindful of web performance, and I've been quite vocal on this site about some alarming trends like calling for the end of bundling (native esm) and roundtrips for everything (liveview and co., or at least the abuse of them). In my experience waterfalls and roundtrips are the number one thing hated by people on slow and/or unreliable networks; 100KB added to a flat bundle at load is almost nothing.

How much is it React/Nue and how much is everything else?

HTML has evolved in the last 15 years to be a platform for applications. The early Bootstrap was a terrible Rube Goldberg machine because CSS didn't have civilized layout mechanisms such as grid and flexbox. Newer frameworks like Tailwind are more sensible, but still add 50k to your bundle, and if your app is complex and developed under deadlines you probably have components that use Tailwind and Bootstrap and emotion and styled-components and raw CSS and you still have to write some SCSS to get the styles just right in the end.

I've been investigating the accessibility of various <Modal> components and found that they all suck because they do complicated things with <Portal>(s) and various-aria-attributes. HTML has had a <dialog> component that properly hides the rest of the page since 2022 but barely anyone was using it.

If you stuck to using Tailwind or Bootstrap or raw CSS and used a minimal widget set you can make small applications with any framework. If you wrote raw CSS and made the most of the widgets that come in HTML5 (like the new stylable <select>) you can make tiny applications.

> React’s baseline isn’t a monster.

Yes it is. It’s not size, it’s logic: Every time the component rerenders, the root loop is executed. Why? The root loop reassigns every useEffect, reruns every useState, every other hook (and useSearchParams is executed n times for n components that need it in the hierarchy) when only the HTML needs rerender.

(Yes the programmer can optimize/memoize, and yes “a hook’s execution time is very short” (but multiplied by every cell in the table, when needed)). Must be the fault of the programmer if the framework has a super-intensive concept at the root.)

I think Nue just puts you in the mindset of trying to keep the codebase as small and lightweight as possible. I wanted to rebuild my website with Nue and there was something telling me to avoid Motion, Tailwind CSS, etc. This philosophy can actually prove very helpful in the long term, however I feel that by using Nue you're really compromising on DX (development is much slower), although that might be because I'm not so familiar with creating websites without a framework. In any case, it's definitely worth a try.

this means the example wasn't made to be lightweight. You'll need an apples to apples example to convince any detractor. Implement the same app using two different toolsets, document the process with each and then benchmark it

To be honest, I am very confused with this benchmark. It is misleading.

What is the actually size of the production build portion only for that button part? Because I think that the ShadCN button source code is not equal in size for the button that client downloads in production environment. Especially if you have SSR.

[flagged]

This sounds like ChatGPT’s voice :)

absolutely. page performance is the result of a hairball of initial asset loads, AJAX calls, ad-hoc roundtrips, telemetry bloat, ...

It's so convoluted, and very app specific. Core web vitals provide the right framework to think about what is relevant, but in reality your app likely requires dedicated instrumentation to capture these phases accurately.

I test my damn sites on a fucking iPhone 6 from 2014. Executing that JS is a breeze.

React etc. runs just fine on absolute garbage kiosks. If you introduce 10MB of additional JS on top of 60KB of React, it's those 10MB's fault.

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

before React took over, "SPAs" were written with jQuery and Bootstrap, and it was common to see a project with multiple copies of different versions of jQuery. Totally possible to bloat a website without a framework. just go old school!

> Networks are fast.

Well, it depends on what you mean by “fast”: bandwidth or latency? While the bandwidth has improved enormously over the years, latency… not so much. And it never will due to the simple fact that the speed of light is limited.

Most of the slowness seems to come about by treating latency as something that doesn’t matter (because the testing is done on a local, low-latency network) or will improve radically over time because bandwidth did (which it will not).

Unfortunately, React wants to be both a rendering library and also manage state by tying it to the component lifetime, which encourages cascaded fetching - exactly the kind of workload that is sensitive to latency.

> Yes, that, too. But you are forgetting that React makes all that opimizing work necessary in the first place.

Isn't the runtime state optimization the only responsibility of React. It's a library. The rest goes for Vite, Deno et al.

Low powered android devices are a thing. Networks outside of Metro US, EU, and parts of Asia, are also a thing.

Check out google maps there’s more to the world than your open office.

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

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

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

I've seen this happen many times:

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

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

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

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

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

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

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

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

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

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

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

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

We didn’t do lazy loading or caching either.

EU has laws that give back control to users.

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

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

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

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

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

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

> why cant we have ONE scripts to rule them all

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

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

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

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

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

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

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

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

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

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

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

> but worse in every conceivable way

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

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

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

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

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

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

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

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

More abstraction != easier to use.

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

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

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

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

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

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

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

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

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

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

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

Some way to simulate a slow CPU

Yep, the more complex an app can be, the more complex the app will be

So far this "re-thinking" is just dumping loads of innerHtml's and trashing the entire DOM.

The only reason it's fast is because browsers have been optimized beyond any sane reason.

E.g. your table demo removes and re-adds all rows on every button press. This is not re-thinking. This is throwing all we've learned out of the window and starting from scratch.

Cool, good luck! Building on top of Web standards is definitely a great idea and your (non-Rust) demo is pretty good. If I wanted to build a static webapp and was in the mood to play with something new I might try it.

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

This is really nice and simple.

I wonder how would the Web develop if something like this appeared in 1997 along with DHTML.