Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TodoMVC App Written in Vanilla JavaScript

github.com

Post reply on HN
Print view View original

41–50 of 115 posts

Re: TodoMVC App Written in Vanilla JavaScript

#41

Post by grabanski »

lelandfe wrote: post #39

Oh, hey! This is from the founder of Frontend Masters – easily the best FE resource I've ever found: https://frontendmasters.com/ . Their content creation process is pretty nifty: they run live workshops regularly that subscribers can join, and the footage from the workshops ultimately gets cut and turned into the tutorials. Had no idea who was behind it, but I love that they're still contributing back like this.

Ah, thanks for the plug!! I did this as a fun little weekend project, glad people are finding it useful as a reference of how simple vanilla JS can be these days. :-)

Re: TodoMVC App Written in Vanilla JavaScript

#42

Post by ricardobeat »

ghubcoder wrote: post #38

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.

Re: TodoMVC App Written in Vanilla JavaScript

#43

Post by ricardobeat »

Philip-J-Fry wrote: post #9

The thing I enjoy about frameworks like React is the declarative nature of the UIs. I'd love to not be able to use them and to create complex UIs in pure JavaScript but it always ends up being painful where you spend more time optimising the rendering than doing any work. In simple apps I will write UI in a functional matter in pure JavaScript, regardless of the performance implications. But bigger DOM means worse pe…

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.

Re: TodoMVC App Written in Vanilla JavaScript

#44

Post by Philip-J-Fry »

5560675260 wrote: post #34
Philip-J-Fry wrote: post #31

Earlier quoted context omitted.

Because it can be automated? Every app that doesn't do this is just implementing the diff by hand, e.g. on this event delete this element, update this element, add CSS class to this element, etc. When the UI gets complicated you have to maintain this all yourself and it's a pain. Multiple event listeners between components to say something has happened. It makes sense to be able to describe what you want to achieve a…

> When the UI gets complicated you have to maintain this all yourself and it's a pain This is also something that can be automated by a framework. Check out https://svelte.dev/blog/virtual-dom-is-pure-overhead

Yes... but that's the exact argument I'm making here. Unless you want to go through that pain, you need a framework.

Whether that's Svelte without a VDOM or React with a VDOM. The entire point of these frameworks is that you can write complex UI in a declarative way. They both exist because writing it declaratively in pure JS leads to performance issues. But there's nothing stopping the browser implementing something that does this optimisation for you.

Re: TodoMVC App Written in Vanilla JavaScript

#45

Post by recursive »

Philip-J-Fry wrote: post #9

The thing I enjoy about frameworks like React is the declarative nature of the UIs. I'd love to not be able to use them and to create complex UIs in pure JavaScript but it always ends up being painful where you spend more time optimising the rendering than doing any work. In simple apps I will write UI in a functional matter in pure JavaScript, regardless of the performance implications. But bigger DOM means worse pe…

Cases where "UI should be a function of state" seem like a small sliver of all use cases. Probably not worth the complexity for implementing directly in the browser. And there are plenty of conditions that just prohibit the pattern entirely as far as I can tell. Things where referential stability matters, like you have a contentEditable or allow arbitrary edits on a canvas.

Re: TodoMVC App Written in Vanilla JavaScript

#46

Post by toomim »

ricardobeat wrote: post #43
Philip-J-Fry wrote: post #9

The thing I enjoy about frameworks like React is the declarative nature of the UIs. I'd love to not be able to use them and to create complex UIs in pure JavaScript but it always ends up being painful where you spend more time optimising the rendering than doing any work. In simple apps I will write UI in a functional matter in pure JavaScript, regardless of the performance implications. But bigger DOM means worse pe…

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.

Re: TodoMVC App Written in Vanilla JavaScript

#47

Post by Philip-J-Fry »

bobbylarrybobby wrote: post #35
Philip-J-Fry wrote: post #31

Earlier quoted context omitted.

Because it can be automated? Every app that doesn't do this is just implementing the diff by hand, e.g. on this event delete this element, update this element, add CSS class to this element, etc. When the UI gets complicated you have to maintain this all yourself and it's a pain. Multiple event listeners between components to say something has happened. It makes sense to be able to describe what you want to achieve a…

Yes, but there are ways to accomplish this automation without diffing. Svelte does this by statically wiring up the data dependencies in your app when it builds, and then at runtime making exactly the changes to the DOM that it needs to based on the information it had at build time. No need to diff.

The point is that A) that's a framework and B) that requires you to compile Svelte files.

If you want to write declarative UI in pure JS then you need the browser to do these DOM optimisations for you, and diffing the changes is the way to do that.

Re: TodoMVC App Written in Vanilla JavaScript

#48

Post by recursive »

Philip-J-Fry wrote: post #44
5560675260 wrote: post #34

Earlier quoted context omitted.

> When the UI gets complicated you have to maintain this all yourself and it's a pain This is also something that can be automated by a framework. Check out https://svelte.dev/blog/virtual-dom-is-pure-overhead

Yes... but that's the exact argument I'm making here. Unless you want to go through that pain, you need a framework. Whether that's Svelte without a VDOM or React with a VDOM. The entire point of these frameworks is that you can write complex UI in a declarative way. They both exist because writing it declaratively in pure JS leads to performance issues. But there's nothing stopping the browser implementing something…

I find the "pain" to be drastically overstated. See this HN post.

Re: TodoMVC App Written in Vanilla JavaScript

#49

Post by chacham15 »

ricardobeat wrote: post #43
Philip-J-Fry wrote: post #9

The thing I enjoy about frameworks like React is the declarative nature of the UIs. I'd love to not be able to use them and to create complex UIs in pure JavaScript but it always ends up being painful where you spend more time optimising the rendering than doing any work. In simple apps I will write UI in a functional matter in pure JavaScript, regardless of the performance implications. But bigger DOM means worse pe…

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
Post reply on HN