8 ms·

> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. I disagree. Try loading up a library heavy site

> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve parsing a giant lump of JSON before you can do anything, that’s particularly CPU intensive and takes time on low end devices. > Yes, there are a few specialized domains where this will matter. No, you probably don’t work in one. Again: I beg to differ. Anyone hoping that their site will rank well on Google needs to factor in site performance via core web vitals. Time and time again I’ve seen React-based sites perform horribly and it’s very difficult to dig your way out of the hole after the fact. I actually think most of the problem isn’t React itself, it’s the ecosystem and the philosophy that surrounds it so often. You’ll have React, you’ll have some extra state management library on top, you’ll have some hideous CSS in JS bulk on top because no one wants to actually learn CSS… it’s all prioritisation of developer experience over user experience. And it’s industry standard these days.

satvikpendem 2y ago
With React Server Components, you can have your cake and eat it too, by sending only the necessary HTML to the browser (thereby having good performance and SEO) but also hydrating with more interactivity if necessary. And I'm not sure where you think CSS in JS means you don't learn CSS, I'm not sure how you'd use it otherwise... Either way, there are CSS in JS (TypeScript) libraries that compile down to regular CSS classes, like PandaCSS, so again, you can have your cake and eat it too.
- afavour 2y ago
  React Server Components strikes me as React solving a React-caused problem with yet more React. Which is fine, I guess, if you’re already locked into the React ecosystem. But as someone that isn’t, looking at the whole proposition from the outside, it just screams vendor lock-in to me. There are too many devs out there only expert in the way React does things and can’t step outside of it. RSC is an additional crutch that allows this to continue but that doesn’t mean it’s healthy. My main contention with the OP’s point was the assertion that React is almost always the right answer. One of my biggest bugbears about any web dev discussion (particularly on HN) is that everyone treats it as a one size fits all argument and it isn’t. If you’re making a webapp with interactivity levels like Gmail has then React is a sensible choice. The page reloads very irregularly. But if you’re making something like a blog with lots of drive by visits and only small islands of reactive content IMO it’s the wrong choice.
  - thrw42A8N 2y ago
    The original problem was caused by PHP (see XHP) and this is just bringing the solution to full feature parity.
  - satvikpendem 2y ago
    Perhaps it is vendor lock in, but the concept as a whole is not that difficult to generalize, as other frontend frameworks have their own sorts of implementations of the concept. Phoenix in the Elixir world has LiveView, for example. It's just that React's is more seamless, especially with TypeScript, as you can run JS (TypeScript) on both the client and server, so that you have greater control over exactly which components you want to be on the client versus the server without having to do so manually if you were to use something like Rails or Django. Therefore, even if you are making something like blogs, you can still use React as essentially a templating language via JSX and also use React for interactivity, for example a comment form component.
  - switz 2y ago
    > React Server Components strikes me as React solving a React-caused problem with yet more React. This is not the case. RSC solves the hydration problem, in which hydration is profoundly expensive (larger bundle sizes, more client JS to parse and execute, and slower time to interactive), when most of the UI on any website can be non-hydrated. This also gives you the ability to write server only code (which as it would turn out, reduces sending third party deps to the client even more) for free with beautiful composability to client side hydration when you need it. Everyone hydrates at some point. Maybe you write isomorphic javascript or maybe you render a rails or python app and sprinkle in some JS. RSC enables you to do this with complete composition and re-usability. I'll put my money where my mouth is: RSC will continue to grow in adoption and its patterns will be adopted across many UI frameworks and libraries. This wasn't a solution in search of a problem, this was a large step forward in giving us more optionality as to how we architect websites. > There are too many devs out there only expert in the way React does things and can’t step outside of it. This is a weird ad hominem, attacking developers' skill instead of the actual technology. There are millions upon millions of React developers, and many of us have been building successful software for a long time and step outside of React every day. > But if you’re making something like a blog with lots of drive by visits and only small islands of reactive content IMO it’s the wrong choice. For some use-cases it is not the best choice, and for others it's the correct one. No one is hailing React as a one-size-fits-all solution, rather it remains a great balance that scales remarkably well to many needs.
