4 ms·

50% on plain rendering is very unexpected. Complex apps tend to have bottlenecks on IO/data fetching more than just plain rendering. I would love an article de

50% on plain rendering is very unexpected. Complex apps tend to have bottlenecks on IO/data fetching more than just plain rendering. I would love an article detailing your experience and measurements.

dustingetz 9y ago
our renders are compute heavy because it is so dynamic (most of today's apps aren't). Think of it this way. Virtual DOM is like a spreadsheet. You only want to recompute the stuff downstream of what's changed. That's basically what React's render-tree pruning is all about. But there are a couple problems. First, naive server rendered React isn't diffing anything at all, it recomputes the whole virtual dom from scratch every time. So there isn't any render-tree pruning since we're not doing a diff. That's what the walmart-labs patches help with, since obviously a lot of SSR'ed components aren't changing between SSRs, that can be reused, and we can be fast again. Second, React.js views are more than just banging html together, it also has to call a bunch of functions as part of that process. For example client side sorting, or map/reduce/filter. So if those functions are expensive, your views are slow, even if the html itself isn't all that complex. Third, since much of our "view rendering" cost is actually computation not directly related to making html, React can't reuse pieces of those computations anyway. You'd need to code your "math" in terms of React components even though there's no html associated with them. Fourth, if your dataflows are dynamic enough, like a spreadsheet, even if React actually could optimize those computations (which it cant), it wouldn't even be helpful, because while Views are trees, many computations are not. For example, in a spreadsheet: Edit cell C7, quick what is the tree of computations you can skip? The question doesn't even make sense, because spreadsheets aren't trees. Spreadsheets do complicated graph dependency tracking, with cycle analysis and all that, in order to make this fast. React doesn't do that. As an example of how dynamic Hyperfiddle is, go to http://dustingetzcom2.hyperfiddle.net/ http://dustingetzcom2.hyperfiddle.net/ and in the top toolbar click "data" and then click "dev". Dustingetzcom2 is not coded in javascript, its coded in data, and you edit the data live in the dev pane, and the right things update live as you make changes. That's why the render computation is so expensive.
- abritinthebay 9y ago
  That... is not very dynamic. I'm sorry, I'm looking at your example link and you should be getting rendering times in the sub 40ms range. Unless that's not a representative example of course. Nothing in there seems particularly un-reusable.
- batmansmk 9y ago
  No need to try to explain why you think it is slow based on your understanding of React. Facts are always better. Good news is: I suspect you have no React issue. How is your NODE_ENV? Set to production? After looking at your website, you have no perf issue caused by React itself! Remove the blinking cursor made with setInterval, and use CSS animation for that. You'll see :)
  - dustingetz 9y ago
    Here are the walmart labs patches I mentioned: https://github.com/walmartlabs/react-ssr-optimization https://github.com/walmartlabs/react-ssr-optimization That link has the data points you are looking for, react SSR problems are well understood and documented and have been for some time now, that repo is a year old also see https://www.reddit.com/r/reactssr/ https://www.reddit.com/r/reactssr/

dustingetz 9y ago

our renders are compute heavy because it is so dynamic (most of today's apps aren't). Think of it this way. Virtual DOM is like a spreadsheet. You only want to recompute the stuff downstream of what's changed. That's basically what React's render-tree pruning is all about. But there are a couple problems. First, naive server rendered React isn't diffing anything at all, it recomputes the whole virtual dom from scratch every time. So there isn't any render-tree pruning since we're not doing a diff. That's what the walmart-labs patches help with, since obviously a lot of SSR'ed components aren't changing between SSRs, that can be reused, and we can be fast again. Second, React.js views are more than just banging html together, it also has to call a bunch of functions as part of that process. For example client side sorting, or map/reduce/filter. So if those functions are expensive, your views are slow, even if the html itself isn't all that complex. Third, since much of our "view rendering" cost is actually computation not directly related to making html, React can't reuse pieces of those computations anyway. You'd need to code your "math" in terms of React components even though there's no html associated with them. Fourth, if your dataflows are dynamic enough, like a spreadsheet, even if React actually could optimize those computations (which it cant), it wouldn't even be helpful, because while Views are trees, many computations are not. For example, in a spreadsheet: Edit cell C7, quick what is the tree of computations you can skip? The question doesn't even make sense, because spreadsheets aren't trees. Spreadsheets do complicated graph dependency tracking, with cycle analysis and all that, in order to make this fast. React doesn't do that. As an example of how dynamic Hyperfiddle is, go to http://dustingetzcom2.hyperfiddle.net/ http://dustingetzcom2.hyperfiddle.net/ and in the top toolbar click "data" and then click "dev". Dustingetzcom2 is not coded in javascript, its coded in data, and you edit the data live in the dev pane, and the right things update live as you make changes. That's why the render computation is so expensive.

abritinthebay 9y ago
That... is not very dynamic. I'm sorry, I'm looking at your example link and you should be getting rendering times in the sub 40ms range. Unless that's not a representative example of course. Nothing in there seems particularly un-reusable.
batmansmk 9y ago
No need to try to explain why you think it is slow based on your understanding of React. Facts are always better. Good news is: I suspect you have no React issue. How is your NODE_ENV? Set to production? After looking at your website, you have no perf issue caused by React itself! Remove the blinking cursor made with setInterval, and use CSS animation for that. You'll see :)
- dustingetz 9y ago
  Here are the walmart labs patches I mentioned: https://github.com/walmartlabs/react-ssr-optimization https://github.com/walmartlabs/react-ssr-optimization That link has the data points you are looking for, react SSR problems are well understood and documented and have been for some time now, that repo is a year old also see https://www.reddit.com/r/reactssr/ https://www.reddit.com/r/reactssr/