20 ms·
React in concurrent mode: 2000 state-connected comps re-rendered at 60FPS
- fenwick67 7y agoThis is rendering 3d shapes in threejs, not doing anything in the DOM, so this is quite a nothingburger isn't it?
- Waterluvian 7y agoThe thing that excites me is using the react component paradigm for non DOM stuff like canvas and webGL.
- ioquatix 7y agoUnfortunately, history shows us that it's a terrible idea from a performance perspective.
- Jasper_ 7y agoIt's also a very strange way to write a renderer, since you want your renderer to be pass-based, rather than object-based. React + Three.JS is just the wrong level of abstraction, since Three.JS a scene graph toolkit.
- deleted 7y ago[deleted]
- mlsarecmg 7y agoReact has hooks. They are essentially algebraic effects. Check out some of the demos here: https://github.com/react-spring/react-three-fiber https://github.com/react-spring/react-three-fiber and look for "useFrame". useFrame binds a single component to the render-loop. But in a managed way. Once the component unmount, it's getting taken out. You can also stack calls like that with something like a z-index, which is awesome for effects. This game uses some of it: https://codesandbox.io/embed/react-three-fiber-untitled-game-i2160 https://codesandbox.io/embed/react-three-fiber-untitled-game...
- fenwick67 7y agoWhy is this exciting?
- crubier 7y agoYou tell react what you want your scene graph to look like in the end. You don’t have to write down how to update. Which removes a whole class of bugs AND simplifies code A LOT
- HereBeBeasties 7y agoFlutter looks like it could be quite interesting for this - on mobile it compiles over to native machine code and uses GL or whatever. I haven't looked at the details for web, but I think it does webasm and canvas, etc. and with the architecture they have it could potentially be a lot faster than traditional JS frameworks https://flutter.dev/web https://flutter.dev/web
- fyp 7y agoRendering "thousands" of anything is usually not how you impress people. The scheduler is still cool though.
- crooked-v 7y agoI suspect you never had to deal with the days of AngularJS, where just rendering a large table-style view with a thousand interactive elements could slow browsers to a crawl.
- crimsonalucard 7y agoI think the comment is referring to the state of the front end in context of computing in general. In a broader context those metrics are pathetic. Your OS for example has UI performance light years faster.
- Jasper_ 7y agoYeah, I'd say around the order of ~10k items is when an O(n^2) algorithm gets noticeably slow. "Thousands" is a shockingly weak payoff for all the effort. edit: and the real innovation here appears to be writing a multi-threaded scheduler. You should not need to spin up multiple threads to handle 2,000 objects. Something is going seriously wrong perf-wise here.
- c-smile 7y ago> O(n^2) algorithm gets noticeably slow. What algorithm? If that's about diff/reconciliation of DOM/VDOM then it is worse than that - O(n^3).
- forrestthewoods 7y agoCan you point me to a good resource on what the n^3 process is? It’s not intuitive to me why it’s so, ahem, complex. Thanks! :)
- 7y ago
- duxup 7y agoThe scheduling and ability to provide an app that behaves as users expect / based on user research is probably more important than any numbers.
- _august 7y agohttps://reactjs.org/docs/concurrent-mode-intro.html https://reactjs.org/docs/concurrent-mode-intro.html
- armagon 7y agoWhat are "comps"? (much less "state-connected comps")?
- forrestthewoods 7y ago> If you give it an impossible load, so many render requests that it must choke, it will start to manage these requests to maintain a stable 60fps, by updating components virtually and letting them retain their visual state Does that mean if you try to update too many things it will simply... not update them in order to maintain 60fps? That does not seem ideal. In this particular example, a bunch of random objects updated every frame, will that result in a "spiral of death"? Meaning every frame M transform requests are made. But it will only process N (where N < M) requests. Or does it drop parts of the queue if it didn't process a transform before receiving a second update for the same transform? Is updating 2000 boxes per second really considered an "impossible" amount to update? That seems like a shockingly small number. Edit: I don’t understand the downvotes. My question on understanding behavior is perfectly reasonable. I don’t understand how this new technology works. What is it doing under the hood?
- onion2k 7y agoIs updating 2000 boxes per second really considered an "impossible" amount to update? That seems like a shockingly small number. That's not what's happening in the demo. It's effectively updating 2000 virtual DOM nodes at 60 frames a second by scheduling updates so as many things are updated in each 16ms frame as possible. It'll scale with the device. If you have a beast of a computer it might update all 2000 every frame. If you're on a $100 smart phone it'll schedule the updates across several frames. In the demo each node is a three.js box geometry - react-three-fiber uses react's virtual DOM reconciler to update state on three.js things. That doesn't have to be the case though. The nodes could be HTML elements or SVG things or any other browser renderable item. React doesn't care. What the demo really shows is that concurrent mode React moves the bottleneck out of the framework and back to the browser - how fast the UI can be updated will be down to the browser instead of what the JS framework can do. That's a really big deal. It'll make writing performant UIs a lot easier which is good for everyone.
- setr 7y agoI believe the question is that if I generate 2000 updates a second, but its applying those 2000 updates over 4 seconds (applying 500 updates a second to maintain 60fps), then at second 1 I have 2000 updates remaining(+2000 new) At second 2 I have 3500 updates remaining (+2000 new, -500 processed) At second 3 I have 5000 updates remaining (+2000 new, -500 processed) That is, my backlog will indefinitely grow larger, unless it's dropping updates.
- proc0 7y agoI'm excited to see how much this will make 2d games possible with react.
- c-smile 7y agoWhat do you expect from React in 2D games? React is just a procedural method of UI rendering. That's what pretty much all games do already. So is the question.
- mlsarecmg 7y agoCheck out this: https://codesandbox.io/embed/react-three-fiber-untitled-game-i2160 https://codesandbox.io/embed/react-three-fiber-untitled-game... Or some of the other demos here: https://github.com/react-spring/react-three-fiber https://github.com/react-spring/react-three-fiber React lends extremely well to games, especially with hooks. Now you have reactive components, but also algebraic effects.
- proc0 7y agoI was thinking 2d games but woah, very impressive.
- crubier 7y agoReact is not procedural. React is declarative. React is a way to turn imperative APIs into declarative APIs that are much easier to reason about. So yes, this is a big deal in my opinion.
- proc0 7y agoMany games are also a procedural method of UI rendering. Think about puzzle games, or even tetris. From a high level they're just complicated buttons. Of course it wouldn't be a good fit for anything that is highly interactive or 3d.
- gdxhyrd 7y agoI really, really hope nobody writes games in React. It is such a bad fit for games and it is very disrespectful of the environment and your users' battery.
- millstone 7y agoHow does the scheduler achieve preemption? How does it decide when to render and when to allow the event loop to run?
- cheez 7y agoI wrote something like this many years ago and all I did was queue stuff to be processed simultaneously.
- pomber 7y agoSee https://pomb.us/build-your-own-react/#step-iii-concurrent-mode https://pomb.us/build-your-own-react/#step-iii-concurrent-mo...
- millstone 7y agoThanks. This really drives home how insane the browser architecture is. React would like to pause rendering to react to new events as they come in. However, there is no way for React to be told when there is a new event, so it has to poll for it. Unfortunately there's no way to directly poll for a new event, so it has to fake an event poll via inversion of control built on top of requestAnimationFrame.
- pomber 7y agoYes, but the React team is working together with the Chrome team to improve it. There is an `isInputPending` proposal https://techcrunch.com/2019/04/22/facebook-makes-its-first-browser-api-contribution/ https://techcrunch.com/2019/04/22/facebook-makes-its-first-b...
- c-smile 7y agoNot sure I understand the achievement. That type of rendering is more about GPU load than of anything React (DOM) related. As of DOM rendering of comparable number of nodes then this: https://terrainformatica.com/2019/07/29/bloomberg-terminal-how-i-would-it-with-sciter/ https://terrainformatica.com/2019/07/29/bloomberg-terminal-h... 900 elements re-rendered on each frame of kinematic scroll (60 FPS) with 10% CPU load. And 250 FPS max on typical high-DPI monitor. In other tests underlying recordset is updated with 25 FPS frequency. The view observes and updates screen for visible rows - 2% CPU for that. All that in main GUI thread so I do not understand the excitement.
- Normal_gaussian 7y agoEssentially the reactive state model - which imo is 'fast' to code in - currently has a horrendous limitation on how many components can be reactive. A naive minesweeper implementation (that is state-connected) will get upset at a hundred cells, and terribly laggy at 900 (a standard 30x30 super expert board). This means devs have to abandon reactive programming for parts of their code with a non trivial component count. The demo is showing 'smooth' perf on these kinds of "state-connected" workloads. The graphics side of things is a partial distraction, mainly it will mean web devs won't have to make the current performance vs ease of development tradeoff in webapps (think boring saas stuff). The way in which it isn't a distraction is it will make it possible to get past CSS limitations inside of react in a very intuitive way. As this raises the low bar react had for game perf, we will no doubt see more react games. But have no doubt - this is about what the current state of reactive programming is capable of off the shelf.
- abcpassword 7y agoI’d like to see a laggy react implementation of minesweeper. I build apps with more complex component graphs than this without performance issue.
- gdxhyrd 7y agoI am amazed at the fact that even going the slow path gets laggy with a mere 900 elements... What are they doing?!
- csande17 7y agoFrom a marketing standpoint, I'm not sure demos like this that draw comparisons between JavaScript frameworks and 3D game engines are a great idea. The author describes updating 2000 cubes every frame as an "impossible amount of load", and claims that React will soon "run circles around even the best performing manual WebGL apps". Here's Unity maintaining a smooth framerate while updating three times that many cubes: https://www.youtube.com/watch?v=qVMfKJfsHQg https://www.youtube.com/watch?v=qVMfKJfsHQg Unlike the React demo, all of the cubes actually move each frame (it's not "rescheduling" updates to later frames like React Concurrent Mode does), and it's doing a complex physics simulation to decide where the cubes should go.
- underwater 7y agoReact concurrent makes a lot of sense for UI elements, which are complex and self contained and sporadically updated. Whereas a game engine is much more about raw speed, and every element is updated on each tick. I would be surprised if the overhead of React and concurrent mode bookkeeping were worth it for a game engine.
- Jasper_ 7y agoYeah, maintaining state for 2000 elements is not a hard problem. I've written CPU particle systems which handle ~10k particles per frame, some of which even run entirely in the browser. This shot from Super Mario Galaxy simulates around 3,000 particles, on top of all the other bone/joint animations that are happening. Performance like this is possible in a web browser, but you wouldn't think so given how popular React and ThreeJS are. https://noclip.website/#smg/AstroGalaxy;AAI4t49Qk^u9Ld&YUm,m_W-zy_4~(x_UcUO6UP@]=WR2Z39kY1tTqnNC9G:U0+^8 https://noclip.website/#smg/AstroGalaxy;AAI4t49Qk^u9Ld&YUm,m...
- onion2k 7y agoPerformance like this is possible in a web browser, but you wouldn't think so given how popular React and ThreeJS are. Updating the state of thousands of DOM nodes at a steady 16ms per frame in a browser is hard enough that you have to go beyond "just update them all every frame" like in a simple particle system. To go fast you have to move to working out what needs to update based on what changed in the state. Most web app developers don't want to have to think too hard about how it gets on the screen. They, very reasonably in my opinion, want to work on the app logic itself instead. Unfortunately that's how we end up with janky UIs. If React's concurrent mode can just be fast by default by spreading out updates if the framerate is falling that's good for everyone.
- undoware 7y agoNo, the sim itself is not that impressive compared to Unity or similar. They are, however, impressive relative to legacy React, which, as a development modality, has an enormous amount going for it. React and React-likes are winning in the marketplace because the development style it opens up really is that much better than many competitors. Yes, it's average everyday use cases driving that; no, that is nothing to be ashamed of. There are many reasons you don't write a shopping cart in Unity, but now you can get a taste of performance nevertheless. Props to the React team. (Yes that is a joke; I am passing props to the React team ;D)
- dharma1 7y agothis isn't actually by the React team - it's by one incredible individual, who does open source for free - Paul Henschel
- crubier 7y agoIn this post Paul Henschel is actually saying how impressed he is with the work of the react team. Paul’s work here (react three fiber) is actually a very thin layer on top of react. Which is impressive in itself. In 3 files he was able to bond all of react to all of three JS. Which says a lot on react and on Paul’s work. But the point is: it’s react general ideas that are at play here
- dharma1 7y agoHe's also using his own state manager, Zustand which gives a significant speed boost
- gcpwnd 7y agoI am quite offended that this guy complains about people who claim that they have great benchmark scores and then he does the very same. Can't we make buzz about achievements without attacking others?
- francasso 7y agoThe day ignorant people will stop discovering new stupid ways to solve trivial problems and then market them to their undiscerning fellows will be a great day for humanity. Unfortunately I will not live to see that day. Yes this is a sour comment, made by an elitist that can no longer muster the energy to be compassionate and walk towards the light people that seem to have taken a vow not to experiment, evaluate, judge and, most importantly, use their brain and previous experience. All the offensive words in this post have been chosen with care for their dictionary definition. Now go ahead, complain and downvote.
- swyx 7y agowe have an ongoing discussion at /r/reactjs if anyone is interested as well: https://www.reddit.com/r/reactjs/comments/e43l6w/rich_harris_implements_the_round_react_demo_with/ https://www.reddit.com/r/reactjs/comments/e43l6w/rich_harris...