4 ms·

> it's uncommon that I want more than 100 items I believe the discussion is GUI items, not what you might consider data items. Look at this current Hacker News

> it's uncommon that I want more than 100 items I believe the discussion is GUI items, not what you might consider data items. Look at this current Hacker News page. Each comment, depending on how fine-grained you're counting, looks to have about 5-6 or more GUI components. In your browser viewport you may see a dozen comments. GUI components add up quickly. These are also only the components in view. React, however, is rendering the entire page. Easily hundreds of React components.

danShumway 6y ago
But depending on how they're styled and what animations you're using, React can easily handle rendering out 1000 DOM nodes. To be clear, I don't want to act like it's not a real concern, I've been in situations where the number of DOM elements I was rendering out with React ended up being a performance concern. It's a real thing. Heck, I've been in situations where React's insistence on computing the virtual DOM was a performance problem. One of the downsides of component-based architecture is that it's very easy to get into situations where you're completely pointlessly duplicating effort parsing data multiple times and passing it around between components and mapping it to new lists of data. It's a major weakness for systems like React that encourage you to loosely couple all of your components, even components that are inherently very related to each other. But I think people are underestimating what that component/DOM limit is, even for browsers like IE 11. If you have 100 items on screen, and it's causing the browser to slow down, you'd better be doing something at least somewhat complicated with those elements. You'd better be sticking some SVG charts in there or something. Otherwise I'm going to (perhaps uncharitably) accuse you of overcomplicating your DOM and inserting a bunch of nodes that don't need to exist. If someone wants to try and implement HN in React, they shouldn't be using 5-6 separate React components for a single comment, that's... I don't know how to parse that kind of architecture. I don't want to be dismissive about it, and different people have different approaches to programming -- but I feel pretty strongly that kind of granularity is over-engineering.
- simion314 6y ago
  Not OC but from my experience because you have some nested DIVs and spans and some other node elements for each data item when you first load your data you get a big hang/freeze because the browsers are still slow at creating this elements, this is a browser issue I think, because most of the time you want to have a big list of similar items there should not be such a giant work of creating and computing similar DOM elements but I assume because of how complex css engine is you get this giant freeze.
  - danShumway 6y ago
    Eh... you really shouldn't get a big hang/freeze if you're just talking about inserting 1000 nodes into the DOM. It's not going to be fast enough that you can do it at 60fps, but that's not the point of the DOM -- 60fps insertion is not something we care about. I mean, yes, some of this is dependent on CSS. If you're doing complex rendering, or doing something strange with your fonts. I'm not going to make absolute claims about performance in every case, and different people have different interactions and requirements they're dealing with. There's caveats. However, if someone comes to me and says, "I put 1000 DOM nodes into the browser and my page froze", I might not immediately make strong claims about the application, but I am going to immediately start looking around the codebase suspiciously to see if they're doing something strange or abnormal. The current HN page you're on right now has ~2500 DOM nodes. Does it freeze for you when you load the page? People complain a lot about DOM insertion, but while DOM insertion does sometimes cause problems, I've found it's more often that the problems happened before the insertion. At the point where DOM insertion actually becomes a problem, I suspect we're usually no longer talking about lists of 1000 simple table elements, or just putting 100 search results on a single page.
    - simion314 6y ago
      I am not sure what I did wrong, maybe if I had set some min/max height/width on soem elements it would have improved the performance, or maybe if i changed some flex-box property so regular layout or maybe if I changed some css rule on some parent somewhere it would have worked better. I am sure I can make a list with just text and not css I can insert 1000 text nodes in it, the issue is if you have something mroe complex like a grid with thumbnails and titles, and a small description under, and some css effect for hover, and a few buttons when you hover over those items etc. In a sane GUI this 1000 widgets are not created at all, only the visible ones are created and when you scroll the data under the Widget is swapped, this is great because you don't have to focus on performance or use pagination and then pretend pagination is better UX. Just to clarify I agree that there should not be many DOM nodes in a page, the browser or framework widget should be smart and transparently recycle the existing DOM elements, I imagine there would be some new List and Grid widgets that are more advanced but that could be used by everyone with his favorite framework.

