8 ms·

This is a wonderful example of a well engineered solution to the wrong problem. React is a wonderful view library, and if limited to that use it is remarkably

This is a wonderful example of a well engineered solution to the wrong problem. React is a wonderful view library, and if limited to that use it is remarkably fast and easy to use. But the usual way of building things is to treat React as a total web app framework. The terminology is very confused: they still call it "rendering", even though it now usually includes data fetching, complex manipulations, event processing, etc. You just `React.render` once when your page first loads and then child components take care of the rest. It should really be called `React.start`. > The reason for the stutter is simple: once rendering begins, it can’t be interrupted. Rendering should never need to be interrupted. If your app is architected to have any rendering operation take long enough that it's perceptible to the user, STOP DOING THAT THING DURING RENDERING. Want a performant web app? Apply separation of concerns properly, and limit your use of React to the view layer.

MuffinFlavored 7y ago
Without data fetching or manipulating, you have nothing to render.
- couchand 7y ago
  Yes, but don't do it from within your view. Fetch the data you need and provide it to the view. The standard React application renders a few levels down, investigates the document location and matches against routes, renders a few more levels, discovers there is some necessary data missing, fetches it, renders a few more levels down, realizes there's more data missing, stops and waits for it, etc. This isn't a failing of React per se, but rather of how people use it.
  - weberc2 7y ago
    As an ignorant and neutral bystander, I’m really curious why this is downvoted and would be interested in reading the rebuttal (seems like I could learn something).
    - chacham15 7y ago
      React isnt the one mandating how its used. It can be used in the way that the GP is talking about, but you can also keep the data entirely separate. Redux et al do exactly that. The main thing that the GP is missing is that, like with video games, in order to keep the view rendering smoothly, you need something like double buffering so that if the render isnt complete, you dont block. That is independent of how the data is being provided.
    - PKop 7y ago
      Because 4 or 5 years of real world React development have proven them inadequate suggestions. React itself was created in opposition to arbitrary separation of concerns dogma. The concern is the component, the entity encompassing both UI and data manipulation code, as well as styling. Separating all of these parts into isolation does not result in more maintainable code or better UX.
      - couchand 7y ago
        No, React was created in opposition to the fact that we used to manually update the DOM because that's all we had tools for.
        PKop 7y ago
        Rethinking best practices absolutely addressed misapplication of separation of concerns. https://www.youtube.com/watch?v=x7cQ3mrcKaY https://www.youtube.com/watch?v=x7cQ3mrcKaY Components have always had JSX markup along with data manipulation logic. CSS in JS and styling co-located with component extended this consolidation of cross-cutting concerns. These, along with not manually updating DOM state as you mention, all fall under declarative aspects of React.. which concurrent rendering and Suspense are consistent with and essentially an extension of.
        mosdl 7y ago
        No, React was created to allow contractors to write code fast and not worry about optimization.
  - crooked-v 7y ago
    My general lean here has been to use a library like redux-first-router (https://github.com/faceyspacey/redux-first-router https://github.com/faceyspacey/redux-first-router) to have this data lookup stuff happen based on routing and existing Redux state, and conditional rendering wrapping for specific components using that data (for example, https://github.com/acdlite/recompose/blob/master/docs/API.md#branch https://github.com/acdlite/recompose/blob/master/docs/API.md...).
  - ng12 7y ago
    > Fetch the data you need and provide it to the view. That's exactly what this feature is doing -- making the view layer more flexible in how it responds to the data received.
- nostrademons 7y ago
  Do it at the top-level. React components shouldn't be managing their own data fetches or computation. They should take event handlers that indicate something has happened on the page, and then delegate that back up the tree until the App decides what to do with them. The App is then responsible for making the relevant fetches, massaging the data into a form suitable for display on the page, and updating the state. Components, to the greatest extent possible, should be stateless and react only to changes in props. If they do need state it should be for things local to the view (eg. the position of a slider, the currently selected tab, or the hidden/shown state of an expando). Aside from keeping rendering lightweight and never needing to block, this architecture also: 1.) Lets the app batch up RPCs to minimize network traffic. 2.) Lets you easily swap out the network layer for mock data so you can develop the UI before the server is ready (often very important because backend dev tends to be slower than frontend). 3.) Lets you handle failures sensibly. Oftentimes a failed RPC requires that you make non-local changes to the UI (eg. display a butterbar, change page layout to not display a component, display an alternate component). 4.) Lets you easily add logging, tracing, and performance profiling capability to your network layer. 5.) Keeps your UI components reusable so they aren't coupled to a specific app or backend. 6.) Optimally handles cases where data (derived) from the fetch shows up in multiple places in the UI. One classic example of this is a table where the total count of results is in a UI element elsewhere on the page; another is when logging in changes the elements you're shown.
  - PKop 7y ago
    >Do it at the top-level. Which top level? Requires a lot of coordination code, duplication, and coupling of your entire component hierarchy to each other no? Still doesn't solve disparities in data loading completion across different services. Render giant loading spinner or the entire app? Plus, you will be overfetching if everything is pulled into top level components. For exactly the reason componentizing the markup was a good idea, it is beneficial to breakup data loading and manipulation concerns across components, while also being able to reuse some of this logic through abstractions (hooks). >Keeps your UI components reusable so they aren't coupled to a specific app or backend. They are coupled to each other by virtue of where you define them in the hierarchy and which props they need to pass to and receive from each other.
