7 ms·

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 fr

by 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.
- soulofmischief 2y ago
  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.
  - injidup 2y ago
    > 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
    - soulofmischief 2y ago
      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!
    - RUnconcerned 2y ago
      mithril is hardly the new paradigm of the year
  - bryanrasmussen 2y ago
    I'd think it has about 60% cohesive vision, but that's just a ballpark, 0 seems way to low though.
    - soulofmischief 2y ago
andrewingram 2y ago
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.
- MartijnHols 2y ago
  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.
  - tipiirai 2y ago
    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.
    - dhruvrajvanshi 2y ago
      > 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.
cowsandmilk 2y ago
> 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.
- jack_riminton 2y ago
  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
- branko_d 2y ago
  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.
ben_w 2y ago
> 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.
- pavlov 2y ago
  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.
  - CodesInChaos 2y ago
    > 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.
    - deleted 2y ago
      [deleted]
- spockz 2y ago
  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.
mpweiher 2y ago
> 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.
- tmpz22 2y ago
  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.
  - troupo 2y ago
    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-2024/ https://infrequently.org/2024/01/performance-inequality-gap-...
  - HappMacDonald 2y ago
    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.
  - deleted 2y ago
    [deleted]
  - mpweiher 2y ago
    How would you spec such a "lower powered" Android device?
ksec 2y ago
>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.
- ivan_gammel 2y ago
  > 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.
  - PaulHoule 2y ago
    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.
    - ksec 2y ago
      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.
    - ivan_gammel 2y ago
      >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.

by ikurei 2y ago

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.

soulofmischief 2y ago
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.
- injidup 2y ago
  > 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
  - soulofmischief 2y ago
    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!
  - RUnconcerned 2y ago
    mithril is hardly the new paradigm of the year
- bryanrasmussen 2y ago
  I'd think it has about 60% cohesive vision, but that's just a ballpark, 0 seems way to low though.
  - soulofmischief 2y ago

andrewingram 2y ago

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.

MartijnHols 2y ago
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.
- tipiirai 2y ago
  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.
  - dhruvrajvanshi 2y ago
    > 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.

cowsandmilk 2y ago

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

jack_riminton 2y ago
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
branko_d 2y ago
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.

ben_w 2y ago

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

pavlov 2y ago
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.
- CodesInChaos 2y ago
  > 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.
  - deleted 2y ago
    [deleted]
spockz 2y ago
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.

mpweiher 2y ago

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

tmpz22 2y ago
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.
- troupo 2y ago
  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-2024/ https://infrequently.org/2024/01/performance-inequality-gap-...
- HappMacDonald 2y ago
  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.
- deleted 2y ago
  [deleted]
- mpweiher 2y ago
  How would you spec such a "lower powered" Android device?

ksec 2y ago

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

ivan_gammel 2y ago
> 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.
- PaulHoule 2y ago
  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.
  - ksec 2y ago
    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.
  - ivan_gammel 2y ago
    >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.