12 ms·

Reading over the authors primary reasons to not use React, they strike me as fundamentally misguided - mostly solving problems that most people don’t have. One

by johnfn 2y ago

Reading over the authors primary reasons to not use React, they strike me as fundamentally misguided - mostly solving problems that most people don’t have. One reason it says that React is a poor choice is performance issues. But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. Yes, there are a few specialized domains where this will matter. No, you probably don’t work in one. Greater leverage can almost always be derived from improving the backend. The second reason the author says is that it’s based on a legacy eventing system which supports IE. The author goes on for quite a while to say how bad this is, but I question the assumption it’s predicated on: the legacy eventing system never bothers me, and it doesn’t create issues visible to my users. As far as it seems to me, this argument is akin to saying that React hasn’t bothered refactoring an old part of the code base. Yes, that’s not great, but it hardly strikes me as a reason to drop a framework entirely. Finally, the author doesn’t actually give a prescription as to what to use instead of React. This is, personally, where the argument really falls apart. React does make a set of tradeoffs, I don’t deny that, but most alternatives I’ve seen make a worse set of tradeoffs that shift more work onto the engineer. Of course, since the author doesn’t actually highlight any alternative, we can’t have a discussion about what you’re trading away, but I suspect that the author makes no proposal because he knows that any alternative would immediately be shot down as obviously worse than React.

aaronblohowiak 2y ago
>React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. Yes, there are a few specialized domains where this will matter. No, you probably don’t work in one. Greater leverage can almost always be derived from improving the backend. Respectfully, I disagree on all of these points.
- Tronno 2y ago
  Care to elaborate?
  - aaronblohowiak 2y ago
    Other commenters have elaborated as well, but to summmarize: hundreds of Ms on a dev machine a) does matter and b) is likely much much more in less than ideal computing environments, I disagree that the backend usually is where more time is spent (at least in maaaaany apps I have worked on) And re: specialized domains, I think most users of most software appreciate speed even if it isn’t a stated objective
echelon 2y ago
> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. Yes, there are a few specialized domains where this will matter. No, you probably don’t work in one. This is fine for solving random business integration concerns, but for application software we have to use on a daily basis, it really sucks. Modern web applications sometimes feel incredibly shitty to use. Gmail, YouTube, YouTube Music, Reddit, Twitter -- these are all bloated, hulking, beastly things. I'm really hoping Rust becomes popular for specifically web application development. It'll need to overcome the awkward WASM/DOM bridge, but then it'll sing. Heavy software that users spend hours within are where those hundreds of milliseconds per action really add up. We should be angry about anything worse than single digit milliseconds with these tools. We need an engineering culture of excellence in these domains. Channel the Steve Jobs energy to say this isn't good enough.
- ToucanLoucan 2y ago
  > This is fine for solving random business integration concerns, but for application software we have to use on a daily basis, it really sucks. And more than it just sucking, it is unnecessary. We have mature, well documented, cost effective solutions for developing software that have been around from years to decades. We know how to develop software. The problem is people trying to develop software with web tools.
- no_wizard 2y ago
  > Heavy software users spend hours within are where those hundreds of milliseconds per action really add up. We should be angry about anything worse than single digit milliseconds with these tools. I think in the article writers mind here we are talking hundreds of milliseconds on first load and the majority of actions are instantaneous after that. This can be achieved, but it takes some diligence and product mind focus to optimize what you can how you can and even big companies like Google don’t always prioritize this the way they should
  - deleted 2y ago
    [deleted]
- 2y ago
ToucanLoucan 2y ago
> But front end performance issues are almost never the most pressing issue to deal with. Maybe not to you, but it's by far and away the biggest complaint with any website or app that uses React/Angular under the hood in my experience. On any computer older than a few years, the sheer amount of JavaScript being demanded to be run creates serious system bottlenecks. This is literally why I cancelled Spotify, because it's fucking absurd to me that I need a (then anyway) 700 MB app to stream music.
- johnfn 2y ago
  Is it? On Hacker News it probably is, and I agree that it can drive engineers nuts to know that apps are more bloated than they have to be, but I think we’re a relatively small percentage of the population. Among my less technically/inclined friends and family I haven’t heard one complaint about, say, Spotify being slow, and certainly never any complaints about its size.
  - ToucanLoucan 2y ago
    They don't say "I'm sick of React websites," they just say "Wow websites are getting slower and slower." or they complain about specific tabs or just the browser in general sucking up tons of RAM and CPU.
    - no_wizard 2y ago
      I’m also aware they won’t make the direct references and I’m willing to bet the OP is too. There are very few instances I can think of for the last 4 years where I heard anyone complaining like this about the general state of these things. There’s a few offenders I can think of, like Salesforce, but I haven’t heard from any non technical users especially about things like Gmail being slow or their browsers being too slow. Whet I often hear instead to be honest is people widely seem surprised when they have 200 tabs open in Chrome and everything still feels fast to them That’s not to say performance isn’t important, it really is, in fact I’m the performance czar where I work, I spend along time on optimizations and performance. However the acceptable performance threshold is dependent on the activity more than anything I’ve found. That’s why it’s such a big deal in e-commerce but people don’t seem to care as much for longer lived apps, otherwise Jira might actually be snappy Now of course there is a threshold regardless of app where it will things negatively, losing customers etc. and thus it shouldn’t be ignore either