PKop 7y ago
>Apply separation of concerns properly With the component paradigm, these things can't always easily be separated. Or, it is useful to consolidate data concerns and UI concerns, but often data concerns like UI have a hierarchy, or the concerns are spread all over the place (not in neat, clear groups). It is very useful to declaratively specify the recipe for both UI and data, and allow the framework to coordinate these things across and within components. >Rendering should never need to be interrupted. Following this line of thought would lead to not rendering anything until everything is ready. Large applications have multiple levels of components and data concerns. These solutions allow for isolating responsibilities at smaller levels, and coordinating their presentation in ways that produce good UI (few loading spinners, flickering etc). >and if limited to that use This simply passes the responsibility somewhere else no? And any significant apps can't avoid these concerns. You'd still be left with the coordination between React and whatever else was handling these concerns, but with much more code likely to tie them together.
manigandham 7y ago
There's nothing inherently special about rendering. If the function is an unresolved promise then it should automatically await, and treat that component as blank or nonexistent. It's just legacy architecture to make render functions sync and blocking.
nickdandakis 7y ago
Out of curiosity, how is it not still "rendering"? Do you prefer "start" because it renders a tree of children? But yes, rendering doesn't need to be interrupted. They specifically mention architecture decisions to avoid rendering operations that take too long (debounce and throttle). This eliminates previously necessary architecture decisions while providing a better user experience. How is that solving the wrong problem? Also, this is still the view layer. There's nothing React-specific about data fetching, "complex manipulations" or "event processing". Previously if you had a text input whose output you used to fetch some data and render in a list, you'd use debounce. Now, with Concurrent Mode, you don't have to and can instead use the React API.
kiliancs 7y ago
> React is a wonderful view library The React model makes sense because of how state management is part of it, not strictly just the view. I think seeing it just as a view library necessarily leads to the rest of your other conclusions. I recommend reading https://overreacted.io/react-as-a-ui-runtime/ https://overreacted.io/react-as-a-ui-runtime/ by Abramov which describes React as a UI runtime. Embracing React as a UI runtime you eventually find problems that concurrent mode solves. Some are related to performance and concurrency, but some are related to managing state and data dependencies. It also provides idiomatic ways that encourage good UX (like managing error/loading conditions once, at the right level).
deleted 7y ago
[deleted]
underwater 7y ago
The browser gives you 16ms to execute JS if you want to avoid stutter. Even with the tightest, hand rolled, vanilla JavaScript there are plenty of situations where that isn't enough time, especially on low end devices. Seperation of concerns is all good and well, but there are some product experiences you simply can't do with plain HTML.
- mstade 7y ago
  And yet we have games that routinely do rendering, networking, state updates, and a bunch of other things in that same time frame. Even in JS, using HTML. Let's not automatically assume the runtime is at fault.