- hmeh 2y ago
  You literally cannot. You can bake two cakes. You can’t have your cake and eat it too. Server and client rendering? You must concern yourself with both. The best frameworks will not perfect abstract this for you. They can’t, it’s leaky. When the cracks show, it will be painful. CSS-in-JS? I’ve used it and fought for it. Have you ever looked at the css output? That’s not a cake I’d want to eat. Compare it to a codebase with a well architected set of css and the markup and css actually do work for you. They are clarifying and reinforce structure. There are levels of productivity you gain based solely on things being clear and not convoluted that many people in our industry cannot recognize because they are fixated on the wrong thing. Whether that be what other people are using, or what gives dopamine hits (hot reloading, cool tech, etc)
  - satvikpendem 2y ago
    > You literally cannot. You can bake two cakes. You can’t have your cake and eat it too. It is a common saying, not to be taken "literally." > The best frameworks will not perfect abstract this for you. They can’t, it’s leaky. When the cracks show, it will be painful. Better than before with pure server side solutions like Rails or Django, however. I use RSCs and they work just fine, because you are using TypeScript on both the client and the server, meaning there are greater abstractions that can be leveraged. > Have you ever looked at the css output? Not sure what CSS in JS library you used but with something like Typestyle or PandaCSS, you write CSS but in JS objects, so the generated CSS is simply turning those objects into the CSS you already wrote, not sure why it would be any different.
    - hmeh 2y ago
      I know what analogies are. I was extending yours. I was just saying that there are tradeoffs. You don’t think there are, and that’s fine. I can see them and I make my choices accordingly.
      - satvikpendem 2y ago
        I never said there weren't tradeoffs, just that RSCs enable greater functionality than before, such that one can "have their cake and eat it too," but it's not meant to mean that there are only two cakes in this entire analogical universe. Other frameworks (ie, cakes) have their own tradeoffs.
michaelcampbell 2y ago
Reacting to assertions of broad averages with specific counter examples doesn't necessarily invalidate their point.
- afavour 2y ago
  OK, let me restate something from my previous component explicitly: a site that’s concerned with SEO is not a “specialized domain”. It is very, very common.
  - Scarblac 2y ago
    So are web applications that are completely behind auth and never need to care about SEO. They're quite different and it's a shame they're usually mixed up in these discussions.
  - wokwokwok 2y ago
    Many sites have a two tier application with a CMS SEO “landing page” abd conversion funnel run by the marketing department and a user-login that takes you to a separate website that is SEO irrelevant. So… a site that doesnt care about SEO and is not indexed and is purely for logged in users is also very common.
    - afavour 2y ago
      I don’t really understand the disagreement here. I didn’t claim those sites are rare. I was specifically refuting the OPs claim that page load time only matters in a small number of specialized domains. I am saying it is very common for it to matter. It’s also very common for it to not matter, you’ll get no argument from me there.
ls_stats 2y ago
>Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. that was the case in 2015 when entry level android devices were quite slow, nowdays a cheap $200 android phone has at least 4-6GB of RAM and an eight core processor. if that isn't enough for your react powered site, you are doing something very wrong.
- Mordisquitos 2y ago
  The performance of client-side web applications asymptotically approaches load times of "at most a few hundred milliseconds" on the high end phone models owned by developers.
- martinald 2y ago
  Keep in mind that React is very single threaded (as is nearly everything in javascript). These phones might have 8 cores; but they tend to have the same single thread performance as 10+ year old iPhones.
  - gf000 2y ago
    That assumes that the bottleneck is JS parsing/execution. The browser itself is not single-threaded and can load/parse resources in parallel. And I don't buy that most websites would have react as the bottleneck, over the million other js libs, ads and tracking.
    - mh- 2y ago
      No one is asking you to buy it, there is tons of empirical data you can analyze for yourself.