afavour 2y ago
> 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.
hmeh 2y ago
Ironically the first question you ask is the question people should be asking about React. Specifically, what problem does it solve, and do I have that problem? The problem most teams tend to face, and I believe part of the authors argument is that people reach for React out of an almost superstitious or orthodoxy-based belief. Likely many developers don’t even know how to build something without React. They don’t know the first thing about html, server-side rendering, progressive enhancement or any of the things we used to use to build forms over data applications before React came along and its siren song drew away many developers, and, worse, created an entire generation that fits the criteria I’m describing. The author doesn’t need to describe an alternative any more than he did, because the alternative is supposed to be self-evident. If it’s not, the person is supposed to take the plethora of breadcrumbs in the article and figure out how we used to do things before bloated, convoluted, and typically unnecessary frameworks. When you look at something like Remix and Next you see people trying go back to the simple (forms, server rendering) by adding additional complexity. It’s doubling down on complexity, rather than finding simplicity.
- vessenes 2y ago
  Meh. What is that self-evident alternative supposed to be? I ask as someone who crafted HTML with my father's lisp parens on computers running linux kernels which were still delivered with the pl suffix, and as someone who occasionally still occasionally tries to deliver frontend code, much to my dismay. I've made websites in so many stacks and varieties that it would be intensely boring to list or read them, and I have NO IDEA what he thinks is better, or even if he is able to disambiguate the React architecture from the React library/stack, or which one he is talking about. It's a tome, a full tome, without a clear position. Mine is this: a truly state based rendering and eventing engine for frontends is a dream, a beautiful dream, not unlike the beautiful dream of a purely functional language based on the lambda (or rho?) calculus. The dream giveth and it taketh away, and it is always a fundamentalist dream; where that fundamentalism hits the cracks of reality is where engineers have to make tradeoffs. The React architecture stack (well, the stack without prop drilling) stays somewhat beautiful as a dream in my opinion, which is to say it provides guide- and guard-rails to stay relatively productive delivering mid size applications across millions of devices without a ton of moments where I'm like "what the fuck is the rule of hooks, and how did I break it here?" The react library stack, and by extension the node stack: sucks balls, full stop. I'm happy to get some other framework which has write/compile-time type safety, modularity and an eventing/rendering system that abstracts away most of my concerns for delivering over the web and is lighter weight, has less dependencies, etc. However, if the author wants me to change my ill-begotten ways, it would probably be more effective to explain how it is that each of the items in his list: "Preact, Stencil, Svelte, Lit, FAST, Qwik, or any of a dozen faster, smaller, reactive client-side systems" provide a better world. In this area, I believe I'm a journeyman, reading a senior / master engineer's writing -- fine. But he is not informing me at all. I don't want to go learn the recommended 18 (12 unnamed) smaller client-side systems that apparently require less mental bookkeeping of me. I'm not even sure what that means -- I code tsx in vim, and do not feel like I have to do a lot of bookkeeping. So, back to you -- what's your recommendation? I'm genuinely curious what you think would be better. Or the author, if he wants to butt in here. I just don't understand what you (or the author) thinks should be done. The forms processing and server rendering (say with Perl 5 and tcl were two early langauges for me) were not that great.
hasanhaja 2y ago
I urge you to read Alex's Reckoning series. > performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. I think outside of the privilege bubble where a significant percentage of the world is in, these concerns are measured in the tens of seconds. > it doesn’t create issues visible to my users What do your users look like? What kind of devices are they on? Is it mostly mobile or desktop? Are they mostly accessing your service on cellular networks or not? Based on that, what does your INP look like? IMO you'll see the impact of React's legacy synthetic event system by looking at your INP because it's reinventing in userland what the platform already does well. This impact on INP is amplified on mobile and moreso on low-end mobile. See CRUX data visualised by desktop or mobile below: https://infrequently.org/2022/12/performance-baseline-2023/#2023-content-targets https://infrequently.org/2022/12/performance-baseline-2023/#... > Finally, the author doesn’t actually give a prescription as to what to use instead of React. I think he does and that's a big part of this article. It's almost literally everything from the "OK, But What, Then?" section. The TLDR is there isn't a one-size-fits-all.
- agumonkey 2y ago
  Curious, is this the series https://infrequently.org/2024/08/the-landscape/ https://infrequently.org/2024/08/the-landscape/ ?
  - hasanhaja 2y ago
    Yes, that's the one! Thank you for linking it.
    - agumonkey 2y ago
      thanks back, i never saw his blog and he seems deeply knowledgeable
- johnfn 2y ago
  > I think he does and that's a big part of this article. It's almost literally everything from the "OK, But What, Then?" section. I did read it. I didn't want to go into depth debunking every single sentence OP wrote because I thought it would be obnoxious, but I'll write a bit more. > The TLDR is there isn't a one-size-fits-all. That's what I mean - the author gives no prescription. Saying there is no one-size-fits-all is not a prescription. I'll respond to a specific quote the author said, which I believe to be the crux of his suggestion: > Teams that have grounded their product decisions appropriately can productively work through the narrow form by running truly objective bakeoffs. Most teams do not have the privilege of being able to "ground their product decisions appropriately". Most teams - at least those in small to mid-size startups - will start out building A, route through A' and A'' and end up building B once they land on PMF. If you ran a "bakeoff" on A, you're going to be a bit upset when you end up at A' and probably run horribly technically aground when you truly find the right thing to build. Yes, if at the point when you discover B you have the latitude to rewrite your entire codebase to fit your new criteria, then by all means, go ahead. That will definitely outperform React. I think the teams with that kind of latitude is an exceptionally small fraction of all teams, and the number of teams with the technical chops to do it correctly will be an even smaller fraction of that. The rest of us will use React, which is roughly 80% as good as the optimal solution. Oh and, yes, if you work at a huge company who has found PMF and has the latitude to rewrite your code into whatever the optimal solution is, don't let me stop you. That is what Google and Facebook did, after all. I just don't think many of us are Google or Facebook.