_bxg1 7y ago
> If your app is architected to have any rendering operation take long enough that it's perceptible to the user, STOP DOING THAT THING DURING RENDERING. At my workplace we frequently encounter cases where the rendering itself - just the evaluation of the pure React functions - takes hundreds of milliseconds, if not several seconds. This is after memoizing every part of it that can be memoized, after profiling it for places where work can be shaved off, etc. Sometimes there really is just that much rendering, and unlike other types of computation, today's React gives you no options for putting that in a worker or breaking it up. Tabs' single threads mean you can't even scroll in the interim. Concurrent Mode is the only hope we have of solving that case, other than avoiding it with paging, which is what we currently do.
- paulddraper 7y ago
  > React gives you no options for putting that in a worker or breaking it up. Isn't that React Fiber? [1] "Fiber breaks down animation into segments that can be spread out over multiple frames." How does that differ from React Concurrent? Are they compatible? [1] https://en.wikipedia.org/wiki/React_Fiber https://en.wikipedia.org/wiki/React_Fiber
  - _bxg1 7y ago
    So, I'm not sure exactly how Fiber works, but given the context and what I've read/watched, here's my guess: Confusingly, there are multiple tiers of "updates" happening in a React app. One is when your render functions are called to recompute their React element trees. Work can be avoided here via shouldComponentUpdate(), etc. Once React has this internal data structure, it uses it to do another level of updates to the actual DOM. This part is totally black-boxed from the application code, because React has all the information it needs internally to avoid unnecessary updates at this level. I think, maybe, that Fiber is specifically focused on this latter stage. Concurrent Mode would then be the stage 1 equivalent of what Fiber does in stage 2. This would be why it has an effect on how application code can actually be written, where Fiber didn't really.
    - acemarke 7y ago
bcyn 7y ago
> Apply separation of concerns properly The disconnect here is the definition of "concerns." One analogy is, imagine cutting a square into stripes. You're implying that there's only one way to do so, say, cutting horizontally. But you can easily cut vertically and still end up with well separated stripes. The stripes, whether horizontal or vertical, are separated cleanly. While you may see splitting by data fetching, view, etc. as the only way to separate by concerns, there are certainly others. The component model that has been adopted by many React users is one such way.
- bcrosby95 7y ago
  Unless you want a mess, usually you still separate by both. Just because you "cut" a square vertically or horizontally, doesn't mean each strip doesn't have, say, more separating lines that you didn't cut. These concerns should still be separated, even if they aren't separated at the highest levels of your application. At the top level, we slice our projects vertically (by feature) at work. But it doesn't mean we have 1 giant god framework that handles all layers for a given feature. We still segment by layer. And we still have layer focused libraries.
throwaway_bad 7y ago
> If your app is architected to have any rendering operation take long enough that it's perceptible to the user, STOP DOING THAT THING DURING RENDERING. As is tradition, frontend developers are still slowly reinventing the techniques from other fields. The neat thing about UI is that your end user is a human and a human can't visually process too many items at once on a screen. This means you should never really need to consider more than O(thousands) elements to render either. That should always fit under 16ms. This has been known to game developers since forever. Don't spend resources on things that won't be displayed. If you are doing too much work that means you aren't culling invisible objects or approximating things at a lower level of detail. In practice for frontend developers, this just means using stuff like react-virtualized so that even if you have a list of a bajillion objects, only the stuff in the viewport is rendered.
- andrewingram 7y ago
  I don't think there's any slow reinvention going on in the way you're describing -- the adoption of ideas from (for example) game development has been a total non-secret since the dawn of the React age. There's definitely slow reimplementation going on though, and unfortunately it's having to be done at the scripting level, rather than the engine level.
  - throwaway_bad 7y ago
    Yea you're right, I guess there is a distinction between reinventing and reimplementing. The authors even mentioned that concurrent mode is inspired by "double buffering" from graphics. I am just trying to support the grandparent comment that the current optimization is at the wrong level of abstraction. React is at the level of a "scene graph" (dom). If it's slow, the first technique to reach for should be stuff like "occlusion culling".
    - andrewingram 7y ago
      That's largely analogous to what people attempt to do with virtualisation, but the ability of things to have unpredictable resizing and reflow behaviours throws a few spanners into the works. My understanding that (at least until recently, things might be different now) is that most game engine optimisations depend on being able to make a lot of assumptions that usually hold true, or being able to calculate most of your scene graph optimisations during a build step.