- slotrans 2y ago
  Multiple times daily I encounter sites that are brutally slow not just on my beefy Android phone, but on my 3GHz+ 8-core 64GB desktop machine. You need to take performance seriously or it will just be bad. Most of the industry has chosen to be bad.
johnfn 2y ago
> I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve parsing a giant lump of JSON before you can do anything, that’s particularly CPU intensive and takes time on low-end devices. The entire site may take multiple seconds to load, sure, but it's quite rare that this is a React issue. Typically, the real issue is something like the website making a bunch of API requests in serial rather than parallel. For instance, the issue of JSON parsing that you cited is actually an SSR issue; that's entirely orthogonal to React, and you can make the same error in any other popular web framework. > I actually think most of the problem isn’t React itself, it’s the ecosystem and the philosophy that surrounds it so often. You’ll have React, you’ll have some extra state management library on top, you’ll have some hideous CSS in JS bulk on top because no one wants to actually learn CSS… it’s all prioritisation of developer experience over user experience. And it’s industry standard these days. I think you're saying "React is slow" when you mean to say "the entire frontend ecosystem is slow". To which I respond... sure? None of this is React-specific. If you don't use React, you'll still have to use state management (or manage it yourself; have fun!), figure out something to do with CSS, etc, etc.
- leptons 2y ago
  API requests at page-load are definitely going to lower the page speed score. No API requests should happen at all, ideally, and all script and CSS to render everything "above the fold" should be loaded in-line. Nothing that is visible "below the fold" should ever run or load until the page is scrolled down by the site visitor. Only the bare-minimum script parsing that is required for the content "above the fold" should happen. Sure you can load scripts in-line for stuff below the fold, but make sure it doesn't actually get parsed by the browser until that feature is likely to be visible on the screen. It doesn't matter what library or framework is used - even jQuery can score 100% page speeds on Google Lighthouse. It really only depends on following every single nitpicky thing that Google Lighthouse recommends, and finding a solution for it. I took a site (actually a few thousand sites) that was scoring about 5 to 35 out of 100 on Google Lighthouse (depending on the customiztions), up to 100/100 on Google Lighthouse. It took a lot of work, but the clients are happy now. Where React doesn't do well is with lots of DOM elements. In another project I created a complex web application that had about 3000 div elements with drag-and-drop interface and all kinds of stuff going on. Well React couldn't handle it. The browser started crashing due to memory issues if the page was open longer than 20 minutes or so, it slowed to a crawl and eventually froze. I ended up switching that one component to a canvas based solution (Konva) and it solved the problem completely. I still use React for all the other simple UI stuff, but I learned my lesson about what React is really good at and what it's not.
lolinder 2y ago
These disagreements almost always boil down to one side saying "some people use React to build content-oriented websites" and the other side saying "but most of us are building web applications". In a typical web application use case (yes, there are exceptions) you're only rarely looking at usage from old or cheap Android devices. Occasionally you'll see a tablet, but even that's rare. The vast majority of the time your users are on either Chrome or Safari on a relatively modern Mac or Windows machine. In many cases the application loads once at the start of at least 10+ minutes of work, so initial load times rarely matter much. If you're building a website that needs SEO, then yeah, React is completely the wrong tool, and you should just make a proper static site or hook your marketing team up with WordPress (or whatever takes its place once Matt is finished blowing it up). But those use cases, while common, represent a tiny fraction of total engineering effort across the industry, so most web developers here don't have the design constraints that make React a bad choice.
- xcrunner529 2y ago
  The top sites using react are all e-commerce or social sites. I would bet the majority of react sites and devs that use them are not building apps that require SPA or something like React. Which is the problem.
  - lolinder 2y ago
    > I would bet the majority of react sites and devs that use them are [n]ot building apps that require SPA or something like React. [edited to restore what I assume is the ended meaning] On what basis do you bet this, though? Sure, you see sites that bug you by being slow in contexts where you'd choose something else, but most devs are working on sites and apps that you will never see, because you're not the target demographic. I don't have survey data one way or the other, but anecdotally everywhere I've worked on an SPA has been a clear case where trying to do it in backend+JQuery would have been a huge failure.
    - ysavir 2y ago
      But there is a wide gulf between backend + JQuery and SPA. The frustration often shown is people treating the extremes as the only options available. Having a use case for which backend + jQuery doesn't cut it doesn't require reinventing navigation state and history in JS, or loading every stat on the page via JSON. There are middle grounds.