LtWorf 2y ago
> But front end performance issues are almost never the most pressing issue Tell me your websites are unbearably slow without telling me your websites are unbearably slow :D
- johnfn 2y ago
  I've spent plenty of time optimizing performance. It almost always comes down to a backend issue, unless the frontend is doing something profoundly stupid, like making multiple API requests in serial when they could be batched or parallelized.
  - LtWorf 2y ago
    Yes because loading 500 different css and js files is not a problem for performance.
    - smrq 2y ago
      They literally just said "unless the frontend is doing something profoundly stupid".
      - yawaramin 2y ago
        That's the norm in the React world nowadays. You should take a look at https://infrequently.org/2024/08/object-lesson/ https://infrequently.org/2024/08/object-lesson/
        johnfn 2y ago
        This article is better, but has very little to do with React. The major issues I see are 1) loading a 2.5 MB AWS library (not React), 2) not doing SSR (not React) and 3) not tree shaking (not React). I agree these are all problems. But shouting to the skies about React is not going to solve them.
        2y ago
xcrunner529 2y ago
They’re not problems most people have because they shouldn’t be using React or maybe even a SPA-type site in the first place! I think that’s one of the big points regardless. Just using react and it’s bloat to be hip and it not actually doing anything better or more performant for the use case of a shopping site. It’s not a CAD app or web office suite.
gnulinux996 2y ago
> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. Try opening facebook.com; click the messenger, (+1 second) Click one of your chat groups (~2 seconds) This is merely just to show something From what I have seen, its quite easy to have performance issues with React
- reshlo 2y ago
  So easy in fact that even the company that makes React can’t use it in a way that makes their site fast.
- johnfn 2y ago
  That doesn't say much about React, though. Indeed, you can open the network panel and watch requests go by over the seconds that it takes to open, suggesting that the issue likely resides on the backend.
  - gls2ro 2y ago
    So the company that invented it does not know how to properly use it? Or are you implying that React does not fit FB use case?
    - Wool2662 2y ago
      He's literally saying the front end technology doesn't matter at all in this. Are you just going to defend React to the bitter end? Or do you just enjoy imaginary binary choices?
      - gls2ro 2y ago
        I think I was not clear in my question: I don't defend React. My question was almost the opposite and I was trying to ask: So if even Facebook has a problem with using React then who has a better examplea about why and how to use it?
        2y ago
ramones13 2y ago
To your third point - the author would recommend doing research and prototyping with all the options you might consider based on your use-cases. He actively avoids being prescriptive in generic contexts like this because he wants to avoid arbitrary dogmatic solutions (like React tends to be). Source: I work closely with him and have been frustrated with this stance until I saw people using Next and Remix for things like landing or contact pages.
- johnfn 2y ago
  (Sorry, somewhat copying this, since I responded to a similar point elsewhere.) This is not practical advice for the vast majority of software engineering teams. Most teams do not have the privilege of being able to do research and prototypes across multiple options, at least in a way representative of what their final product will look like. Most teams - at least those in small to mid-size startups - will start out building A, route through A' and A'' and end up building B once they land on PMF. If you were to run 5 different prototypes on A, you're going to be a bit upset when you end up at A' and you're likely to run horribly technically aground when you truly find the right thing to build. Yes, if at the point when you discover B you have the latitude to rewrite your entire codebase to fit your new criteria, then by all means, go ahead. That will definitely outperform React. I think the teams with that kind of latitude is an exceptionally small fraction of all teams, and the number of teams with the technical chops to do it correctly will be an even smaller fraction of that. The rest of us will use React, which is roughly 80% as good as the optimal solution.
  - ramones13 2y ago
    My experiences don’t really align with yours - most people are playing “follow the leader” with tech - “X uses Y, so we should to” and that’s it. To your point though - use the platform. Vanilla HTML, CSS, and JS. All of that will be reusable no matter where you pivot and not lock you in to a pattern that might not work well for where you land.
    - johnfn 2y ago
      > Vanilla HTML, CSS, and JS This is a non-answer. It only really is an admissible solution if you're just working by yourself. React solves real problems when building web applications. If you use vanilla HTML, CSS and JS, you're going to have to solve those same problems. How are you going to do it? How are you going to manage state? How are you going to synchronize your state with the DOM? How are you going to organize your components? Teams that use vanilla HTML, CSS, and JS end up eventually building an internal, buggy, half-implemented, undocumented version of React.
