4 ms·

> For massive apps with 1,000 components on the same page If have a 40X25 table on your page that's editable, that's your 1,000 components right there. But aw

> For massive apps with 1,000 components on the same page If have a 40X25 table on your page that's editable, that's your 1,000 components right there. But away from tables, it does seem overkill to have 1,000+ components on a single page.

amelius 1y ago
1,000 components is my standard test for trying out a new UI library. I recently tried it with Kotlin/Compose. Turned out that everything becomes noticeably slower with so many components, even if the components are in a scroll view and only a few of them are visible.
- aatd86 1y ago
  Displaying so many would require virtualization. No one is going to see a myriad of components all at once anyway. The slowing down part might be eager computations in partially optimized implementations. The same way we use pagination on the web, or lazy loading, etc... But I guess the question is whether that should be a default...
  - amelius 1y ago
    Maybe but it sounds like bad excuses. There are a myriad of examples anyone can come up with that require a UI library to simply be fast. For example, perhaps someone wants to implement minesweeper with checkboxes. Or build an "infinite" feed, or a settings panel showing thousands of settings of a system where you can filter with a filter box, etc., etc. You can argue against all of these cases, or you can simply rely on a fast UI library and be done with it.
  - jitl 1y ago
    1000 component should be trivial for a framework in 2025 without virtualization.
    - aatd86 1y ago
      Hmmh... Warning: Lighthouse issues a warning when the page's <body> element has more than ~800 nodes (elements). Error: Lighthouse reports an error when the <body> element has more than ~1,400 nodes. Other Related Lighthouse Warnings Lighthouse also flags two other related issues, which often contribute to a large DOM: Maximum DOM Depth: It warns if your DOM tree has a nesting depth greater than 32 levels. Maximum Child Elements: It warns if any single parent element has more than 60 direct children. The general recommendation for optimal performance is to keep your page's total DOM node count below 1,500. source: https://web.dev/articles/dom-size-and-interactivity https://web.dev/articles/dom-size-and-interactivity These are "NODES", not even components as you say...
      - amelius 1y ago
        That's because a webpage should render properly on __all__ browsers. You don't have this problem with UI libraries because all users will run the same library.
        jitl 1y ago
        ?
jfengel 1y ago
1,000 is a lot, but not uncommon for a CRUD app. Especially when you start with a small one and the scope creeps. Users want one more feature, and one more field. Then it's time to replace some other CRUD app and you've already got this one going ...
GeoAtreides 1y ago
> If have a 40X25 table on your page that's editable, that's your 1,000 components right there. Why would you do it like that?! Just have a normal component for a table, and when the clicks on a cell, spawn (and teleport) an edit component over that cell.

amelius 1y ago

1,000 components is my standard test for trying out a new UI library. I recently tried it with Kotlin/Compose. Turned out that everything becomes noticeably slower with so many components, even if the components are in a scroll view and only a few of them are visible.

aatd86 1y ago
Displaying so many would require virtualization. No one is going to see a myriad of components all at once anyway. The slowing down part might be eager computations in partially optimized implementations. The same way we use pagination on the web, or lazy loading, etc... But I guess the question is whether that should be a default...
- amelius 1y ago
  Maybe but it sounds like bad excuses. There are a myriad of examples anyone can come up with that require a UI library to simply be fast. For example, perhaps someone wants to implement minesweeper with checkboxes. Or build an "infinite" feed, or a settings panel showing thousands of settings of a system where you can filter with a filter box, etc., etc. You can argue against all of these cases, or you can simply rely on a fast UI library and be done with it.
- jitl 1y ago
  1000 component should be trivial for a framework in 2025 without virtualization.
  - aatd86 1y ago
    Hmmh... Warning: Lighthouse issues a warning when the page's <body> element has more than ~800 nodes (elements). Error: Lighthouse reports an error when the <body> element has more than ~1,400 nodes. Other Related Lighthouse Warnings Lighthouse also flags two other related issues, which often contribute to a large DOM: Maximum DOM Depth: It warns if your DOM tree has a nesting depth greater than 32 levels. Maximum Child Elements: It warns if any single parent element has more than 60 direct children. The general recommendation for optimal performance is to keep your page's total DOM node count below 1,500. source: https://web.dev/articles/dom-size-and-interactivity https://web.dev/articles/dom-size-and-interactivity These are "NODES", not even components as you say...
    - amelius 1y ago
      That's because a webpage should render properly on __all__ browsers. You don't have this problem with UI libraries because all users will run the same library.
      - jitl 1y ago
        ?

jfengel 1y ago

1,000 is a lot, but not uncommon for a CRUD app. Especially when you start with a small one and the scope creeps. Users want one more feature, and one more field. Then it's time to replace some other CRUD app and you've already got this one going ...

GeoAtreides 1y ago

> If have a 40X25 table on your page that's editable, that's your 1,000 components right there. Why would you do it like that?! Just have a normal component for a table, and when the clicks on a cell, spawn (and teleport) an edit component over that cell.