xcrunner529 2y ago
It’s just embarrassing any image scrolling site will eventually just eat all the memory and crash and you lose your place. Used to kill me back in the Tumblr days and React perpetuates it.
- deleted 2y ago
  [deleted]
- ZYbCRq22HbJ2y7 2y ago
  That is an implementation issue, not a framework issue. There are plenty of easy to use virtual scrolling libraries for React and vanilla JS. There is also `content-visibility` with CSS Containment now.
  - xcrunner529 2y ago
    I’d love to see how those new options perform these days by replicating a large tumblr blog or instagram feed. Might be a fun project.
ksec 2y ago
>it’s all prioritisation of developer experience over user experience. And I have been saying this for well over a decade. Hopefully it catches on. I have always asked for example of sites done in React where I couldn't tell it is done in React or other JS Front End. The "at worst, hundreds of milliseconds" is precisely why Web Apps never felt as good as native apps. And if we collectively cant make web apps good, why not go back to Interactive Web Pages that is mostly Jank Free. I say mostly because it is still not Native Apps level. Recently submitted, [1] why does liking a tweet re-render the entire screen? done using [2] React-scan. [1] https://x.com/aidenybai/status/1862529226727121366 https://x.com/aidenybai/status/1862529226727121366 [2] https://github.com/aidenybai/react-scan https://github.com/aidenybai/react-scan
- Izkata 2y ago
  > why does liking a tweet re-render the entire screen? They're probably using Redux, which has been the go-to for state management in React for nearly a decade. I've always been averse to it because it's implemented using contexts and triggers those full re-renders - it was designed during the class-based components era and relied on people actually implementing shouldComponentUpdate(), which isn't really a thing with modern function-based components. If they were using modern hook-based state management like Zustand or Valtio, full rerenders wouldn't happen.
  - efdee 2y ago
    Redux uses context but does not do full re-renders except if you are using it wrong. It does a shallow compare on the object resulting from your selector to decide whether or not to re-render a component. That being said, none of the React projects I've had the chance of working on in the last 5 or 6 years has used Redux, so stating that it's been the go-to state management library for nearly a decade kind of sounds weird to me.
pmdr 2y ago
> on an old or cheap Android device. My Core-i5 24GB of RAM desktop PC that's 8 years old can pretty much do anything I used to do in 2016, except smoothly run React websites, some of which are verging on becoming unusable. This is nuts. People should stop using their M3 Pro Macbook as a benchmark for what's 'fast enough.'
- cosmic_cheese 2y ago
  “Works on my machine” in general is a huge problem in dev culture. I understand the desire to work on machines with lots of power and memory with a nice high res display and fiber connection. It makes the experience a great deal nicer. Even so, we should be keeping old and/or thoroughly mediocre devices around and testing on them periodically so we don’t succumb to illusions of good performance.
KronisLV 2y ago
I largely agree with your points, but wish it’d be easier to have server side rendering that’s not as tightly coupled to the rest of the system. What almost always happens is that with a SPA the core business logic is more or less separate from the bits that are shown in the browser, so that if AngularJS gets deprecated you still have an API that you can use for your Vue/React/Angular rewrite. However, if JSF becomes too much of a maintenance burden, the chances of me migrating to HTMX or a similar technology, even a full on SPA are pretty close to 0% when I have only a similar amount of time as in the case above. Why? Because the previous implementation is going to be in the same codebase and like it or not, as more time passes and as more people work on the codebase, there will be coupling. Those technologies will intertwine to such a degree, that a clear cut replacement will be really difficult. I guess what I’m pondering is why we don’t have an RPC/IPC component as a central part of Django, Rails, Laravel, JSF and all the others - so I could have server side rendering but separate repos (with separately managed dependencies) for the back end and the front end. Maybe even deploy them as separate containers that talk to one another and have resources managed separately, so the old JSF permission check logic for rendering components in a deep tree cannot eat the CPU time that’s needed for some scheduled processes in the back end.
bigfatkitten 2y ago
> I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve parsing a giant lump of JSON before you can do anything, that’s particularly CPU intensive and takes time on low end devices. Try doing it on a flagship handset like a Pixel 8 Pro, and it's still a slow and miserable experience. m.facebook.com, as an example.

