3 ms·

So React rewrite did not help after all? Imagine, one of the largest software tool companies on Earth cannot reliably REbuild something in React. I lost count o

So React rewrite did not help after all? Imagine, one of the largest software tool companies on Earth cannot reliably REbuild something in React. I lost count of the inconsistency issues React introduced. https://news.ycombinator.com/item?id=33576722 https://news.ycombinator.com/item?id=33576722

catigula 8mo ago
React isn't causing these issues.
- dev_l1x_be 8mo ago
  Good to know. So it only causes the UI inconsistency bugs.
  - danudey 8mo ago
    The new design/architecture allows them to do great stuff in the name of efficiency; for example, when browsing through some parts of the UI, it's now much more capable of just updating the part of the page that's changed, rather than having to reload the entire thing. This is a significantly better approach for a lot of things. I understand that the 'updating the part of the page that's changed' functionality is now dramatically slower, more unresponsive, and less reliable than the 'reload the entire thing' approach was, and it feels like browsing the site via Citrix over dial-up half the time, but look, sacrifices have to be made in the name of making things better even if the sacrifice is that things get worse instead.
    - hunterpayne 8mo ago
      > for example, when browsing through some parts of the UI React allows this? I didn't realize that I needed React to do this when we used Java and Js to do this 20 years ago. I also didn't realize I needed React to do this when we used Scala and generated Js to do this 10 years ago. JFC, the world didn't start when you turned 18.
      - zx8080 8mo ago
        Shhh, don't insult them. It's the lost art of doing stuff smart and efficient. Now the trend is doing stuff _vibe_ instead.
      - ibrahima 8mo ago
        > I understand that the 'updating the part of the page that's changed' functionality is now dramatically slower, more unresponsive, and less reliable than the 'reload the entire thing' approach was, and it feels like browsing the site via Citrix over dial-up half the time, but look, sacrifices have to be made in the name of making things better even if the sacrifice is that things get worse instead. I don't think they were being serious.
    - captn3m0 8mo ago
      GitHub used jQuery + pjax to do exactly this a decade ago - rendered HTML for smaller components was fetched and replaced in-place with a single DOM update. It even had fancy sliding transitions.
    - dev_l1x_be 8mo ago
      > to do great stuff in the name of efficiency; for example, when browsing through some parts of the UI, it's now much more capable of just updating the part of the page that's changed Are you implying that this only doable with React? I mean just for the fun of it you can look at this video: https://www.youtube.com/watch?v=3GObi93tjZI https://www.youtube.com/watch?v=3GObi93tjZI
- dham 8mo ago
  Then why is the site slower than it was in 2012 on a 2009 Macbook?

catigula 8mo ago

React isn't causing these issues.

dev_l1x_be 8mo ago
Good to know. So it only causes the UI inconsistency bugs.
- danudey 8mo ago
  The new design/architecture allows them to do great stuff in the name of efficiency; for example, when browsing through some parts of the UI, it's now much more capable of just updating the part of the page that's changed, rather than having to reload the entire thing. This is a significantly better approach for a lot of things. I understand that the 'updating the part of the page that's changed' functionality is now dramatically slower, more unresponsive, and less reliable than the 'reload the entire thing' approach was, and it feels like browsing the site via Citrix over dial-up half the time, but look, sacrifices have to be made in the name of making things better even if the sacrifice is that things get worse instead.
  - hunterpayne 8mo ago
    > for example, when browsing through some parts of the UI React allows this? I didn't realize that I needed React to do this when we used Java and Js to do this 20 years ago. I also didn't realize I needed React to do this when we used Scala and generated Js to do this 10 years ago. JFC, the world didn't start when you turned 18.
    - zx8080 8mo ago
      Shhh, don't insult them. It's the lost art of doing stuff smart and efficient. Now the trend is doing stuff _vibe_ instead.
    - ibrahima 8mo ago
      > I understand that the 'updating the part of the page that's changed' functionality is now dramatically slower, more unresponsive, and less reliable than the 'reload the entire thing' approach was, and it feels like browsing the site via Citrix over dial-up half the time, but look, sacrifices have to be made in the name of making things better even if the sacrifice is that things get worse instead. I don't think they were being serious.
  - captn3m0 8mo ago
    GitHub used jQuery + pjax to do exactly this a decade ago - rendered HTML for smaller components was fetched and replaced in-place with a single DOM update. It even had fancy sliding transitions.
  - dev_l1x_be 8mo ago
    > to do great stuff in the name of efficiency; for example, when browsing through some parts of the UI, it's now much more capable of just updating the part of the page that's changed Are you implying that this only doable with React? I mean just for the fun of it you can look at this video: https://www.youtube.com/watch?v=3GObi93tjZI https://www.youtube.com/watch?v=3GObi93tjZI
dham 8mo ago
Then why is the site slower than it was in 2012 on a 2009 Macbook?