leerob 7y ago
> They still call it "rendering", even though it now usually includes data fetching. Their documentation explicitly states that Suspense is not for data fetching. That's what the new Relay APIs are for. https://reactjs.org/docs/concurrent-mode-suspense.html#what-suspense-is-not https://reactjs.org/docs/concurrent-mode-suspense.html#what-...

MuffinFlavored 7y ago

Without data fetching or manipulating, you have nothing to render.

couchand 7y ago
Yes, but don't do it from within your view. Fetch the data you need and provide it to the view. The standard React application renders a few levels down, investigates the document location and matches against routes, renders a few more levels, discovers there is some necessary data missing, fetches it, renders a few more levels down, realizes there's more data missing, stops and waits for it, etc. This isn't a failing of React per se, but rather of how people use it.
- weberc2 7y ago
  As an ignorant and neutral bystander, I’m really curious why this is downvoted and would be interested in reading the rebuttal (seems like I could learn something).
  - chacham15 7y ago
    React isnt the one mandating how its used. It can be used in the way that the GP is talking about, but you can also keep the data entirely separate. Redux et al do exactly that. The main thing that the GP is missing is that, like with video games, in order to keep the view rendering smoothly, you need something like double buffering so that if the render isnt complete, you dont block. That is independent of how the data is being provided.
  - PKop 7y ago
    Because 4 or 5 years of real world React development have proven them inadequate suggestions. React itself was created in opposition to arbitrary separation of concerns dogma. The concern is the component, the entity encompassing both UI and data manipulation code, as well as styling. Separating all of these parts into isolation does not result in more maintainable code or better UX.
    - couchand 7y ago
      No, React was created in opposition to the fact that we used to manually update the DOM because that's all we had tools for.
      - PKop 7y ago
        Rethinking best practices absolutely addressed misapplication of separation of concerns. https://www.youtube.com/watch?v=x7cQ3mrcKaY https://www.youtube.com/watch?v=x7cQ3mrcKaY Components have always had JSX markup along with data manipulation logic. CSS in JS and styling co-located with component extended this consolidation of cross-cutting concerns. These, along with not manually updating DOM state as you mention, all fall under declarative aspects of React.. which concurrent rendering and Suspense are consistent with and essentially an extension of.
      - mosdl 7y ago
        No, React was created to allow contractors to write code fast and not worry about optimization.
- crooked-v 7y ago
  My general lean here has been to use a library like redux-first-router (https://github.com/faceyspacey/redux-first-router https://github.com/faceyspacey/redux-first-router) to have this data lookup stuff happen based on routing and existing Redux state, and conditional rendering wrapping for specific components using that data (for example, https://github.com/acdlite/recompose/blob/master/docs/API.md#branch https://github.com/acdlite/recompose/blob/master/docs/API.md...).
- ng12 7y ago
  > Fetch the data you need and provide it to the view. That's exactly what this feature is doing -- making the view layer more flexible in how it responds to the data received.
nostrademons 7y ago
Do it at the top-level. React components shouldn't be managing their own data fetches or computation. They should take event handlers that indicate something has happened on the page, and then delegate that back up the tree until the App decides what to do with them. The App is then responsible for making the relevant fetches, massaging the data into a form suitable for display on the page, and updating the state. Components, to the greatest extent possible, should be stateless and react only to changes in props. If they do need state it should be for things local to the view (eg. the position of a slider, the currently selected tab, or the hidden/shown state of an expando). Aside from keeping rendering lightweight and never needing to block, this architecture also: 1.) Lets the app batch up RPCs to minimize network traffic. 2.) Lets you easily swap out the network layer for mock data so you can develop the UI before the server is ready (often very important because backend dev tends to be slower than frontend). 3.) Lets you handle failures sensibly. Oftentimes a failed RPC requires that you make non-local changes to the UI (eg. display a butterbar, change page layout to not display a component, display an alternate component). 4.) Lets you easily add logging, tracing, and performance profiling capability to your network layer. 5.) Keeps your UI components reusable so they aren't coupled to a specific app or backend. 6.) Optimally handles cases where data (derived) from the fetch shows up in multiple places in the UI. One classic example of this is a table where the total count of results is in a UI element elsewhere on the page; another is when logging in changes the elements you're shown.
- PKop 7y ago
  >Do it at the top-level. Which top level? Requires a lot of coordination code, duplication, and coupling of your entire component hierarchy to each other no? Still doesn't solve disparities in data loading completion across different services. Render giant loading spinner or the entire app? Plus, you will be overfetching if everything is pulled into top level components. For exactly the reason componentizing the markup was a good idea, it is beneficial to breakup data loading and manipulation concerns across components, while also being able to reuse some of this logic through abstractions (hooks). >Keeps your UI components reusable so they aren't coupled to a specific app or backend. They are coupled to each other by virtue of where you define them in the hierarchy and which props they need to pass to and receive from each other.