satvikpendem 2y ago

With React Server Components, you can have your cake and eat it too, by sending only the necessary HTML to the browser (thereby having good performance and SEO) but also hydrating with more interactivity if necessary. And I'm not sure where you think CSS in JS means you don't learn CSS, I'm not sure how you'd use it otherwise... Either way, there are CSS in JS (TypeScript) libraries that compile down to regular CSS classes, like PandaCSS, so again, you can have your cake and eat it too.

afavour 2y ago
React Server Components strikes me as React solving a React-caused problem with yet more React. Which is fine, I guess, if you’re already locked into the React ecosystem. But as someone that isn’t, looking at the whole proposition from the outside, it just screams vendor lock-in to me. There are too many devs out there only expert in the way React does things and can’t step outside of it. RSC is an additional crutch that allows this to continue but that doesn’t mean it’s healthy. My main contention with the OP’s point was the assertion that React is almost always the right answer. One of my biggest bugbears about any web dev discussion (particularly on HN) is that everyone treats it as a one size fits all argument and it isn’t. If you’re making a webapp with interactivity levels like Gmail has then React is a sensible choice. The page reloads very irregularly. But if you’re making something like a blog with lots of drive by visits and only small islands of reactive content IMO it’s the wrong choice.
- thrw42A8N 2y ago
  The original problem was caused by PHP (see XHP) and this is just bringing the solution to full feature parity.
- satvikpendem 2y ago
  Perhaps it is vendor lock in, but the concept as a whole is not that difficult to generalize, as other frontend frameworks have their own sorts of implementations of the concept. Phoenix in the Elixir world has LiveView, for example. It's just that React's is more seamless, especially with TypeScript, as you can run JS (TypeScript) on both the client and server, so that you have greater control over exactly which components you want to be on the client versus the server without having to do so manually if you were to use something like Rails or Django. Therefore, even if you are making something like blogs, you can still use React as essentially a templating language via JSX and also use React for interactivity, for example a comment form component.
- switz 2y ago
  > React Server Components strikes me as React solving a React-caused problem with yet more React. This is not the case. RSC solves the hydration problem, in which hydration is profoundly expensive (larger bundle sizes, more client JS to parse and execute, and slower time to interactive), when most of the UI on any website can be non-hydrated. This also gives you the ability to write server only code (which as it would turn out, reduces sending third party deps to the client even more) for free with beautiful composability to client side hydration when you need it. Everyone hydrates at some point. Maybe you write isomorphic javascript or maybe you render a rails or python app and sprinkle in some JS. RSC enables you to do this with complete composition and re-usability. I'll put my money where my mouth is: RSC will continue to grow in adoption and its patterns will be adopted across many UI frameworks and libraries. This wasn't a solution in search of a problem, this was a large step forward in giving us more optionality as to how we architect websites. > There are too many devs out there only expert in the way React does things and can’t step outside of it. This is a weird ad hominem, attacking developers' skill instead of the actual technology. There are millions upon millions of React developers, and many of us have been building successful software for a long time and step outside of React every day. > But if you’re making something like a blog with lots of drive by visits and only small islands of reactive content IMO it’s the wrong choice. For some use-cases it is not the best choice, and for others it's the correct one. No one is hailing React as a one-size-fits-all solution, rather it remains a great balance that scales remarkably well to many needs.
