Hacker News Reader

Comment by ricardobeat | Hacker News Reader

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.

View on HN

It 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... it clears innerHTML there and then rerenders the children

Right but proper manual dom is generally faster than optimized react code. That does not means that in general manual dom code is proper.

I 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.

You’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.

> 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.

I never suggested you'd have worse performance. But it's not declarative, it's tedious.

Read my comment again.

One way React can be faster than hand-written code is by batching all dom manipulation into animation frames.

The 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.

Handwritten JS could also batch DOM manipulation (without the need for virtual dom comparison).

https://github.com/wilsonpage/fastdom

Ooo fastdom looks great! Thanks for the link.

https://www.youtube.com/watch?v=VKMw2it8dQY

Reply on news.ycombinator.com