rkagerer 2y ago
I hate what "modern" web development has done to my UI experience. Eg. There's a delay between an Amazon.ca results page loading and it populating the search text box with the phrase you just searched for. As a result when I do two searches in rapid succession, it consistently interrupts my typing at exactly the right time to batter in incomprehensible text. AirCanada and WestJet are two other websites that became awful to use after adopting React-ey style UI's.
- kccqzy 2y ago
  There's no React-ey style UI. Seriously. It's a UI framework not a collection of prebuilt UI components. You cannot tell if a site is using React or not without opening dev tools.
  - trog 2y ago
    I might not be able to tell if it's using React specifically, but I can tell it's using a React-like framework trivially because it feels like the entire website is covered in glue
    - kccqzy 2y ago
      No. You are just dealing with bad code. There are highly performant web apps written in React. It's all about craftsmanship. React gives you many tools to skip unnecessary work and reduce latency, such as shouldComponentUpdate, and assigning keys to elements in a collection. Or architectural decisions like splitting your UI into components correctly. It's up to the individual developers to use them. Bad developers write bad code in any framework. But one thing I've noticed is that because frontend code runs on users' computers, fewer businesses and engineers have the incentive to really optimize that performance. If one writes bad backend code, it shows up as increased AWS bill; if one writes bad frontend code, well the cost is diffuse and many don't notice it.
      - trog 2y ago
        > No. You are just dealing with bad code. There are highly performant web apps written in React. cool maybe I'll see one one day > React gives you many tools to skip unnecessary work and reduce latency, such as shouldComponentUpdate, and assigning keys to elements in a collection but do people use these outside of demos I have an high end CPU with 32GB of RAM and almost every single website I use gives me a worse experience than I got 20 years ago > if one writes bad frontend code, well the cost is diffuse and many don't notice it. exactly, and that's why we are where we are today - surrounded on all sides by websites covered in glue, because bad experience has been completely normalised, all for what? Some abstract notion of developer convenience that results in almost every case in a significantly worse experience by almost any metric.
beeflet 2y ago
> hundreds of milliseconds. Yes, there are a few specialized domains where this will matter. No, you probably don’t work in one. This is funny to me, because I would think that for hundreds of milliseconds, anything user-facing is impacted. It's on the order of the human reaction time (~200ms). That's noticeable delay. I do not work in frontend, so perhaps I am misguided. But I have had bad user experience using apps with even 100ms delay that require a lot of input (for example using excel or something in a streaming VM).
- maigret 2y ago
  You are not misguided. Physiology is mostly intangible but consistent. Many of the comments here willingly ignore that “yes but my use case is different and my users are patient”. Their brain will still disconnect quickly and be frustrated.
wordofx 2y ago
In 2024. React is probably the worst choice you could make when creating a new web application.
- vessenes 2y ago
  ...and the best would be?
- cheema33 2y ago
  For static web page, it would be tough to beat html/css. But if you are building a web application of some complexity, it would be tough to beat React. You can totally shoot yourself in the foot with any language or framework. And you can most certainly do that with React as well. As we so often see.
diob 2y ago
Yeah, poor performance is possible in any system using any tech. Being able to diagnose it and fix it is what matters. I've never had a performance issue I couldn't fix in React.
- gls2ro 2y ago
  I think the question that we are discussing here is: What amount of performance issues you will not need to fix if you were not using React to begin with?
slotrans 2y ago
> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. Many years ago I worked at a wonderful company that made the terrible decision to rebuild the frontend in React. We had a performance dashboard permanently displayed on a TV in the office, prominently showing the p99 time-to-interactive of our home page. It sat at TWENTY SECONDS for at least 2 years. No progress was ever made, to the best of my knowledge. This was an e-commerce site, more or less. As per the author's reasoning, it absolutely should not have been an SPA.
- gf000 2y ago
  E-commerce sites are a pretty good fit for SPAs. Sounds like a bad rewrite, nothing more, nothing less.
  - exceptione 2y ago
    Why do you think that? The only client side component of interest would be filtering and sorting, (although the server could render the new state too). I would choose traditional server side + a little bit of client side code here.
    - deleted 2y ago
      [deleted]
59nadir 2y ago
There really are only a handful of things you could do that should passably take "hundreds of milliseconds" and loading a web page is not among them. Neither is displaying a few hundred thousand things on a screen, least of all what are essentially rects in 2D. The only reason any of the above sounds fine to take this long is because the standards of web development are so incredibly low.
- bryanrasmussen 2y ago
  sure if you have the access directly to drawing those rects in 2D, but if you are using a library to do drawing of the rects you may have a small tradeoff of time (obviously not 100s of milliseconds) and if you are using a library that abstracts away writing to the DOM for you and then the browser takes the DOM and essentially figures out how to draw a hundred thousand things on the screen you might get in the hundred milliseconds area - depending on a whole bunch of things that are varying from time to time. The only reason that 100s of milliseconds might sound fine is because there are multiple layers of abstraction between levels, but as you can see from all the other responses here the 100s of milliseconds evidently does not sound fine.
grey-area 2y ago
> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. This is not my experience on real react sites. Loading the pages on mobile (say 4G) takes seconds to load with a partially rendered page which is slowly constructed. Loading the equivalent pages in HTML rendered server side would reliably be under 100ms (excluding assets). This is somewhat disguised by better connections and large images taking up, but all that js and json does have a cost. You're probably trying to talk about the overhead of the framework, but what is the true overhead of a framework which encourages you to introduce bloat and create a separate component file and sometimes a separate network connection for every single component on your web page? Here is a real case study with comparison of approaches from this author: https://infrequently.org/2024/08/object-lesson/ https://infrequently.org/2024/08/object-lesson/ >The second reason the author says is that it’s based on a legacy eventing system which supports IE. There are lots of horrible bits of react which are based on solving problems which aren't really a problem on the web any more - from manipulating the dom (pretty easy without react) to dealing with IE polyfills, and lots of bits that you really don't need the client to concern itself with (i.e. routing code). You may not care about that code but you are importing it and forcing your users to download it. It all adds to overhead. There are also a ton of other points in the article which you've elided, which go into the multiple failings of React as a tool, and primary among them is that it encourages you to use react and only react, the ultimate in lock-in. > Finally, the author doesn’t actually give a prescription as to what to use instead of React. You want them to choose one framework instead of react, they're explicitly rejecting that choice and saying you don't have to become a follower of react or any other religion, instead they're advocating choosing tools based on the evidence they have presented, so they are IMO presenting a clear choice: Server side rendering with a bit of js as required to load dynamic data React or similar frameworks which try to push everything to the client
mvdtnz 2y ago
> But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. I'm guessing you're one of those developers who never browses the web on anything but the latest Macbook Pro and iPhone. I implore you to restrict yourself to some lower end devices for a few weeks and let us know if you still feel the same way.
- jazzypants 2y ago
  I generally agree with you, but I have a budget cell phone (~$100) and I can run StackBlitz on it without it even blinking. I think budget cell phones have gotten a lot better than most people think.