hmeh 2y ago
You literally cannot. You can bake two cakes. You can’t have your cake and eat it too. Server and client rendering? You must concern yourself with both. The best frameworks will not perfect abstract this for you. They can’t, it’s leaky. When the cracks show, it will be painful. CSS-in-JS? I’ve used it and fought for it. Have you ever looked at the css output? That’s not a cake I’d want to eat. Compare it to a codebase with a well architected set of css and the markup and css actually do work for you. They are clarifying and reinforce structure. There are levels of productivity you gain based solely on things being clear and not convoluted that many people in our industry cannot recognize because they are fixated on the wrong thing. Whether that be what other people are using, or what gives dopamine hits (hot reloading, cool tech, etc)
- satvikpendem 2y ago
  > You literally cannot. You can bake two cakes. You can’t have your cake and eat it too. It is a common saying, not to be taken "literally." > The best frameworks will not perfect abstract this for you. They can’t, it’s leaky. When the cracks show, it will be painful. Better than before with pure server side solutions like Rails or Django, however. I use RSCs and they work just fine, because you are using TypeScript on both the client and the server, meaning there are greater abstractions that can be leveraged. > Have you ever looked at the css output? Not sure what CSS in JS library you used but with something like Typestyle or PandaCSS, you write CSS but in JS objects, so the generated CSS is simply turning those objects into the CSS you already wrote, not sure why it would be any different.
  - hmeh 2y ago
    I know what analogies are. I was extending yours. I was just saying that there are tradeoffs. You don’t think there are, and that’s fine. I can see them and I make my choices accordingly.
    - satvikpendem 2y ago
      I never said there weren't tradeoffs, just that RSCs enable greater functionality than before, such that one can "have their cake and eat it too," but it's not meant to mean that there are only two cakes in this entire analogical universe. Other frameworks (ie, cakes) have their own tradeoffs.

michaelcampbell 2y ago

Reacting to assertions of broad averages with specific counter examples doesn't necessarily invalidate their point.

afavour 2y ago
OK, let me restate something from my previous component explicitly: a site that’s concerned with SEO is not a “specialized domain”. It is very, very common.
- Scarblac 2y ago
  So are web applications that are completely behind auth and never need to care about SEO. They're quite different and it's a shame they're usually mixed up in these discussions.
- wokwokwok 2y ago
  Many sites have a two tier application with a CMS SEO “landing page” abd conversion funnel run by the marketing department and a user-login that takes you to a separate website that is SEO irrelevant. So… a site that doesnt care about SEO and is not indexed and is purely for logged in users is also very common.
  - afavour 2y ago
    I don’t really understand the disagreement here. I didn’t claim those sites are rare. I was specifically refuting the OPs claim that page load time only matters in a small number of specialized domains. I am saying it is very common for it to matter. It’s also very common for it to not matter, you’ll get no argument from me there.

ls_stats 2y ago

>Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. that was the case in 2015 when entry level android devices were quite slow, nowdays a cheap $200 android phone has at least 4-6GB of RAM and an eight core processor. if that isn't enough for your react powered site, you are doing something very wrong.

Mordisquitos 2y ago
The performance of client-side web applications asymptotically approaches load times of "at most a few hundred milliseconds" on the high end phone models owned by developers.
martinald 2y ago
Keep in mind that React is very single threaded (as is nearly everything in javascript). These phones might have 8 cores; but they tend to have the same single thread performance as 10+ year old iPhones.
- gf000 2y ago
  That assumes that the bottleneck is JS parsing/execution. The browser itself is not single-threaded and can load/parse resources in parallel. And I don't buy that most websites would have react as the bottleneck, over the million other js libs, ads and tracking.
  - mh- 2y ago
    No one is asking you to buy it, there is tons of empirical data you can analyze for yourself.
slotrans 2y ago
Multiple times daily I encounter sites that are brutally slow not just on my beefy Android phone, but on my 3GHz+ 8-core 64GB desktop machine. You need to take performance seriously or it will just be bad. Most of the industry has chosen to be bad.

johnfn 2y ago

