Live data from Hacker News

TodoMVC App Written in Vanilla JavaScript

github.com

51–60 of 115 posts

Re: TodoMVC App Written in Vanilla JavaScript

#51
post #26

Earlier quoted context omitted.

it sounds sort of wild to expect there to be diffing! why do you have to generate a whole copy of the stuff instead of just telling the browser what changes to make? bonus: the existing apis instead of one that don't exist yet.

Diffing is exactly what you need to do (barring newer methods like svelte) to figure out what to tell the browser to change. The vdom tree is much faster to manipulate than DOM nodes.

But you can't see those changes until the actual DOM changes as well. It's only because of react's insistence that mutation is evil that this became a problem. You could just directly update the thing you wanted to and just skip the whole diff thing.

Re: TodoMVC App Written in Vanilla JavaScript

#53

Earlier quoted context omitted.

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.

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

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.

Re: TodoMVC App Written in Vanilla JavaScript

#54
post #46

Earlier quoted context omitted.

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.

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.

Re: TodoMVC App Written in Vanilla JavaScript

#55
post #46

Earlier quoted context omitted.

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.

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

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

Re: TodoMVC App Written in Vanilla JavaScript

#56
post #46

Earlier quoted context omitted.

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

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

https://github.com/wilsonpage/fastdom

Re: TodoMVC App Written in Vanilla JavaScript

#57

Earlier quoted context omitted.

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.

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.

Re: TodoMVC App Written in Vanilla JavaScript

#58
Nice! I was going to suggest the usage of Trusted Types API [0] to escape HTML [1], but support [2] for modern browsers is not there yet, specifically for HTML.

0: https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Typ...

1: https://github.com/1Marc/todomvc-vanillajs-2022/blob/1c31309...

2: https://developer.mozilla.org/en-US/docs/Web/API/TrustedHTML...

Re: TodoMVC App Written in Vanilla JavaScript

#59

I get this running it in chrome Uncaught SyntaxError: Missing initializer in const declaration (at helpers.js:4:14) Installed and ran with: npm install npm run start Any idea what went wrong...?

The assignment (=) is missing from those const declarations, except for the first one; I guess they were hastily converted from function declarations to satisfy modern tastes.

Oops, yeah I just accepted a pull request from the community that broke my helpers module declarations. Just fixed it, thanks for noticing!

Re: TodoMVC App Written in Vanilla JavaScript

#60

Nice! I was going to suggest the usage of Trusted Types API [0] to escape HTML [1], but support [2] for modern browsers is not there yet, specifically for HTML. 0: https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Typ... 1: https://github.com/1Marc/todomvc-vanillajs-2022/blob/1c31309... 2: https://developer.mozilla.org/en-US/docs/Web/API/TrustedHTML...

Cool! I'll look into the API and consider adding it to this implementation. Or happily would take a look at a PR for it.
Post reply on HN