PKop 7y ago

>Apply separation of concerns properly With the component paradigm, these things can't always easily be separated. Or, it is useful to consolidate data concerns and UI concerns, but often data concerns like UI have a hierarchy, or the concerns are spread all over the place (not in neat, clear groups). It is very useful to declaratively specify the recipe for both UI and data, and allow the framework to coordinate these things across and within components. >Rendering should never need to be interrupted. Following this line of thought would lead to not rendering anything until everything is ready. Large applications have multiple levels of components and data concerns. These solutions allow for isolating responsibilities at smaller levels, and coordinating their presentation in ways that produce good UI (few loading spinners, flickering etc). >and if limited to that use This simply passes the responsibility somewhere else no? And any significant apps can't avoid these concerns. You'd still be left with the coordination between React and whatever else was handling these concerns, but with much more code likely to tie them together.

manigandham 7y ago

There's nothing inherently special about rendering. If the function is an unresolved promise then it should automatically await, and treat that component as blank or nonexistent. It's just legacy architecture to make render functions sync and blocking.

nickdandakis 7y ago

Out of curiosity, how is it not still "rendering"? Do you prefer "start" because it renders a tree of children? But yes, rendering doesn't need to be interrupted. They specifically mention architecture decisions to avoid rendering operations that take too long (debounce and throttle). This eliminates previously necessary architecture decisions while providing a better user experience. How is that solving the wrong problem? Also, this is still the view layer. There's nothing React-specific about data fetching, "complex manipulations" or "event processing". Previously if you had a text input whose output you used to fetch some data and render in a list, you'd use debounce. Now, with Concurrent Mode, you don't have to and can instead use the React API.

kiliancs 7y ago

> React is a wonderful view library The React model makes sense because of how state management is part of it, not strictly just the view. I think seeing it just as a view library necessarily leads to the rest of your other conclusions. I recommend reading https://overreacted.io/react-as-a-ui-runtime/ https://overreacted.io/react-as-a-ui-runtime/ by Abramov which describes React as a UI runtime. Embracing React as a UI runtime you eventually find problems that concurrent mode solves. Some are related to performance and concurrency, but some are related to managing state and data dependencies. It also provides idiomatic ways that encourage good UX (like managing error/loading conditions once, at the right level).

deleted 7y ago

[deleted]

underwater 7y ago

The browser gives you 16ms to execute JS if you want to avoid stutter. Even with the tightest, hand rolled, vanilla JavaScript there are plenty of situations where that isn't enough time, especially on low end devices. Seperation of concerns is all good and well, but there are some product experiences you simply can't do with plain HTML.

mstade 7y ago
And yet we have games that routinely do rendering, networking, state updates, and a bunch of other things in that same time frame. Even in JS, using HTML. Let's not automatically assume the runtime is at fault.

_bxg1 7y ago

> If your app is architected to have any rendering operation take long enough that it's perceptible to the user, STOP DOING THAT THING DURING RENDERING. At my workplace we frequently encounter cases where the rendering itself - just the evaluation of the pure React functions - takes hundreds of milliseconds, if not several seconds. This is after memoizing every part of it that can be memoized, after profiling it for places where work can be shaved off, etc. Sometimes there really is just that much rendering, and unlike other types of computation, today's React gives you no options for putting that in a worker or breaking it up. Tabs' single threads mean you can't even scroll in the interim. Concurrent Mode is the only hope we have of solving that case, other than avoiding it with paging, which is what we currently do.

