5 ms·

> A complex page can have up to 60,000 DOM nodes under React's control with thousands of event listeners. It starts in about 3s and never drops below 60fps Can

by lgl 6y ago

> A complex page can have up to 60,000 DOM nodes under React's control with thousands of event listeners. It starts in about 3s and never drops below 60fps Can one really make such affirmations regarding client rendered web apps? I'm assuming these numbers aren't solely measured on localhost in some state of the art development machine/device so won't it depend on the client's machine specs, browser, usage, bandwidth, etc?

schwartzworld 6y ago
I don't know what bandwidth has to do with react managing the DOM.
- onion2k 6y ago
  A naively built app will do things like take some user input from a form, send it off to an API and await the response, and then update the UI when if the request is successful or display an error if there's a problem. That means the user has to wait for the request to complete before moving on to their next task. In other words, the DOM update waits for the network. If you have a slow connection that feels horrible (snarky frontend dev note - if you build a server-side rendered app it's how everything in the app works. Sucks if you have a slow connection.) It's better for the user if the UI assumes the request has been successful and updates the UI with a temporary success state, and then undoes the update if the request fails and gives the user the option to recover their update and try again. Most of the time there won't be a problem (especially with good client side validation) so they'll never see the recover state, and they'll never need to wait for a network request to finish either. Obviously you shouldn't use that sort of UX pattern for critical things though.
  - mattmanser 6y ago
    Ugh, this has got to be one of my biggest bugbears with SPAs. This pattern fails far more than you obviously think it does, and when it does fail, it's usually handled so poorly it's worse than the 'cure' you're peddling. Give me a clean, server-side form submission any day over the "has it worked, hasn't it?" inconsistency of SPAs.
krzepah 6y ago
This is how i manage more than 60,000 DOM nodes https://github.com/developit/preact-virtual-list https://github.com/developit/preact-virtual-list ; actually i think i could handle 600,000 and still have no problem.
- Kuinox 6y ago
  You just removed an usefull features from the user. The virtual list make ctrl+f not working anymore, and I hate every single react page using it. Suddendly, on this webpage using virtual list, you ctrl+f something, dont find it, because the element does not exist. A vue or angular manage your 60k elements list without any issue, you dont need to virtualize your list, and the search feature your your browser keep working. And if your don't use a virtual list, react get performance issues starts when you get only a few hundreds of elements and you want to filter them. Also, it start 'instantly' with other frameworks, not in 3 seconds, but below 500ms.
  - krzepah 6y ago
    There is a find feature in the specs already. My users actually need to be able to interact with a lot of rows. I can just bind ctrl-f to my search feature. Also, it doesn't take 3 seconds to load but few ms as well. See, you don't just pick a tech, you need to start from the specs and get what the user need. Also, in pure HTML (because i tried it) ; the same rendering would be hanging anytime you try to act on something.
    - Kuinox 6y ago
      Now it doesnt work: - On mobile, using menu to search in browser menus. - When users use F3 to search, an alternative to ctrl+f. You added a few bytes to reimplement a browser feature, and spend time on a feature that already exist, because of your tech choice. There is still probably some accessibility issues. You can have easily 60k rows in HTML without any performance issue, you just need to pay attention...
      - 6y ago

by lgl 6y ago

schwartzworld 6y ago

I don't know what bandwidth has to do with react managing the DOM.

onion2k 6y ago
A naively built app will do things like take some user input from a form, send it off to an API and await the response, and then update the UI when if the request is successful or display an error if there's a problem. That means the user has to wait for the request to complete before moving on to their next task. In other words, the DOM update waits for the network. If you have a slow connection that feels horrible (snarky frontend dev note - if you build a server-side rendered app it's how everything in the app works. Sucks if you have a slow connection.) It's better for the user if the UI assumes the request has been successful and updates the UI with a temporary success state, and then undoes the update if the request fails and gives the user the option to recover their update and try again. Most of the time there won't be a problem (especially with good client side validation) so they'll never see the recover state, and they'll never need to wait for a network request to finish either. Obviously you shouldn't use that sort of UX pattern for critical things though.
- mattmanser 6y ago
  Ugh, this has got to be one of my biggest bugbears with SPAs. This pattern fails far more than you obviously think it does, and when it does fail, it's usually handled so poorly it's worse than the 'cure' you're peddling. Give me a clean, server-side form submission any day over the "has it worked, hasn't it?" inconsistency of SPAs.

krzepah 6y ago

This is how i manage more than 60,000 DOM nodes https://github.com/developit/preact-virtual-list https://github.com/developit/preact-virtual-list ; actually i think i could handle 600,000 and still have no problem.

Kuinox 6y ago
You just removed an usefull features from the user. The virtual list make ctrl+f not working anymore, and I hate every single react page using it. Suddendly, on this webpage using virtual list, you ctrl+f something, dont find it, because the element does not exist. A vue or angular manage your 60k elements list without any issue, you dont need to virtualize your list, and the search feature your your browser keep working. And if your don't use a virtual list, react get performance issues starts when you get only a few hundreds of elements and you want to filter them. Also, it start 'instantly' with other frameworks, not in 3 seconds, but below 500ms.
- krzepah 6y ago
  There is a find feature in the specs already. My users actually need to be able to interact with a lot of rows. I can just bind ctrl-f to my search feature. Also, it doesn't take 3 seconds to load but few ms as well. See, you don't just pick a tech, you need to start from the specs and get what the user need. Also, in pure HTML (because i tried it) ; the same rendering would be hanging anytime you try to act on something.
  - Kuinox 6y ago
    Now it doesnt work: - On mobile, using menu to search in browser menus. - When users use F3 to search, an alternative to ctrl+f. You added a few bytes to reimplement a browser feature, and spend time on a feature that already exist, because of your tech choice. There is still probably some accessibility issues. You can have easily 60k rows in HTML without any performance issue, you just need to pay attention...
    - 6y ago