by johnfn 2y ago

aaronblohowiak 2y ago

>React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. Yes, there are a few specialized domains where this will matter. No, you probably don’t work in one. Greater leverage can almost always be derived from improving the backend. Respectfully, I disagree on all of these points.

Tronno 2y ago
Care to elaborate?
- aaronblohowiak 2y ago
  Other commenters have elaborated as well, but to summmarize: hundreds of Ms on a dev machine a) does matter and b) is likely much much more in less than ideal computing environments, I disagree that the backend usually is where more time is spent (at least in maaaaany apps I have worked on) And re: specialized domains, I think most users of most software appreciate speed even if it isn’t a stated objective

echelon 2y ago

> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. Yes, there are a few specialized domains where this will matter. No, you probably don’t work in one. This is fine for solving random business integration concerns, but for application software we have to use on a daily basis, it really sucks. Modern web applications sometimes feel incredibly shitty to use. Gmail, YouTube, YouTube Music, Reddit, Twitter -- these are all bloated, hulking, beastly things. I'm really hoping Rust becomes popular for specifically web application development. It'll need to overcome the awkward WASM/DOM bridge, but then it'll sing. Heavy software that users spend hours within are where those hundreds of milliseconds per action really add up. We should be angry about anything worse than single digit milliseconds with these tools. We need an engineering culture of excellence in these domains. Channel the Steve Jobs energy to say this isn't good enough.

ToucanLoucan 2y ago
> This is fine for solving random business integration concerns, but for application software we have to use on a daily basis, it really sucks. And more than it just sucking, it is unnecessary. We have mature, well documented, cost effective solutions for developing software that have been around from years to decades. We know how to develop software. The problem is people trying to develop software with web tools.
no_wizard 2y ago
> Heavy software users spend hours within are where those hundreds of milliseconds per action really add up. We should be angry about anything worse than single digit milliseconds with these tools. I think in the article writers mind here we are talking hundreds of milliseconds on first load and the majority of actions are instantaneous after that. This can be achieved, but it takes some diligence and product mind focus to optimize what you can how you can and even big companies like Google don’t always prioritize this the way they should
- deleted 2y ago
  [deleted]
2y ago

ToucanLoucan 2y ago

> But front end performance issues are almost never the most pressing issue to deal with. Maybe not to you, but it's by far and away the biggest complaint with any website or app that uses React/Angular under the hood in my experience. On any computer older than a few years, the sheer amount of JavaScript being demanded to be run creates serious system bottlenecks. This is literally why I cancelled Spotify, because it's fucking absurd to me that I need a (then anyway) 700 MB app to stream music.

johnfn 2y ago
Is it? On Hacker News it probably is, and I agree that it can drive engineers nuts to know that apps are more bloated than they have to be, but I think we’re a relatively small percentage of the population. Among my less technically/inclined friends and family I haven’t heard one complaint about, say, Spotify being slow, and certainly never any complaints about its size.
- ToucanLoucan 2y ago
  They don't say "I'm sick of React websites," they just say "Wow websites are getting slower and slower." or they complain about specific tabs or just the browser in general sucking up tons of RAM and CPU.
  - no_wizard 2y ago
    I’m also aware they won’t make the direct references and I’m willing to bet the OP is too. There are very few instances I can think of for the last 4 years where I heard anyone complaining like this about the general state of these things. There’s a few offenders I can think of, like Salesforce, but I haven’t heard from any non technical users especially about things like Gmail being slow or their browsers being too slow. Whet I often hear instead to be honest is people widely seem surprised when they have 200 tabs open in Chrome and everything still feels fast to them That’s not to say performance isn’t important, it really is, in fact I’m the performance czar where I work, I spend along time on optimizations and performance. However the acceptable performance threshold is dependent on the activity more than anything I’ve found. That’s why it’s such a big deal in e-commerce but people don’t seem to care as much for longer lived apps, otherwise Jira might actually be snappy Now of course there is a threshold regardless of app where it will things negatively, losing customers etc. and thus it shouldn’t be ignore either

afavour 2y ago

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

hmeh 2y ago

Ironically the first question you ask is the question people should be asking about React. Specifically, what problem does it solve, and do I have that problem? The problem most teams tend to face, and I believe part of the authors argument is that people reach for React out of an almost superstitious or orthodoxy-based belief. Likely many developers don’t even know how to build something without React. They don’t know the first thing about html, server-side rendering, progressive enhancement or any of the things we used to use to build forms over data applications before React came along and its siren song drew away many developers, and, worse, created an entire generation that fits the criteria I’m describing. The author doesn’t need to describe an alternative any more than he did, because the alternative is supposed to be self-evident. If it’s not, the person is supposed to take the plethora of breadcrumbs in the article and figure out how we used to do things before bloated, convoluted, and typically unnecessary frameworks. When you look at something like Remix and Next you see people trying go back to the simple (forms, server rendering) by adding additional complexity. It’s doubling down on complexity, rather than finding simplicity.

