5 ms·

Isn’t React slow, only able to manage tables of a few dozen rows before slowing down to hell, hence starting the trend of tables paginated by 10 rows only? Isn’

Isn’t React slow, only able to manage tables of a few dozen rows before slowing down to hell, hence starting the trend of tables paginated by 10 rows only? Isn’t that the cost of hooks?

fabian2k 5y ago
React doesn't have an inherent problem with larger tables, and there are quite a few libraries to virtualize long lists or tables if yours are very large and you need the performance. React performance can be a bit tricky to handle if you don't understand how React rendering works and when React will render. But that's not really different from most things, performance is something that you often cannot abstract away entirely.
awestroke 5y ago
I've written code that would have been incredibly hard be made performant without React. With React, vittualizing rendering to only render visible elements is a breeze thanks to the inherent composability of react components, and now also hooks. React is not the performance bottleneck, the DOM is
- dotancohen 5y ago
  > React is not the performance bottleneck, the DOM is. I think that's pushing the blame just a layer too deep. It's like saying that engines are not holding up hypersonic missile development, the thick atmosphere is.
  - awestroke 5y ago
    No, it's the truth. Whether you use react or vanilla js, creating 10 000 complex element trees is going to take a lot of time due to the DOM recalculating layout and redrawing between every DOM operation. React makes it easy to draw less through virtualization. Virtualization is very hard to implement in a non-declarative way
    - laurent92 5y ago
      I can easily build a table in HTML with 70k cells (100 columns, 700 lines, it does happen, and users prefer that when getting an overview of their project), but in React, it takes 15s to render. Setting the innerHtml takes milliseconds.
      - awestroke 5y ago
        Just use something like react-virtualized. Problem solved
        afiori 5y ago
        it remains true that react is unable to use the DOM at its full performance regardless of virtualization. part of it is that after all react is a library and not a compiler (which is good per se, I like that you could use react with only vanilla .js and .mjs files or even once big HTML file) which means that for the react runtime components are black boxes and cannot be statically analyzed nor statically optimized. in the case of a table with 70k rows, even if the component only returned one jsx without any computation react would have to run the same diffing algorithms (this could be solved with a useMemo, but not always)
- austincheney 5y ago
  That isn’t just disagreeable, it’s measurably wrong. The DOM is insanely fast when you aren’t lazy, such as using query selectors. https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc A trillion unnecessary and never removed event listeners will also destroy your performance. Event listeners are an extra layer of abstraction that you can live without if you know what you are doing. That’s a big unlikely if. React is not really a performance bottleneck either but it also certainly isn’t a performance benefit. This is that immaturity the article speaks to.
  - awestroke 5y ago
    I am talking about DOM manipulation operations such as creating and updating elements. See my other comment. React does not query the DOM at all (almost), so query speed is irrelevant
    - austincheney 5y ago
      DOM operations are just a few common methods such as: appendChild, removeChild, setAttribute, getAttribute, removeAttribute, createElement, createTextNode. These were slow when injecting massive quantities of new nodes more than 12 years ago. Now they are fast. If you are that concerned with speed then just produce everything in a document fragment and when ready inject the document fragment into the document. Bottleneck bypassed. React won't solve for that bottleneck because it is still JavaScript beholden to the DOM just the same.
      - afiori 5y ago
        how do you replace event listeners? attach all of them at the document root and wait for bubbling/capture? attach single event listeners somewhere and then dispatch manually? use onclick="..." attributes? or maybe are you referring to native functionality like actually using semantic elements and using links and forms for page actions (with a service worker I believe you can make a nojs website quite interactive even offline) I believe I am not exactly "know what I am doing" at least when it comes to implementation, so I would enjoy some clarifications
- barbarbar 5y ago
  React does not seem fast in this benchmark https://krausest.github.io/js-framework-benchmark/2021/table_chrome_94.0.4606.54.html https://krausest.github.io/js-framework-benchmark/2021/table...

Isn’t React slow, only able to manage tables of a few dozen rows before slowing down to hell, hence starting the trend of tables paginated by 10 rows only? Isn’t that the cost of hooks?

fabian2k 5y ago

React doesn't have an inherent problem with larger tables, and there are quite a few libraries to virtualize long lists or tables if yours are very large and you need the performance. React performance can be a bit tricky to handle if you don't understand how React rendering works and when React will render. But that's not really different from most things, performance is something that you often cannot abstract away entirely.

awestroke 5y ago

I've written code that would have been incredibly hard be made performant without React. With React, vittualizing rendering to only render visible elements is a breeze thanks to the inherent composability of react components, and now also hooks. React is not the performance bottleneck, the DOM is

dotancohen 5y ago
> React is not the performance bottleneck, the DOM is. I think that's pushing the blame just a layer too deep. It's like saying that engines are not holding up hypersonic missile development, the thick atmosphere is.
- awestroke 5y ago
  No, it's the truth. Whether you use react or vanilla js, creating 10 000 complex element trees is going to take a lot of time due to the DOM recalculating layout and redrawing between every DOM operation. React makes it easy to draw less through virtualization. Virtualization is very hard to implement in a non-declarative way
  - laurent92 5y ago
    I can easily build a table in HTML with 70k cells (100 columns, 700 lines, it does happen, and users prefer that when getting an overview of their project), but in React, it takes 15s to render. Setting the innerHtml takes milliseconds.
    - awestroke 5y ago
      Just use something like react-virtualized. Problem solved
      - afiori 5y ago
        it remains true that react is unable to use the DOM at its full performance regardless of virtualization. part of it is that after all react is a library and not a compiler (which is good per se, I like that you could use react with only vanilla .js and .mjs files or even once big HTML file) which means that for the react runtime components are black boxes and cannot be statically analyzed nor statically optimized. in the case of a table with 70k rows, even if the component only returned one jsx without any computation react would have to run the same diffing algorithms (this could be solved with a useMemo, but not always)
austincheney 5y ago
That isn’t just disagreeable, it’s measurably wrong. The DOM is insanely fast when you aren’t lazy, such as using query selectors. https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc A trillion unnecessary and never removed event listeners will also destroy your performance. Event listeners are an extra layer of abstraction that you can live without if you know what you are doing. That’s a big unlikely if. React is not really a performance bottleneck either but it also certainly isn’t a performance benefit. This is that immaturity the article speaks to.
- awestroke 5y ago
  I am talking about DOM manipulation operations such as creating and updating elements. See my other comment. React does not query the DOM at all (almost), so query speed is irrelevant
  - austincheney 5y ago
    DOM operations are just a few common methods such as: appendChild, removeChild, setAttribute, getAttribute, removeAttribute, createElement, createTextNode. These were slow when injecting massive quantities of new nodes more than 12 years ago. Now they are fast. If you are that concerned with speed then just produce everything in a document fragment and when ready inject the document fragment into the document. Bottleneck bypassed. React won't solve for that bottleneck because it is still JavaScript beholden to the DOM just the same.
    - afiori 5y ago
      how do you replace event listeners? attach all of them at the document root and wait for bubbling/capture? attach single event listeners somewhere and then dispatch manually? use onclick="..." attributes? or maybe are you referring to native functionality like actually using semantic elements and using links and forms for page actions (with a service worker I believe you can make a nojs website quite interactive even offline) I believe I am not exactly "know what I am doing" at least when it comes to implementation, so I would enjoy some clarifications
barbarbar 5y ago
React does not seem fast in this benchmark https://krausest.github.io/js-framework-benchmark/2021/table_chrome_94.0.4606.54.html https://krausest.github.io/js-framework-benchmark/2021/table...