6 ms·

I agree with most of what you say, but your conclusion: > Its paradigm is a beautiful one to develop with in most ways, but there is a significant price to pay

by davedx 7y ago

I agree with most of what you say, but your conclusion: > Its paradigm is a beautiful one to develop with in most ways, but there is a significant price to pay in terms of performance. I've worked with React on-and-off since around 2013. I can count on one hand the number of times that out-of-the-box idiomatic React code has incurred a significant price in terms of performance. The majority of my React apps just work, they just render fast enough by default. One time I've had to optimize it was when I had a React app that displayed a page of items from the database without any pagination: once it got to a few hundred items, it would indeed render very slowly. My optimization here was actually not to start memoizing or implement componentShouldUpdate -- it was to implement pagination and search in the app, because the UX was more important than rendering speed, and solving the UX solved the render speed. I don't understand what kind of apps people are building with React that incur these significant rendering performance costs? I could understand it if you're building a realtime cryptocurrency exchange dashboard but I don't think most people are doing that?

azangru 7y ago
I saw in a recent tweet (can't find now) that React-based web apps were draining mobile phone batteries significantly faster than the comparison, because, with the constant re-renders, they were generating a heavier CPU load. This is something I had never thought about before.
- davedx 7y ago
  It makes sense, if it's changing very quickly and re-rendering the whole component tree -- say it's some kind of realtime stream of updates or a graphql subscription. And then of course you should try and optimize so only that component is re-rendered. My main argument is against people who try to argue that you should memoize a form input field or a div or something that changes once every few seconds or so. It's just pointless.
- runawaybottle 7y ago
  That app could be just as battery draining as a vue or angular app. We’d have to know the details.
mhenr18 7y ago
I work on an app that edits and renders fairly complex indoor floorplans to SVG, all using React. We deal with large hospitals and airports, so it's normal for us to have tens of thousands of components mounted at once - pagination isn't a viable solution for our purposes. We've had to tap basically every optimization that React apps can do when managing large numbers of elements - however this has been worth it for us: - We can use the same code to render interactive plans on the client, and to render to print-quality PDFs on the server - We can use the same framework in our UI and plan rendering The downside is that it's more CPU intensive than alternatives like a WebGL renderer, but for now that's a tradeoff worth making.
- mncharity 7y ago
  > more CPU intensive than alternatives like a WebGL renderer, but for now that's a tradeoff worth making Mixing traditional React with WebGL is another option. There's react-three-fiber[1], and custom/simpler hybrids are also possible. Though I've not tried server-side rendering. [1] https://github.com/react-spring/react-three-fiber https://github.com/react-spring/react-three-fiber
simion314 7y ago
IMO pagination is garbage UX, any sane GUI tookit can render more then 100 items on screen. Imagine you text editor or spreeadsheet viewer would have a limit of 100 rows. Sane GUIs don't create all this rows widgets from the start but use smarter techniques. From what I seen this technique is called now "windowing" but I knew it before by the name of "render item recycling"
- danShumway 7y ago
  > any sane GUI tookit can render more then 100 items on screen Sure, but it's uncommon that I want more than 100 items on a screen in a webapp. Infinite scroll is not an antipattern, but it is something that people should be a little bit cautious of. Users like context and clear anchors -- I like to be able to hit a back/forward button and know where I'll end up. I also like pages to load quickly and not make a ton of background requests on mobile connections, so if I can have an initial page load under a few megabytes at max, and can wait for the user to request data before loading it -- that's sometimes an attractive proposition. Multiple search engines used to experiment with infinite scrolling and virtual rows, and as far as I know, most of the big ones went back to pagination, and I think it's because sometimes pagination is genuinely better UX, particularly when you're scrolling through a long list of blog posts or search results. Of course you can put thousands of elements in the DOM, and you can implement virtual scrolling if you need tens of thousands or millions. But the DOM tree is ultimately meant to be a human-traversable interface, and a <ul> element with several thousand <li>s beneath it is arguably not very traversable. There are no hard rules here and there are a lot of caveats to what I'm about to say -- but I now bias towards avoiding DOM trees that are so big that I couldn't stick the current tree in a text editor and mostly consume its content textually, and that includes on dynamic web apps. The current state I'm displaying to the user should be small enough that the user can wrap their head around it. The fact that React is so slow that you basically need to at least occasionally think about how you're rendering state is a separate conversation.
  - TeMPOraL 7y ago
    > Sure, but it's uncommon that I want more than 100 items on a screen in a webapp. Infinite scroll is not an antipattern, but it is something that people should be a little bit cautious of. Having ~100-200 items, I'd damn love to have them all on the screen. It seems like the best option out of the trio of render all, pagination or infinite scroll. Pagination is faster than infinite scroll, infinite scroll is more convenient than pagination, but both make it hard to reliably display data in sequence (as the whole data set isn't loaded immediately anymore) - and more importantly, both break search. However bad and bare-bones searching is in the browser, it's still better than search reimplementations in web apps, because the latter aren't any more sophisticated, and also have limited scope. That's just my opinion, and a point of annoyance with modern SPAs. Most of the time when I have to scroll a lot, or traverse a bunch of pages, all I really want is to be able to CTRL+F for the thing I'm looking for without changing the state of the application.
nothis 7y ago
>I don't understand what kind of apps people are building with React that incur these significant rendering performance costs? I could understand it if you're building a realtime cryptocurrency exchange dashboard but I don't think most people are doing that? I think it's just easy to make mistakes (bad loops, overly trigger-happy interpretations of "state change", etc), especially for all things "lists" (which make up half the web). Since people make mistakes, I'd always consider easy-to-make mistakes a design flaw, in this case affecting performance. Also there's a psychological cost to making incremental "loading" operations visible. Although some mysterious "research" is frequently cited that people just fucking LOVE spinning loading icons and gray placeholder boxes that are never where the actual content will pop in, it's just instantly making my perception of a site slower. If a website just takes 5 seconds to load, okay. If, during that time, it just pops in and out 50 components, 3 different loading bars, spinning whirlies and blurry placeholder images (where the one I actually want to see always loads last), I'm suddenly having a "delay experience". It's like a whole firework of bullshit happening to remind you the site HAS NOT loaded yet.

by davedx 7y ago

azangru 7y ago

I saw in a recent tweet (can't find now) that React-based web apps were draining mobile phone batteries significantly faster than the comparison, because, with the constant re-renders, they were generating a heavier CPU load. This is something I had never thought about before.

davedx 7y ago
It makes sense, if it's changing very quickly and re-rendering the whole component tree -- say it's some kind of realtime stream of updates or a graphql subscription. And then of course you should try and optimize so only that component is re-rendered. My main argument is against people who try to argue that you should memoize a form input field or a div or something that changes once every few seconds or so. It's just pointless.
runawaybottle 7y ago
That app could be just as battery draining as a vue or angular app. We’d have to know the details.

mhenr18 7y ago

I work on an app that edits and renders fairly complex indoor floorplans to SVG, all using React. We deal with large hospitals and airports, so it's normal for us to have tens of thousands of components mounted at once - pagination isn't a viable solution for our purposes. We've had to tap basically every optimization that React apps can do when managing large numbers of elements - however this has been worth it for us: - We can use the same code to render interactive plans on the client, and to render to print-quality PDFs on the server - We can use the same framework in our UI and plan rendering The downside is that it's more CPU intensive than alternatives like a WebGL renderer, but for now that's a tradeoff worth making.

mncharity 7y ago
> more CPU intensive than alternatives like a WebGL renderer, but for now that's a tradeoff worth making Mixing traditional React with WebGL is another option. There's react-three-fiber[1], and custom/simpler hybrids are also possible. Though I've not tried server-side rendering. [1] https://github.com/react-spring/react-three-fiber https://github.com/react-spring/react-three-fiber

simion314 7y ago

IMO pagination is garbage UX, any sane GUI tookit can render more then 100 items on screen. Imagine you text editor or spreeadsheet viewer would have a limit of 100 rows. Sane GUIs don't create all this rows widgets from the start but use smarter techniques. From what I seen this technique is called now "windowing" but I knew it before by the name of "render item recycling"

danShumway 7y ago
> any sane GUI tookit can render more then 100 items on screen Sure, but it's uncommon that I want more than 100 items on a screen in a webapp. Infinite scroll is not an antipattern, but it is something that people should be a little bit cautious of. Users like context and clear anchors -- I like to be able to hit a back/forward button and know where I'll end up. I also like pages to load quickly and not make a ton of background requests on mobile connections, so if I can have an initial page load under a few megabytes at max, and can wait for the user to request data before loading it -- that's sometimes an attractive proposition. Multiple search engines used to experiment with infinite scrolling and virtual rows, and as far as I know, most of the big ones went back to pagination, and I think it's because sometimes pagination is genuinely better UX, particularly when you're scrolling through a long list of blog posts or search results. Of course you can put thousands of elements in the DOM, and you can implement virtual scrolling if you need tens of thousands or millions. But the DOM tree is ultimately meant to be a human-traversable interface, and a <ul> element with several thousand <li>s beneath it is arguably not very traversable. There are no hard rules here and there are a lot of caveats to what I'm about to say -- but I now bias towards avoiding DOM trees that are so big that I couldn't stick the current tree in a text editor and mostly consume its content textually, and that includes on dynamic web apps. The current state I'm displaying to the user should be small enough that the user can wrap their head around it. The fact that React is so slow that you basically need to at least occasionally think about how you're rendering state is a separate conversation.
- TeMPOraL 7y ago
  > Sure, but it's uncommon that I want more than 100 items on a screen in a webapp. Infinite scroll is not an antipattern, but it is something that people should be a little bit cautious of. Having ~100-200 items, I'd damn love to have them all on the screen. It seems like the best option out of the trio of render all, pagination or infinite scroll. Pagination is faster than infinite scroll, infinite scroll is more convenient than pagination, but both make it hard to reliably display data in sequence (as the whole data set isn't loaded immediately anymore) - and more importantly, both break search. However bad and bare-bones searching is in the browser, it's still better than search reimplementations in web apps, because the latter aren't any more sophisticated, and also have limited scope. That's just my opinion, and a point of annoyance with modern SPAs. Most of the time when I have to scroll a lot, or traverse a bunch of pages, all I really want is to be able to CTRL+F for the thing I'm looking for without changing the state of the application.

nothis 7y ago

>I don't understand what kind of apps people are building with React that incur these significant rendering performance costs? I could understand it if you're building a realtime cryptocurrency exchange dashboard but I don't think most people are doing that? I think it's just easy to make mistakes (bad loops, overly trigger-happy interpretations of "state change", etc), especially for all things "lists" (which make up half the web). Since people make mistakes, I'd always consider easy-to-make mistakes a design flaw, in this case affecting performance. Also there's a psychological cost to making incremental "loading" operations visible. Although some mysterious "research" is frequently cited that people just fucking LOVE spinning loading icons and gray placeholder boxes that are never where the actual content will pop in, it's just instantly making my perception of a site slower. If a website just takes 5 seconds to load, okay. If, during that time, it just pops in and out 50 components, 3 different loading bars, spinning whirlies and blurry placeholder images (where the one I actually want to see always loads last), I'm suddenly having a "delay experience". It's like a whole firework of bullshit happening to remind you the site HAS NOT loaded yet.