vessenes 2y ago
Meh. What is that self-evident alternative supposed to be? I ask as someone who crafted HTML with my father's lisp parens on computers running linux kernels which were still delivered with the pl suffix, and as someone who occasionally still occasionally tries to deliver frontend code, much to my dismay. I've made websites in so many stacks and varieties that it would be intensely boring to list or read them, and I have NO IDEA what he thinks is better, or even if he is able to disambiguate the React architecture from the React library/stack, or which one he is talking about. It's a tome, a full tome, without a clear position. Mine is this: a truly state based rendering and eventing engine for frontends is a dream, a beautiful dream, not unlike the beautiful dream of a purely functional language based on the lambda (or rho?) calculus. The dream giveth and it taketh away, and it is always a fundamentalist dream; where that fundamentalism hits the cracks of reality is where engineers have to make tradeoffs. The React architecture stack (well, the stack without prop drilling) stays somewhat beautiful as a dream in my opinion, which is to say it provides guide- and guard-rails to stay relatively productive delivering mid size applications across millions of devices without a ton of moments where I'm like "what the fuck is the rule of hooks, and how did I break it here?" The react library stack, and by extension the node stack: sucks balls, full stop. I'm happy to get some other framework which has write/compile-time type safety, modularity and an eventing/rendering system that abstracts away most of my concerns for delivering over the web and is lighter weight, has less dependencies, etc. However, if the author wants me to change my ill-begotten ways, it would probably be more effective to explain how it is that each of the items in his list: "Preact, Stencil, Svelte, Lit, FAST, Qwik, or any of a dozen faster, smaller, reactive client-side systems" provide a better world. In this area, I believe I'm a journeyman, reading a senior / master engineer's writing -- fine. But he is not informing me at all. I don't want to go learn the recommended 18 (12 unnamed) smaller client-side systems that apparently require less mental bookkeeping of me. I'm not even sure what that means -- I code tsx in vim, and do not feel like I have to do a lot of bookkeeping. So, back to you -- what's your recommendation? I'm genuinely curious what you think would be better. Or the author, if he wants to butt in here. I just don't understand what you (or the author) thinks should be done. The forms processing and server rendering (say with Perl 5 and tcl were two early langauges for me) were not that great.

hasanhaja 2y ago

I urge you to read Alex's Reckoning series. > performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. I think outside of the privilege bubble where a significant percentage of the world is in, these concerns are measured in the tens of seconds. > it doesn’t create issues visible to my users What do your users look like? What kind of devices are they on? Is it mostly mobile or desktop? Are they mostly accessing your service on cellular networks or not? Based on that, what does your INP look like? IMO you'll see the impact of React's legacy synthetic event system by looking at your INP because it's reinventing in userland what the platform already does well. This impact on INP is amplified on mobile and moreso on low-end mobile. See CRUX data visualised by desktop or mobile below: https://infrequently.org/2022/12/performance-baseline-2023/#2023-content-targets https://infrequently.org/2022/12/performance-baseline-2023/#... > Finally, the author doesn’t actually give a prescription as to what to use instead of React. I think he does and that's a big part of this article. It's almost literally everything from the "OK, But What, Then?" section. The TLDR is there isn't a one-size-fits-all.

agumonkey 2y ago
Curious, is this the series https://infrequently.org/2024/08/the-landscape/ https://infrequently.org/2024/08/the-landscape/ ?
- hasanhaja 2y ago
  Yes, that's the one! Thank you for linking it.
  - agumonkey 2y ago
    thanks back, i never saw his blog and he seems deeply knowledgeable
johnfn 2y ago
> I think he does and that's a big part of this article. It's almost literally everything from the "OK, But What, Then?" section. I did read it. I didn't want to go into depth debunking every single sentence OP wrote because I thought it would be obnoxious, but I'll write a bit more. > The TLDR is there isn't a one-size-fits-all. That's what I mean - the author gives no prescription. Saying there is no one-size-fits-all is not a prescription. I'll respond to a specific quote the author said, which I believe to be the crux of his suggestion: > Teams that have grounded their product decisions appropriately can productively work through the narrow form by running truly objective bakeoffs. Most teams do not have the privilege of being able to "ground their product decisions appropriately". Most teams - at least those in small to mid-size startups - will start out building A, route through A' and A'' and end up building B once they land on PMF. If you ran a "bakeoff" on A, you're going to be a bit upset when you end up at A' and probably run horribly technically aground when you truly find the right thing to build. Yes, if at the point when you discover B you have the latitude to rewrite your entire codebase to fit your new criteria, then by all means, go ahead. That will definitely outperform React. I think the teams with that kind of latitude is an exceptionally small fraction of all teams, and the number of teams with the technical chops to do it correctly will be an even smaller fraction of that. The rest of us will use React, which is roughly 80% as good as the optimal solution. Oh and, yes, if you work at a huge company who has found PMF and has the latitude to rewrite your code into whatever the optimal solution is, don't let me stop you. That is what Google and Facebook did, after all. I just don't think many of us are Google or Facebook.

LtWorf 2y ago

> But front end performance issues are almost never the most pressing issue Tell me your websites are unbearably slow without telling me your websites are unbearably slow :D