> I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve parsing a giant lump of JSON before you can do anything, that’s particularly CPU intensive and takes time on low-end devices. The entire site may take multiple seconds to load, sure, but it's quite rare that this is a React issue. Typically, the real issue is something like the website making a bunch of API requests in serial rather than parallel. For instance, the issue of JSON parsing that you cited is actually an SSR issue; that's entirely orthogonal to React, and you can make the same error in any other popular web framework. > I actually think most of the problem isn’t React itself, it’s the ecosystem and the philosophy that surrounds it so often. You’ll have React, you’ll have some extra state management library on top, you’ll have some hideous CSS in JS bulk on top because no one wants to actually learn CSS… it’s all prioritisation of developer experience over user experience. And it’s industry standard these days. I think you're saying "React is slow" when you mean to say "the entire frontend ecosystem is slow". To which I respond... sure? None of this is React-specific. If you don't use React, you'll still have to use state management (or manage it yourself; have fun!), figure out something to do with CSS, etc, etc.

leptons 2y ago
API requests at page-load are definitely going to lower the page speed score. No API requests should happen at all, ideally, and all script and CSS to render everything "above the fold" should be loaded in-line. Nothing that is visible "below the fold" should ever run or load until the page is scrolled down by the site visitor. Only the bare-minimum script parsing that is required for the content "above the fold" should happen. Sure you can load scripts in-line for stuff below the fold, but make sure it doesn't actually get parsed by the browser until that feature is likely to be visible on the screen. It doesn't matter what library or framework is used - even jQuery can score 100% page speeds on Google Lighthouse. It really only depends on following every single nitpicky thing that Google Lighthouse recommends, and finding a solution for it. I took a site (actually a few thousand sites) that was scoring about 5 to 35 out of 100 on Google Lighthouse (depending on the customiztions), up to 100/100 on Google Lighthouse. It took a lot of work, but the clients are happy now. Where React doesn't do well is with lots of DOM elements. In another project I created a complex web application that had about 3000 div elements with drag-and-drop interface and all kinds of stuff going on. Well React couldn't handle it. The browser started crashing due to memory issues if the page was open longer than 20 minutes or so, it slowed to a crawl and eventually froze. I ended up switching that one component to a canvas based solution (Konva) and it solved the problem completely. I still use React for all the other simple UI stuff, but I learned my lesson about what React is really good at and what it's not.

lolinder 2y ago

These disagreements almost always boil down to one side saying "some people use React to build content-oriented websites" and the other side saying "but most of us are building web applications". In a typical web application use case (yes, there are exceptions) you're only rarely looking at usage from old or cheap Android devices. Occasionally you'll see a tablet, but even that's rare. The vast majority of the time your users are on either Chrome or Safari on a relatively modern Mac or Windows machine. In many cases the application loads once at the start of at least 10+ minutes of work, so initial load times rarely matter much. If you're building a website that needs SEO, then yeah, React is completely the wrong tool, and you should just make a proper static site or hook your marketing team up with WordPress (or whatever takes its place once Matt is finished blowing it up). But those use cases, while common, represent a tiny fraction of total engineering effort across the industry, so most web developers here don't have the design constraints that make React a bad choice.

xcrunner529 2y ago
The top sites using react are all e-commerce or social sites. I would bet the majority of react sites and devs that use them are not building apps that require SPA or something like React. Which is the problem.
- lolinder 2y ago
  > I would bet the majority of react sites and devs that use them are [n]ot building apps that require SPA or something like React. [edited to restore what I assume is the ended meaning] On what basis do you bet this, though? Sure, you see sites that bug you by being slow in contexts where you'd choose something else, but most devs are working on sites and apps that you will never see, because you're not the target demographic. I don't have survey data one way or the other, but anecdotally everywhere I've worked on an SPA has been a clear case where trying to do it in backend+JQuery would have been a huge failure.
  - ysavir 2y ago
    But there is a wide gulf between backend + JQuery and SPA. The frustration often shown is people treating the extremes as the only options available. Having a use case for which backend + jQuery doesn't cut it doesn't require reinventing navigation state and history in JS, or loading every stat on the page via JSON. There are middle grounds.

