I'm not happy about how bloated most React sites are, and I've mostly stopped using it unless clients specifically request it after years of it being my main framework, but...
> The issue is that these huge frameworks have made the web a horrible slow mess.
I don't think this is accurate. Most bloat in the web is caused by:
a) developers don't taking any time to optimize, lazy load, cache, minimize dependencies...
(This is partly on React, or may be on the culture around React that has made all of this normal and acceptable.)
b) the 300 tracking scripts every site has to try to squeeze as much revenue as possible
(I remember being shocked, some years ago, when I saw a site with 50 trackers. May be it was The Verge? Or some newspaper? Now I don't even bat an eye when the number is in the hundreds.)
React sites can be extremely fast if the developer cares, and the bloat it introduces is rarely relevant. The OP article describes a button as 78K, but that's because it's loading the whole of react for just a button.
If your page has hundreds of buttons, you don't bring 78K hundreds of times, and so complex sites built with React are not that inefficient.
As a Devops engineer, do you have stats on how much of that slowness is the framework or the actual app code?
> a) developers don't taking any time to optimize, lazy load, cache, minimize dependencies...
> (This is partly on React, or may be on the culture around React that has made all of this normal and acceptable.)
Yes, that, too. But you are forgetting that React makes all that opimizing work necessary in the first place.
Networks are fast. Machines are crazy fast. Almost 30 years ago I was doing on-line adaptation of Postscript print files. So some form input and re-rendering the Postscript with the updates from the form values. Basically instantaneous.
> Networks are fast.
Well, it depends on what you mean by “fast”: bandwidth or latency? While the bandwidth has improved enormously over the years, latency… not so much. And it never will due to the simple fact that the speed of light is limited.
Most of the slowness seems to come about by treating latency as something that doesn’t matter (because the testing is done on a local, low-latency network) or will improve radically over time because bandwidth did (which it will not).
Unfortunately, React wants to be both a rendering library and also manage state by tying it to the component lifetime, which encourages cascaded fetching - exactly the kind of workload that is sensitive to latency.
> 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.
His point isn't "network/hardware is fast, so let's be inefficient": it is the opposite. "network/hardware is fast, so why is the page still slow?". On lower powered devices and slower networks, it's even more vital to author lean applications and web pages — but "things are slow even when the hardware and network are fast" is a simple canary that we are swimming through some problems.
1. Even those low-powered Android devices are basically supercomputers
2. The Javascript bloat hurts those devices immensely. See "Performance Inequality Gap 2024" https://infrequently.org/2024/01/performance-inequality-gap-...
How would you spec such a "lower powered" Android device?
Alex Russel did a lot of writing on this and posts yearly updates based on the state of the phone market. You can pick median, P75 or P95 device based on the analysis and set up targets based on that.
https://infrequently.org/2024/01/performance-inequality-gap-...
I did it the simple way and bought a first item in "sort by cheapest" smartphone list. That's Alcatel 1, and it's extremely underpowered. It's maybe a bit overkill, but if something runs on that device, it will run amazing on anything else.
Hmm....that's a cool writeup but not really what I was looking for. Anyway, let's take the phone configuration he mentions:
"The A51 featured eight slow cores (4x2.3 GHz Cortex-A73 and 4x1.7 GHz Cortex-A53) on a 10nm process"
Looking at Wikipedia, it also has at least 4 GB of RAM and comes with 4G Internet.
The Alcatel 1 also seems to have at least a 1 GHz CPU and at least a gigabyte of RAM.
I also had a look at the Samsung Galaxy Watch. Lowest spec I could find was 1 GHz dual core + 768MB RAM (bluetooth), 1.5 GB (LTE).
The machine I was doing the web-based Postscript rendering on was a PowerMac G3. Single core 32 bit processor running at 266 MHz and and with 192MB of RAM. Connection was early DSL, 768 KB down, I think 128 KB up.
I did not do any heroic optimizations, it was fast "as-is".
So I think my point stands that modern computers, including low end Smartphones and watches are incredibly powerful and fast, including the networks.
If your tech stack manages to bring that hardware to its knees for basic UI rendering, and requires a lot of optimization effort to run barely reasonably, then there is something fundamentally wrong with your tech stack.
> If your tech stack manages to bring that hardware to its knees for basic UI rendering, and requires a lot of optimization effort to run barely reasonably, then there is something fundamentally wrong with your tech stack
Yea, I think this is the problem, but the hard part is that it's largely outside of your control on the web. Alcatel 1 is technically a super computer, but it can't even run its own UI properly. I optimize my websites on it and while laggy, they sometimes run faster than Chrome's UI that displays them, it's crazy.
Running the system + the browser is already way too much and there's almost no perf budget left for the website - and it doesn't help that web tech is inherently sub-optimal in many ways, so you're already pessimized on all fronts. Even a baseline a simple page with almost no content is laggy on this device.
> it's largely outside of your control on the web.
On the web or in the JS ecosystem?
While I agree that even just the browsers are monster applications, usually duplicating (at least) the entire OS they are running on, just usually worse.
However, most browsers are perfectly capable of extremely snappy rendering and interactions, even on low-powered devices.
Let's remember that WWW.app was developed on a NeXT Cube, 25 MHz 68040, probably in the 16-64 MB RAM range (min was 8, but I am assuming it was more than the min), and that was plenty snappy.
> a) developers don't taking any time to optimize, lazy load, cache, minimize dependencies... > ... > b) the 300 tracking scripts every site has to try to squeeze as much revenue as possible
Having seen the dynamics up close, I'd say it's far closer to the truth to say that the reason developers don't have time for a) is because they are having to spend all their time on things like b). I've not met a developer who doesn't want to build a better experience. I have met many developers who can't do so, for reasons outside their control.
Characterising it as "if the developer cares" puts the blame in entirely the wrong place.
It's both. The majority of web developers today suck, plain and simple. They thought they could make a lot of money doing web dev and don't approach engineering as an art form or a science. They just scrape by and do not level up on their own outside of or during work.
I've had to come in and rewrite apps before where the developers had full leeway and still produced an unmaintainable behemoth of third-party components loosely taped together.
Also, React is a nightmare. An absolute minefield with zero cohesive vision, with an ever-changing API and a culture of shaming developers who haven't switched to the new React paradigm-of-the-year. For a framework meant for serious adults, I'd check out mithril. It's small, API-stable and intuitive, and gets right out of your way.
> The majority of web developers today suck
Because they are what we called script kiddies back then, copy-pasting from SO and now LLMs.
I do not even know if they would classify as "junior" devs.
This does not apply to ALL web developers, but many.
> React is a nightmare ... culture of shaming developers who haven't switched to the new React paradigm-of-the-year
proceeds to shame and suggests changing to the new paragdigm of the year.
> For a framework meant for serious adults
I have been using mithril for a decade. It isn't the new paradigm of the year. It's been API stable for a long time.
And the sentence you quoted is a dig at React and the React ecosystem, not individual developers.
Nice try, though!
> Also, React is a nightmare.
I think React is a “nightmare” in similar way that JavaScript is a ”nightmare” - it certainly can be, if you abuse it, and it makes it a little too easy to do so.
However, you can take “just the good parts” and ignore the rest. For me, that means using React as a rendering library and managing state almost entirely outside of it.
I've introduced mithril at three different companies to audiences of non-UX engineers and it went well each time, resulting in small, static, API-driven single page applications. For my Software Engineering class, I'm able to get the basics across in a day and let students iterate without having to set up build tools for them. Huge fan.
React seems to be a self-perpetuating ecosystem at this point, and I keep reading about the next framework-of-the-month being tied to a specific vendor or having an uncertain future with funding/bugs/forks.
I'd think it has about 60% cohesive vision, but that's just a ballpark, 0 seems way to low though.
Fair. I'm curious, what do you think are the best-designed and most cohesive parts of React?
The idea of JSX is I think genius.
If I were making a component rendering type library before React I would probably end up making some fake attributes on HTML elements the way Angular and a lot of other people do. It's a pretty simple idea. Pretty much everybody was doing it about the time of Backbone and Angular etc. etc. I'm sure you can think of other examples.
But whoever first came up with JSX said hey, if we're already making non standard HTML why not go all the way, allow you make your own semantic tree that we "render down" to HTML.
This of course allows you in fact separate out the media target - HTML, Native App, PDF, graphics from your renderable representation of that in code, and thus have different renderers for the same declarative way of structuring content.
https://github.com/chentsulin/awesome-react-renderer
So to me JSX is actually a sensible step up in abstraction layer, although not all the way yet, because you still need to have lots of specific knowledge of your particular media rendering target.
This is perhaps of particular interest to me as in about 2004 I was working on a media management system where the idea was you would feed in multiple markup formats, and a configuration for the media, and then use an in house declarative language to dynamically do things in each media, without having to have much understanding of how the media worked internally because our rendering pipeline took care of that - generated pdf, DHTML website (fancy menus), HTML help, and emails - with of course possibility of saving data for reuse in different media and cross media styling (use same company logos, color schemes, email addresses without having to write code for them in each media etc.)
sorry about last part, old programmer wandering.
I would never want to write template files in something other than JSX at this point. Every library that does binding via HTML attributes is a huge step back, as far as I'm concerned.
I'd also say React's one way data binding was a big step forward when it was released. Where it (and TBH, many other SPA frameworks at the time) missed the boat was form handling, which it turns out is like 90% of the Internet and internal applications.
I wouldn't say it's 90% (although my last quibble regarding percentages in this very thread got downvoted to 0) but it is tedious and sort of difficult because of the tediousness, but not sure I have ever seen any solution for forms that made me say, damn I like working with this.
What is truly remarkable about it is that it’s just JavaScript (after some transpilation), which means you can easily use JavaScript’s control structures. Conditional rendering has never been so easy!
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..
If the PM is like that, the dev should eventually learn not to speak up until they're ready to move on to the next thing. To be clear, the PM should listen to the dev.
But the system persists because both people are complicit.
Isn't this one of the main selling points of apps like Balsamiq, you can present something that looks sketch like rather than a completed page.
When starting from scratch: yes. When maintaining a mature application: no, because then you need to keep in sync the app and balsamiq and there is neither the time nor the will for that. And the money.
I'm still designing on paper with crayons (not a joke)
I design with pencils, but I thought crayons would give the PM something to chew on when there is technical discussion.
Are your designs huge ?
One screen per paper I print with special guides. So, I've got various resolution represented. The I just take pictures of the drawings, load them into this webtool and connect them together.
Like a super low budget Balsamiq
I'm kinda digging the idea.
Maybe I'll show HN, it's one of those ideas I have that just feels "too dumb" to be useful outside of my universe.
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.
I would go farther and say it's not even a lack of "optimization", it's a bloat of spaghetti logic that no sane person would ever write, driven by teams that don't talk to each other and are constantly pushed by stakeholders to add more layers instead of cleaning anything up
It has nothing to do with the frameworks. Except maybe that they empowered developers, including the ones cranking out bad code
> developers don't taking any time to optimize, lazy load, cache, minimize dependencies...
I built much more performant apps without lazy loading or caching when using html and a sprinkle of JS.
Exactly. If it's a common enough occurrence that most React SPA's are slow and bloated, it may not be the framework's fault, but if changing to a simpler framework makes it better, then it's just a semantic argument
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.
> the 300 tracking scripts every site has to try to squeeze as much revenue as possible
Just the other day I was appalled by a new record, 1604.
I'm increasingly of the opinion this stuff needs to just be banned outright by law. None of the businesses I've talked to seem to be aware of how dishonest it looks to say "we value your privacy" while trying to get users to agree to get more companies than there were pupils in my secondary school to analyse them.
EU has laws that give back control to users.
But for this to be effective, the browser should be cooperating and working on the user’s behalf to limit tracking. (You know, the whole reason why WWW calls it “user agent” — it should be on the user’s side.)
Unfortunately >90% of browsers use an engine made by the greatest beneficiary of user tracking. Hundreds of billions in future profits might be endangered by giving users actual control. The proverbial fox guarding the hen house.
> the browser should be cooperating and working on the user’s behalf to limit tracking
I hear Microsoft is working on a new browser that gives the user more control over cookies:
1. It shows a confirmation dialog before setting a cookie
2. The site can declare a machine readable policy (P3P) specifying what the cookie will be used for, which the browser uses to automatically decide if the cookie should be permitted.
They plan to call it "Internet Explorer" or something.
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.
Did the page have any ads? Because ads themselves often also contain lots of third-party tools, for fraud detection, the bidding part, tracking, retargetting...
>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.
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.
Nobody trusts anybody else. The site wants to over estimate clicks, the advertiser wants to under estimate. Of course the numbers won’t match up because you lose people along the way. If you have 300 trackers they can’t all be lying to you.
>The site wants to over estimate clicks, the advertiser wants to under estimate
Only if you show the ads. Many companies do not, but still use lots of trackers. Why? Because their performance marketing team is trying to find the right mix of advertisement channels, so they go for paid search and clicks to Google, Meta and lots of other AdTech. In that case trackers are needed to optimize spending by analyzing user behavior. If certain cohort spends more time on the site, they will get more ads of it. If another cohort leaves the site quickly, they will see less ads. The promise of AdTech in general is that they personalize ads as much as possible to reduce your customer acquisition costs (CACs) - you won't waste money on showing ads to people who won't buy your product. So they need the data and they have to own it, because personalization is their competitive advantage.
Arh! That makes a lot more sense. Thank You. Sometimes I do wish I could learn a lot more about online advertising. But it is mostly a forbidden topic on HN.
Yeah, I think both these are true:
1. React is bigger and slower than it needs to be. There are likely better choices today. 2. Most websites will be bigger and slower than they need to be due to the endless September of new devs, and the rarity of being given space to focus on size/performance. As React is popular, it means even if React was tiny and fast, these websites would still be slow.
Why would React be bigger and slower than it needs to be? It's a very mature project with a professional development team behind it, I'm sure we can trust them to tackle whatever unnecessary bloat they may have. I think we should be able to trust that anything that is in there serves a purpose, and that it serves hundreds of niche edge-cases that someone will eventually run into but are non-obvious until it's widely used.
These kinds of statements are only true if you're willing to sacrifice in other areas such as maintainability, security, stability, compatibility, accessibility, extensibility or something similar.
I understand your answer is in good faith, but it still sounds like the same generic answer given when someone questions the engineering quality of any other popular product or service.
The fact is that plenty of teams are mature and professional and yet most software still suffers from bloat, slowness, bugs. Why would React be different?
Preact, for comparison, is only 5kb or so, and has almost 1:1 feature parity. It's not fully drop-in without the compat, and even experienced React devs can nitpick about it, but that's not the point: the mere fact that it exists and gets the job done is enough to raise doubts about the need for React to be quite big.
Does React need to lose weight? Maybe, maybe not. But I don't think it's good to shut down those discussions.
I think the same generic answer _does_ apply to most mature projects. Libraries like these should be approached like discussions about starting over in mature software projects; "this time we'll do it correctly", or "this framework is much simpler". This applies very much to libraries such as these.
When the complexity is low, projects are easy to learn, maintain and handle. That really makes them seem better and have advantages – advantages like a much reduced bundle size. But these new setups just don't do the same thing. It's a shell of what the old project did, as it's missing solutions for hundreds of edge-cases and other requirements that were tackled by the mature many-year old project that is maintained by some of the best developers. I'm sure React has a bit of bloat, but I'm willing to trust the React team that the vast majority of it is there for a reason. It might also be the cost of building on top of a very mature solution.
Would you not shut such a discussion down when someone new in the team proposes a complete rewrite?
Preact does not have 1:1 feature parity, if it had it would have been much more widely used (who wouldn't want a free filesize reduction?). Preact has plenty of issues, which is why it isn't as widely used.
No, I would not shut down discussions. I appreciate new points of view, and I’m fine with being challenged. I would especially not shut down discussions when my assumptions are nothing but a hunch.
> Preact does not have 1:1 feature parity, if it had it would have been much more widely used
Like another poster said, this is a logical error. Preact is fully featured.
Author here. React’s absolutely mature—no question there, with a skilled team behind it. But the button example highlights something off: a single component outweighing an entire app feels fundamentally broken. There’s clear room for fresh alternatives, especially now. You can see it here on HN—seasoned devs wrestling with React’s wild complexity. Nue’s a stab at fixing that.
> a single component outweighing an entire app feels fundamentally broken.
I think this is an overly dramatic take. Of course react has a fixed overhead. If all you're deploying is the single button, then that overhead is for no benefit. But the overhead gets amortized over your entire app, which most likely has thousands of components. This is like a microbenchmark which only measures the static overhead. Not indicative of a real app.
There's an entire cottage industry of "react" but smaller frameworks out there. Somehow, none of them have caught on.
Preact is the one I'd go for if I wanted a smaller react because it's quite mature and it provides the same API.
> a single component outweighing an entire app feels fundamentally broken
It just doesn't to me, understanding that in react-land, a single component and an entire app will have roughly equivalent size, if you're not pulling in any other dependencies.
No one (I hope) would ever use react for a single button, so it feels like an unhelpful comparison.
I don't think that is fundamentally broken. React is just not the right technology for a single button, and it's not trying to be.
If you tried to use photolitography (the technology used to print the circuits in microprocessors) to do tattoos... well it could probably work, but it would be highly inefficient and expensive and bad.
React is for complex web applications, and it I don't think it's a very valid criticism to say that it is bad for a different use case. To some extent, the React community may have over-promoted React as the final web-dev framework, but that's also a mistake.
In any case, kudos on creating Nue, looks really cool, I'll keep an eye on it ;)
Compare React and Preact:
I use Preact often and very, very rarely run into an issue that justifies React being almost 20x the size.
Is it really React or the stuff it lets you bring in? Many React apps have at least one big widget set (say MUI or reactstrap or …) and then a number of “best of breede” components that do various things. It’s rare for components to be styled with plain CSS these days so you probably have to bring in Emotion and styled-components and Tailwind and …. It is all code that goes into the bundle and it’s a burden on your mind because these are all leaky abstractions and don’t absolve you of understanding CSS.
A someone who's been developing for the web for a living since the late 1990s, I agree that nothing absolves the web developer of the need to understand web fundamentals. But laying blame for bloated SPAs at React's feet is misplaced. With SSR, you can ship React apps that work with JS disabled. And with static extraction (a la vanilla-extract) you can do CSS-in-JS with 0 runtime overhead. Being mindful of bundle size and user-perceived performance is essential. For those that pay attention and leverage the web properly as a platform, amazing performance (and capabilities / UX) with React is achievable. See https://Remix.run.
Oh I agree. Was just addressing OP’s argument that surely React is as optimised and small as it can possibly be. I’m personally not convinced.
If Preact truly was as feature complete as React, it would be used by everyone by now – it's old enough for most teams to be aware of it. The fact that it isn't widely used is case in point.
> If Preact truly was as feature complete as React, it would be used by everyone by now
That's a false logical conclusion.
Preact (and others, like Svelte and Solid) are not only "as feature complete as React", they don't need some of the features of React (hooks are unnecessary when you have proper reactivity) and they are better at certain features (like SSR).
People using or not using them has nothing to do with feature completeness.
Fair enough. The quoted statement doesn't hold outside the context of the argument that Preact has feature parity. You can build the same apps with Preact and those others, you just need to sacrifice other things.
Again, there's no such thing as "feature parity" because some (many?) of React features are not required by other frameworks.
E.g. you don't need React hooks because Preact has signals: https://preactjs.com/guide/v10/signals/
Does this mean that Preact doesn't have feature parity? For a very strict definition, no it doesn't. Does it mean you need to sacrifice anything? No.
Same goes for many other frameworks. In modern landscape when it comes to features and abilities React is actually quite a poor offering.
Not really. Developers are as susceptible to marketing as anyone. React is backed by Facebook. Preact is... not.