johnfn 2y ago
I've spent plenty of time optimizing performance. It almost always comes down to a backend issue, unless the frontend is doing something profoundly stupid, like making multiple API requests in serial when they could be batched or parallelized.
- LtWorf 2y ago
  Yes because loading 500 different css and js files is not a problem for performance.
  - smrq 2y ago
    They literally just said "unless the frontend is doing something profoundly stupid".
    - yawaramin 2y ago
      That's the norm in the React world nowadays. You should take a look at https://infrequently.org/2024/08/object-lesson/ https://infrequently.org/2024/08/object-lesson/
      - johnfn 2y ago
        This article is better, but has very little to do with React. The major issues I see are 1) loading a 2.5 MB AWS library (not React), 2) not doing SSR (not React) and 3) not tree shaking (not React). I agree these are all problems. But shouting to the skies about React is not going to solve them.
        2y ago

xcrunner529 2y ago

They’re not problems most people have because they shouldn’t be using React or maybe even a SPA-type site in the first place! I think that’s one of the big points regardless. Just using react and it’s bloat to be hip and it not actually doing anything better or more performant for the use case of a shopping site. It’s not a CAD app or web office suite.

gnulinux996 2y ago

> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. Try opening facebook.com; click the messenger, (+1 second) Click one of your chat groups (~2 seconds) This is merely just to show something From what I have seen, its quite easy to have performance issues with React

reshlo 2y ago
So easy in fact that even the company that makes React can’t use it in a way that makes their site fast.
johnfn 2y ago
That doesn't say much about React, though. Indeed, you can open the network panel and watch requests go by over the seconds that it takes to open, suggesting that the issue likely resides on the backend.
- gls2ro 2y ago
  So the company that invented it does not know how to properly use it? Or are you implying that React does not fit FB use case?
  - Wool2662 2y ago
    He's literally saying the front end technology doesn't matter at all in this. Are you just going to defend React to the bitter end? Or do you just enjoy imaginary binary choices?
    - gls2ro 2y ago
      I think I was not clear in my question: I don't defend React. My question was almost the opposite and I was trying to ask: So if even Facebook has a problem with using React then who has a better examplea about why and how to use it?
      - 2y ago

ramones13 2y ago

To your third point - the author would recommend doing research and prototyping with all the options you might consider based on your use-cases. He actively avoids being prescriptive in generic contexts like this because he wants to avoid arbitrary dogmatic solutions (like React tends to be). Source: I work closely with him and have been frustrated with this stance until I saw people using Next and Remix for things like landing or contact pages.

johnfn 2y ago
(Sorry, somewhat copying this, since I responded to a similar point elsewhere.) This is not practical advice for the vast majority of software engineering teams. Most teams do not have the privilege of being able to do research and prototypes across multiple options, at least in a way representative of what their final product will look like. Most teams - at least those in small to mid-size startups - will start out building A, route through A' and A'' and end up building B once they land on PMF. If you were to run 5 different prototypes on A, you're going to be a bit upset when you end up at A' and you're likely to run horribly technically aground when you truly find the right thing to build. Yes, if at the point when you discover B you have the latitude to rewrite your entire codebase to fit your new criteria, then by all means, go ahead. That will definitely outperform React. I think the teams with that kind of latitude is an exceptionally small fraction of all teams, and the number of teams with the technical chops to do it correctly will be an even smaller fraction of that. The rest of us will use React, which is roughly 80% as good as the optimal solution.
- ramones13 2y ago
  My experiences don’t really align with yours - most people are playing “follow the leader” with tech - “X uses Y, so we should to” and that’s it. To your point though - use the platform. Vanilla HTML, CSS, and JS. All of that will be reusable no matter where you pivot and not lock you in to a pattern that might not work well for where you land.
  - johnfn 2y ago
    > Vanilla HTML, CSS, and JS This is a non-answer. It only really is an admissible solution if you're just working by yourself. React solves real problems when building web applications. If you use vanilla HTML, CSS and JS, you're going to have to solve those same problems. How are you going to do it? How are you going to manage state? How are you going to synchronize your state with the DOM? How are you going to organize your components? Teams that use vanilla HTML, CSS, and JS end up eventually building an internal, buggy, half-implemented, undocumented version of React.

rkagerer 2y ago

I hate what "modern" web development has done to my UI experience. Eg. There's a delay between an Amazon.ca results page loading and it populating the search text box with the phrase you just searched for. As a result when I do two searches in rapid succession, it consistently interrupts my typing at exactly the right time to batter in incomprehensible text. AirCanada and WestJet are two other websites that became awful to use after adopting React-ey style UI's.

kccqzy 2y ago
There's no React-ey style UI. Seriously. It's a UI framework not a collection of prebuilt UI components. You cannot tell if a site is using React or not without opening dev tools.
- trog 2y ago
  I might not be able to tell if it's using React specifically, but I can tell it's using a React-like framework trivially because it feels like the entire website is covered in glue
  - kccqzy 2y ago
    No. You are just dealing with bad code. There are highly performant web apps written in React. It's all about craftsmanship. React gives you many tools to skip unnecessary work and reduce latency, such as shouldComponentUpdate, and assigning keys to elements in a collection. Or architectural decisions like splitting your UI into components correctly. It's up to the individual developers to use them. Bad developers write bad code in any framework. But one thing I've noticed is that because frontend code runs on users' computers, fewer businesses and engineers have the incentive to really optimize that performance. If one writes bad backend code, it shows up as increased AWS bill; if one writes bad frontend code, well the cost is diffuse and many don't notice it.
    - trog 2y ago
      > No. You are just dealing with bad code. There are highly performant web apps written in React. cool maybe I'll see one one day > React gives you many tools to skip unnecessary work and reduce latency, such as shouldComponentUpdate, and assigning keys to elements in a collection but do people use these outside of demos I have an high end CPU with 32GB of RAM and almost every single website I use gives me a worse experience than I got 20 years ago > if one writes bad frontend code, well the cost is diffuse and many don't notice it. exactly, and that's why we are where we are today - surrounded on all sides by websites covered in glue, because bad experience has been completely normalised, all for what? Some abstract notion of developer convenience that results in almost every case in a significantly worse experience by almost any metric.