paulddraper 7y ago
> React gives you no options for putting that in a worker or breaking it up. Isn't that React Fiber? [1] "Fiber breaks down animation into segments that can be spread out over multiple frames." How does that differ from React Concurrent? Are they compatible? [1] https://en.wikipedia.org/wiki/React_Fiber https://en.wikipedia.org/wiki/React_Fiber
- _bxg1 7y ago
  So, I'm not sure exactly how Fiber works, but given the context and what I've read/watched, here's my guess: Confusingly, there are multiple tiers of "updates" happening in a React app. One is when your render functions are called to recompute their React element trees. Work can be avoided here via shouldComponentUpdate(), etc. Once React has this internal data structure, it uses it to do another level of updates to the actual DOM. This part is totally black-boxed from the application code, because React has all the information it needs internally to avoid unnecessary updates at this level. I think, maybe, that Fiber is specifically focused on this latter stage. Concurrent Mode would then be the stage 1 equivalent of what Fiber does in stage 2. This would be why it has an effect on how application code can actually be written, where Fiber didn't really.
  - acemarke 7y ago

bcyn 7y ago

> Apply separation of concerns properly The disconnect here is the definition of "concerns." One analogy is, imagine cutting a square into stripes. You're implying that there's only one way to do so, say, cutting horizontally. But you can easily cut vertically and still end up with well separated stripes. The stripes, whether horizontal or vertical, are separated cleanly. While you may see splitting by data fetching, view, etc. as the only way to separate by concerns, there are certainly others. The component model that has been adopted by many React users is one such way.

bcrosby95 7y ago
Unless you want a mess, usually you still separate by both. Just because you "cut" a square vertically or horizontally, doesn't mean each strip doesn't have, say, more separating lines that you didn't cut. These concerns should still be separated, even if they aren't separated at the highest levels of your application. At the top level, we slice our projects vertically (by feature) at work. But it doesn't mean we have 1 giant god framework that handles all layers for a given feature. We still segment by layer. And we still have layer focused libraries.

throwaway_bad 7y ago

> If your app is architected to have any rendering operation take long enough that it's perceptible to the user, STOP DOING THAT THING DURING RENDERING. As is tradition, frontend developers are still slowly reinventing the techniques from other fields. The neat thing about UI is that your end user is a human and a human can't visually process too many items at once on a screen. This means you should never really need to consider more than O(thousands) elements to render either. That should always fit under 16ms. This has been known to game developers since forever. Don't spend resources on things that won't be displayed. If you are doing too much work that means you aren't culling invisible objects or approximating things at a lower level of detail. In practice for frontend developers, this just means using stuff like react-virtualized so that even if you have a list of a bajillion objects, only the stuff in the viewport is rendered.

andrewingram 7y ago
I don't think there's any slow reinvention going on in the way you're describing -- the adoption of ideas from (for example) game development has been a total non-secret since the dawn of the React age. There's definitely slow reimplementation going on though, and unfortunately it's having to be done at the scripting level, rather than the engine level.
- throwaway_bad 7y ago
  Yea you're right, I guess there is a distinction between reinventing and reimplementing. The authors even mentioned that concurrent mode is inspired by "double buffering" from graphics. I am just trying to support the grandparent comment that the current optimization is at the wrong level of abstraction. React is at the level of a "scene graph" (dom). If it's slow, the first technique to reach for should be stuff like "occlusion culling".
  - andrewingram 7y ago
    That's largely analogous to what people attempt to do with virtualisation, but the ability of things to have unpredictable resizing and reflow behaviours throws a few spanners into the works. My understanding that (at least until recently, things might be different now) is that most game engine optimisations depend on being able to make a lot of assumptions that usually hold true, or being able to calculate most of your scene graph optimisations during a build step.

leerob 7y ago

> They still call it "rendering", even though it now usually includes data fetching. Their documentation explicitly states that Suspense is not for data fetching. That's what the new Relay APIs are for. https://reactjs.org/docs/concurrent-mode-suspense.html#what-suspense-is-not https://reactjs.org/docs/concurrent-mode-suspense.html#what-...