3 ms·

"- Rendering too many DOM nodes at once - virtual lists help" Yup, despite all the improvements, the DOM is still slow and it is easy to make it behave even sl

by lukan 3y ago

"- Rendering too many DOM nodes at once - virtual lists help" Yup, despite all the improvements, the DOM is still slow and it is easy to make it behave even slower. Only update what is necessary and be aware of the performance bottleneck forced reflow. Every time you change anything and then get clientWidth for example and then change something else - you will make the DOM calculate(and posibly render) everything twice. I found the chrome dev tools to be really helpful with spotting those and other stuff. But sure, if you update EVERYTHING anyway, including waiting for the whole data transfer, with any click, when you just want some tiny parts refreshed, you have other problems anyway.

acdha 3y ago
> the DOM is still slow and it is easy to make it behave even slower I think this should be more nuanced: the DOM itself has been fast for 10-15 years but things like layout are still a concern on large pages. The problem is that the DOM, like an ORM, can make it easy to miss when you’re requesting the browser do other work like recalculating layout, and also that as people started using heavier frameworks they started losing track of what triggers updates. Lists are an interesting challenge because it’s surprisingly hard to beat a well-tuned browser implementation (overflow scrolling, etc.) but a lot of people still have the IE6 instincts and jump for implementing custom scrolling, only to find that there are a lot of native scrolling implementation features which are hard to match, and at some point they realize that what they really should have done was change the design to make layout easier to calculate (e.g. fixed or easily-calculated heights) or displayed fewer things at once.
- troupo 3y ago
  > I think this should be more nuanced: the DOM itself has been fast for 10-15 years It's faster than it was 10-15 years ago. It's still extremely slow. > things like layout are still a concern on large pages. > it easy to miss when you’re requesting the browser do other work like recalculating layout You can't say things like "DOM is fast" and "oh, it's fast if you exclude literally everything that people want to be fast". > and also that as people started using heavier frameworks they started losing track of what triggers updates. I don't know if you realise, but on the very same devices where you're complaining about "large pages and oh my god layout" people are routinely rendering millions of objects with complex logic and animations in under 5 milliseconds? The DOM is excruciatingly slow.
  - acdha 3y ago
    I think you’re using DOM to refer to the entire browser, not just what’s standardized as the DOM. Things like creating or modifying elements will run at tens of millions per second on an old iPhone _but_ there are operations like the one you mentioned which force the browser to do other work like style calculation and layout, and if you inadvertently write code which is something like “DOM update, force recalc, DOM update” in a loop it’s very easy to mistakenly think that the DOM is the source of the performance problem rather than things like the standard web layout process having many ways for different elements to interact. And, yes, I’m not unaware that different display models have different performance characteristics. Modern browsers can run into into the millions of objects range but fundamentally a web page is doing more work and there’s no way it’s going to match something which does less. This is why there have been various ways to turn off some of the expensive work (e.g. fixed table layout) and when APIs like canvas, WebGL, and WebGPU use different designs to allow people who need more control to avoid taking on costs their apps don’t need.
    - troupo 3y ago
      > I think you’re using DOM to refer to the entire browser, not just what’s standardized as the DOM. No, I'm referring to DOM as Document Object Model. > Things like creating or modifying elements will run at tens of millions per second on an old iPhone Not in the DOM :) > but fundamentally a web page is doing more work and there’s no way it’s going to match something which does less. That's why I'm saying that the DOM is not fast. It's excruciatingly slow even for the most basic of things. It's, after all, designed to display a small static page with one or two images, and no amount of haphazard hacks that accumulated on top of it over the years will change it. It will, actually, make it much worse :) There is a reason why the same device that can render a million of objects doing complex animations and logic in under 5ms cannot guarantee smooth animations in DOM. This is a good example: https://twitter.com/fabiospampinato/status/1749500897300730165 https://twitter.com/fabiospampinato/status/17495008973007301... (note: these are not complex animations and logic :) )
      - acdha 3y ago

by lukan 3y ago

acdha 3y ago

> the DOM is still slow and it is easy to make it behave even slower I think this should be more nuanced: the DOM itself has been fast for 10-15 years but things like layout are still a concern on large pages. The problem is that the DOM, like an ORM, can make it easy to miss when you’re requesting the browser do other work like recalculating layout, and also that as people started using heavier frameworks they started losing track of what triggers updates. Lists are an interesting challenge because it’s surprisingly hard to beat a well-tuned browser implementation (overflow scrolling, etc.) but a lot of people still have the IE6 instincts and jump for implementing custom scrolling, only to find that there are a lot of native scrolling implementation features which are hard to match, and at some point they realize that what they really should have done was change the design to make layout easier to calculate (e.g. fixed or easily-calculated heights) or displayed fewer things at once.

troupo 3y ago
> I think this should be more nuanced: the DOM itself has been fast for 10-15 years It's faster than it was 10-15 years ago. It's still extremely slow. > things like layout are still a concern on large pages. > it easy to miss when you’re requesting the browser do other work like recalculating layout You can't say things like "DOM is fast" and "oh, it's fast if you exclude literally everything that people want to be fast". > and also that as people started using heavier frameworks they started losing track of what triggers updates. I don't know if you realise, but on the very same devices where you're complaining about "large pages and oh my god layout" people are routinely rendering millions of objects with complex logic and animations in under 5 milliseconds? The DOM is excruciatingly slow.
- acdha 3y ago
  I think you’re using DOM to refer to the entire browser, not just what’s standardized as the DOM. Things like creating or modifying elements will run at tens of millions per second on an old iPhone _but_ there are operations like the one you mentioned which force the browser to do other work like style calculation and layout, and if you inadvertently write code which is something like “DOM update, force recalc, DOM update” in a loop it’s very easy to mistakenly think that the DOM is the source of the performance problem rather than things like the standard web layout process having many ways for different elements to interact. And, yes, I’m not unaware that different display models have different performance characteristics. Modern browsers can run into into the millions of objects range but fundamentally a web page is doing more work and there’s no way it’s going to match something which does less. This is why there have been various ways to turn off some of the expensive work (e.g. fixed table layout) and when APIs like canvas, WebGL, and WebGPU use different designs to allow people who need more control to avoid taking on costs their apps don’t need.
  - troupo 3y ago
    > I think you’re using DOM to refer to the entire browser, not just what’s standardized as the DOM. No, I'm referring to DOM as Document Object Model. > Things like creating or modifying elements will run at tens of millions per second on an old iPhone Not in the DOM :) > but fundamentally a web page is doing more work and there’s no way it’s going to match something which does less. That's why I'm saying that the DOM is not fast. It's excruciatingly slow even for the most basic of things. It's, after all, designed to display a small static page with one or two images, and no amount of haphazard hacks that accumulated on top of it over the years will change it. It will, actually, make it much worse :) There is a reason why the same device that can render a million of objects doing complex animations and logic in under 5ms cannot guarantee smooth animations in DOM. This is a good example: https://twitter.com/fabiospampinato/status/1749500897300730165 https://twitter.com/fabiospampinato/status/17495008973007301... (note: these are not complex animations and logic :) )
    - acdha 3y ago