beeflet 2y ago

> hundreds of milliseconds. Yes, there are a few specialized domains where this will matter. No, you probably don’t work in one. This is funny to me, because I would think that for hundreds of milliseconds, anything user-facing is impacted. It's on the order of the human reaction time (~200ms). That's noticeable delay. I do not work in frontend, so perhaps I am misguided. But I have had bad user experience using apps with even 100ms delay that require a lot of input (for example using excel or something in a streaming VM).

maigret 2y ago
You are not misguided. Physiology is mostly intangible but consistent. Many of the comments here willingly ignore that “yes but my use case is different and my users are patient”. Their brain will still disconnect quickly and be frustrated.

wordofx 2y ago

In 2024. React is probably the worst choice you could make when creating a new web application.

vessenes 2y ago
...and the best would be?
cheema33 2y ago
For static web page, it would be tough to beat html/css. But if you are building a web application of some complexity, it would be tough to beat React. You can totally shoot yourself in the foot with any language or framework. And you can most certainly do that with React as well. As we so often see.

diob 2y ago

Yeah, poor performance is possible in any system using any tech. Being able to diagnose it and fix it is what matters. I've never had a performance issue I couldn't fix in React.

gls2ro 2y ago
I think the question that we are discussing here is: What amount of performance issues you will not need to fix if you were not using React to begin with?

slotrans 2y ago

> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. Many years ago I worked at a wonderful company that made the terrible decision to rebuild the frontend in React. We had a performance dashboard permanently displayed on a TV in the office, prominently showing the p99 time-to-interactive of our home page. It sat at TWENTY SECONDS for at least 2 years. No progress was ever made, to the best of my knowledge. This was an e-commerce site, more or less. As per the author's reasoning, it absolutely should not have been an SPA.

gf000 2y ago
E-commerce sites are a pretty good fit for SPAs. Sounds like a bad rewrite, nothing more, nothing less.
- exceptione 2y ago
  Why do you think that? The only client side component of interest would be filtering and sorting, (although the server could render the new state too). I would choose traditional server side + a little bit of client side code here.
  - deleted 2y ago
    [deleted]

59nadir 2y ago

There really are only a handful of things you could do that should passably take "hundreds of milliseconds" and loading a web page is not among them. Neither is displaying a few hundred thousand things on a screen, least of all what are essentially rects in 2D. The only reason any of the above sounds fine to take this long is because the standards of web development are so incredibly low.

bryanrasmussen 2y ago
sure if you have the access directly to drawing those rects in 2D, but if you are using a library to do drawing of the rects you may have a small tradeoff of time (obviously not 100s of milliseconds) and if you are using a library that abstracts away writing to the DOM for you and then the browser takes the DOM and essentially figures out how to draw a hundred thousand things on the screen you might get in the hundred milliseconds area - depending on a whole bunch of things that are varying from time to time. The only reason that 100s of milliseconds might sound fine is because there are multiple layers of abstraction between levels, but as you can see from all the other responses here the 100s of milliseconds evidently does not sound fine.

grey-area 2y ago

> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. This is not my experience on real react sites. Loading the pages on mobile (say 4G) takes seconds to load with a partially rendered page which is slowly constructed. Loading the equivalent pages in HTML rendered server side would reliably be under 100ms (excluding assets). This is somewhat disguised by better connections and large images taking up, but all that js and json does have a cost. You're probably trying to talk about the overhead of the framework, but what is the true overhead of a framework which encourages you to introduce bloat and create a separate component file and sometimes a separate network connection for every single component on your web page? Here is a real case study with comparison of approaches from this author: https://infrequently.org/2024/08/object-lesson/ https://infrequently.org/2024/08/object-lesson/ >The second reason the author says is that it’s based on a legacy eventing system which supports IE. There are lots of horrible bits of react which are based on solving problems which aren't really a problem on the web any more - from manipulating the dom (pretty easy without react) to dealing with IE polyfills, and lots of bits that you really don't need the client to concern itself with (i.e. routing code). You may not care about that code but you are importing it and forcing your users to download it. It all adds to overhead. There are also a ton of other points in the article which you've elided, which go into the multiple failings of React as a tool, and primary among them is that it encourages you to use react and only react, the ultimate in lock-in. > Finally, the author doesn’t actually give a prescription as to what to use instead of React. You want them to choose one framework instead of react, they're explicitly rejecting that choice and saying you don't have to become a follower of react or any other religion, instead they're advocating choosing tools based on the evidence they have presented, so they are IMO presenting a clear choice: Server side rendering with a bit of js as required to load dynamic data React or similar frameworks which try to push everything to the client

mvdtnz 2y ago

> But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. I'm guessing you're one of those developers who never browses the web on anything but the latest Macbook Pro and iPhone. I implore you to restrict yourself to some lower end devices for a few weeks and let us know if you still feel the same way.

jazzypants 2y ago
I generally agree with you, but I have a budget cell phone (~$100) and I can run StackBlitz on it without it even blinking. I think budget cell phones have gotten a lot better than most people think.