3 ms·

Maybe I am being naive, but I'm just not sure what people are building with React that requires such heavy focus on optimization that we're starting to look at

by ehnto 6y ago

Maybe I am being naive, but I'm just not sure what people are building with React that requires such heavy focus on optimization that we're starting to look at Concurrent Mode. Is it an issue with React performance, or are we just asking the client devices to do too much work? React is a UI library after all, how complex does a UI need to be before you run into performance issues, or is it that the UI framework is doing work outside the scope of a UI? I understand less capable devices is a concern as well, but that just makes me wonder even more why people are building such taxing applications with React. PS: Please contribute to the conversation, I'm genuinely curious, this isn't my area of expertise. If you're sending a downvote, spend a moment to tell me why I'm wrong.

kbr 6y ago
AFAIK React itself is performant enough, the bottleneck is client code within components. I suppose the change is mostly for full enterprise web apps at the Facebook level that likely have thousands of components running at the same time. Concurrent mode lets React split up work and give some time back to browsers (for e.g. mouse movements or rendering) to prevent large freezes on rerenders, essentially allowing prioritization of certain interactions for latency. On top of that, I think it also helps to remove some of the bottleneck that comes from I/O.
lhorie 6y ago
The fundamental problem with UI frameworks is figuring out what to re-render based on some event, while also providing a declarative view of the code to the developer. Some libraries optimize this via micro-optimizations (e.g. inferno is carefully crafted so that browsers use the hidden classes optimization nearly all the time). Some libraries do this by compilation (e.g. svelte takes assignment expressions and rewrites them into a reactive trigger call). And so on. The problem though is that no matter what the framework does, there's no way to render 1 million things in a page all at once (and yes, people do try that). On a fundamental level, doing anything a million times synchronously will block the main thread (javascript is single-threaded, you see). In the mithril.js community for example, the solution is to say "well, don't render 1 million things, use pagination or occlusion culling or search or some other mechanism since no one's ever going to meaningfully interact w/ 1 million UI elements simultaneously anyways". In the React world, concurrent mode is a technical attempt at addressing that same issue. There are various different use cases that fall within concurrent mode's scope, e.g. avoid stuttering animations (the mithril.js community answer in this case btw might be "well, use CSS" or "use lifecycle events and vnode.dom to drop down to vanilla JS"). The React team is corporate-sponsored, so they solve problems in very different ways that an OSS project run by volunteers.

by ehnto 6y ago

kbr 6y ago

AFAIK React itself is performant enough, the bottleneck is client code within components. I suppose the change is mostly for full enterprise web apps at the Facebook level that likely have thousands of components running at the same time. Concurrent mode lets React split up work and give some time back to browsers (for e.g. mouse movements or rendering) to prevent large freezes on rerenders, essentially allowing prioritization of certain interactions for latency. On top of that, I think it also helps to remove some of the bottleneck that comes from I/O.

lhorie 6y ago

The fundamental problem with UI frameworks is figuring out what to re-render based on some event, while also providing a declarative view of the code to the developer. Some libraries optimize this via micro-optimizations (e.g. inferno is carefully crafted so that browsers use the hidden classes optimization nearly all the time). Some libraries do this by compilation (e.g. svelte takes assignment expressions and rewrites them into a reactive trigger call). And so on. The problem though is that no matter what the framework does, there's no way to render 1 million things in a page all at once (and yes, people do try that). On a fundamental level, doing anything a million times synchronously will block the main thread (javascript is single-threaded, you see). In the mithril.js community for example, the solution is to say "well, don't render 1 million things, use pagination or occlusion culling or search or some other mechanism since no one's ever going to meaningfully interact w/ 1 million UI elements simultaneously anyways". In the React world, concurrent mode is a technical attempt at addressing that same issue. There are various different use cases that fall within concurrent mode's scope, e.g. avoid stuttering animations (the mithril.js community answer in this case btw might be "well, use CSS" or "use lifecycle events and vnode.dom to drop down to vanilla JS"). The React team is corporate-sponsored, so they solve problems in very different ways that an OSS project run by volunteers.