xcrunner529 2y ago

It’s just embarrassing any image scrolling site will eventually just eat all the memory and crash and you lose your place. Used to kill me back in the Tumblr days and React perpetuates it.

deleted 2y ago
[deleted]
ZYbCRq22HbJ2y7 2y ago
That is an implementation issue, not a framework issue. There are plenty of easy to use virtual scrolling libraries for React and vanilla JS. There is also `content-visibility` with CSS Containment now.
- xcrunner529 2y ago
  I’d love to see how those new options perform these days by replicating a large tumblr blog or instagram feed. Might be a fun project.

ksec 2y ago

>it’s all prioritisation of developer experience over user experience. And I have been saying this for well over a decade. Hopefully it catches on. I have always asked for example of sites done in React where I couldn't tell it is done in React or other JS Front End. The "at worst, hundreds of milliseconds" is precisely why Web Apps never felt as good as native apps. And if we collectively cant make web apps good, why not go back to Interactive Web Pages that is mostly Jank Free. I say mostly because it is still not Native Apps level. Recently submitted, [1] why does liking a tweet re-render the entire screen? done using [2] React-scan. [1] https://x.com/aidenybai/status/1862529226727121366 https://x.com/aidenybai/status/1862529226727121366 [2] https://github.com/aidenybai/react-scan https://github.com/aidenybai/react-scan

Izkata 2y ago
> why does liking a tweet re-render the entire screen? They're probably using Redux, which has been the go-to for state management in React for nearly a decade. I've always been averse to it because it's implemented using contexts and triggers those full re-renders - it was designed during the class-based components era and relied on people actually implementing shouldComponentUpdate(), which isn't really a thing with modern function-based components. If they were using modern hook-based state management like Zustand or Valtio, full rerenders wouldn't happen.
- efdee 2y ago
  Redux uses context but does not do full re-renders except if you are using it wrong. It does a shallow compare on the object resulting from your selector to decide whether or not to re-render a component. That being said, none of the React projects I've had the chance of working on in the last 5 or 6 years has used Redux, so stating that it's been the go-to state management library for nearly a decade kind of sounds weird to me.

pmdr 2y ago

> on an old or cheap Android device. My Core-i5 24GB of RAM desktop PC that's 8 years old can pretty much do anything I used to do in 2016, except smoothly run React websites, some of which are verging on becoming unusable. This is nuts. People should stop using their M3 Pro Macbook as a benchmark for what's 'fast enough.'

cosmic_cheese 2y ago
“Works on my machine” in general is a huge problem in dev culture. I understand the desire to work on machines with lots of power and memory with a nice high res display and fiber connection. It makes the experience a great deal nicer. Even so, we should be keeping old and/or thoroughly mediocre devices around and testing on them periodically so we don’t succumb to illusions of good performance.

KronisLV 2y ago

I largely agree with your points, but wish it’d be easier to have server side rendering that’s not as tightly coupled to the rest of the system. What almost always happens is that with a SPA the core business logic is more or less separate from the bits that are shown in the browser, so that if AngularJS gets deprecated you still have an API that you can use for your Vue/React/Angular rewrite. However, if JSF becomes too much of a maintenance burden, the chances of me migrating to HTMX or a similar technology, even a full on SPA are pretty close to 0% when I have only a similar amount of time as in the case above. Why? Because the previous implementation is going to be in the same codebase and like it or not, as more time passes and as more people work on the codebase, there will be coupling. Those technologies will intertwine to such a degree, that a clear cut replacement will be really difficult. I guess what I’m pondering is why we don’t have an RPC/IPC component as a central part of Django, Rails, Laravel, JSF and all the others - so I could have server side rendering but separate repos (with separately managed dependencies) for the back end and the front end. Maybe even deploy them as separate containers that talk to one another and have resources managed separately, so the old JSF permission check logic for rendering components in a deep tree cannot eat the CPU time that’s needed for some scheduled processes in the back end.

bigfatkitten 2y ago