3 ms·
There’s absolutely no way you’ll have worse performance with this vs React. The app is modifying the target elements directly, not recreating the whole page wit
by ricardobeat 5y ago
There’s absolutely no way you’ll have worse performance with this vs React. The app is modifying the target elements directly, not recreating the whole page with innerHTML. React will do the same amount of work at a minimum, and that’s after rebuilding the whole tree and diffing it.
The main bottleneck here are the synchronous localStorage calls happening in the render path, they could be moved to a separate timer.
- toomim 5y agoOne way React can be faster than hand-written code is by batching all dom manipulation into animation frames.
- ricardobeat 5y agoThe rendering code here is already batched since everything happens within a single render() call. And unless you’re using react fiber, its rendering is also synchronous.
- sarchertech 5y agoHandwritten JS could also batch DOM manipulation (without the need for virtual dom comparison).
- SemanticStrengh 5y agohttps://github.com/wilsonpage/fastdom https://github.com/wilsonpage/fastdom
- 1marc 5y agoOoo fastdom looks great! Thanks for the link.
- SemanticStrengh 5y agohttps://www.youtube.com/watch?v=VKMw2it8dQY https://www.youtube.com/watch?v=VKMw2it8dQY
- chacham15 5y agoIt seems like you didnt actually look at the code because thats exactly what its doing: https://github.com/1Marc/todomvc-vanillajs-2022/blob/main/js/app.js#L82 https://github.com/1Marc/todomvc-vanillajs-2022/blob/main/js... it clears innerHTML there and then rerenders the children
- ricardobeat 5y agoYou’re right, I did a quick reading and thought it was updating elements one by one. I still suspect this might be faster than React anyway. Would be interesting to try.
- SemanticStrengh 5y agoRight but proper manual dom is generally faster than optimized react code. That does not means that in general manual dom code is proper.
- 1marc 5y agoI did this style to mimick modern framework code — taking the state (todos) and render the state of the world every time. If the browser had a DOM diffing api this would be more efficient and we would be there. So for a larger project I might using something like Lit’s html stand-alone package or fastdom to get the DOM digging functionality without much dependency code.
- Philip-J-Fry 5y agoI never suggested you'd have worse performance. But it's not declarative, it's tedious. Read my comment again.
- grayrest 5y ago> There’s absolutely no way you’ll have worse performance with this vs React. It's normal to get much worse performance than React if you layout thrash and it's very easy to layout thrash without batched updates. There's overhead in the vdom but getting all the updates batched tends to be a performance win in any decent sized app. This was an active area of library exploration/development in the 2008-2012 timeframe but the only framework actively promoting it was Sencha IIRC.