danShumway 6y ago

But depending on how they're styled and what animations you're using, React can easily handle rendering out 1000 DOM nodes. To be clear, I don't want to act like it's not a real concern, I've been in situations where the number of DOM elements I was rendering out with React ended up being a performance concern. It's a real thing. Heck, I've been in situations where React's insistence on computing the virtual DOM was a performance problem. One of the downsides of component-based architecture is that it's very easy to get into situations where you're completely pointlessly duplicating effort parsing data multiple times and passing it around between components and mapping it to new lists of data. It's a major weakness for systems like React that encourage you to loosely couple all of your components, even components that are inherently very related to each other. But I think people are underestimating what that component/DOM limit is, even for browsers like IE 11. If you have 100 items on screen, and it's causing the browser to slow down, you'd better be doing something at least somewhat complicated with those elements. You'd better be sticking some SVG charts in there or something. Otherwise I'm going to (perhaps uncharitably) accuse you of overcomplicating your DOM and inserting a bunch of nodes that don't need to exist. If someone wants to try and implement HN in React, they shouldn't be using 5-6 separate React components for a single comment, that's... I don't know how to parse that kind of architecture. I don't want to be dismissive about it, and different people have different approaches to programming -- but I feel pretty strongly that kind of granularity is over-engineering.

simion314 6y ago
Not OC but from my experience because you have some nested DIVs and spans and some other node elements for each data item when you first load your data you get a big hang/freeze because the browsers are still slow at creating this elements, this is a browser issue I think, because most of the time you want to have a big list of similar items there should not be such a giant work of creating and computing similar DOM elements but I assume because of how complex css engine is you get this giant freeze.
- danShumway 6y ago
  Eh... you really shouldn't get a big hang/freeze if you're just talking about inserting 1000 nodes into the DOM. It's not going to be fast enough that you can do it at 60fps, but that's not the point of the DOM -- 60fps insertion is not something we care about. I mean, yes, some of this is dependent on CSS. If you're doing complex rendering, or doing something strange with your fonts. I'm not going to make absolute claims about performance in every case, and different people have different interactions and requirements they're dealing with. There's caveats. However, if someone comes to me and says, "I put 1000 DOM nodes into the browser and my page froze", I might not immediately make strong claims about the application, but I am going to immediately start looking around the codebase suspiciously to see if they're doing something strange or abnormal. The current HN page you're on right now has ~2500 DOM nodes. Does it freeze for you when you load the page? People complain a lot about DOM insertion, but while DOM insertion does sometimes cause problems, I've found it's more often that the problems happened before the insertion. At the point where DOM insertion actually becomes a problem, I suspect we're usually no longer talking about lists of 1000 simple table elements, or just putting 100 search results on a single page.
  - simion314 6y ago
    I am not sure what I did wrong, maybe if I had set some min/max height/width on soem elements it would have improved the performance, or maybe if i changed some flex-box property so regular layout or maybe if I changed some css rule on some parent somewhere it would have worked better. I am sure I can make a list with just text and not css I can insert 1000 text nodes in it, the issue is if you have something mroe complex like a grid with thumbnails and titles, and a small description under, and some css effect for hover, and a few buttons when you hover over those items etc. In a sane GUI this 1000 widgets are not created at all, only the visible ones are created and when you scroll the data under the Widget is swapped, this is great because you don't have to focus on performance or use pagination and then pretend pagination is better UX. Just to clarify I agree that there should not be many DOM nodes in a page, the browser or framework widget should be smart and transparently recycle the existing DOM elements, I imagine there would be some new List and Grid widgets that are more advanced but that could be used by everyone with his favorite framework.