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

61–70 of 115 posts

Re: TodoMVC App Written in Vanilla JavaScript

#61

Post by Philip-J-Fry »

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.

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

Read my comment again.

Re: TodoMVC App Written in Vanilla JavaScript

#62

Post by emteycz »

mattgreenrocks wrote: post #18
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…

Echoes of Alan Kay's recent comment on how software devs are way too concerned with the how the computer works to the detriment of what the software is supposed to do.

The battle is fought over performance and size, I think that's exactly what the user wants.

Re: TodoMVC App Written in Vanilla JavaScript

#63

Post by 1marc »

chacham15 wrote: post #49
ricardobeat wrote: post #43

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

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.

Re: TodoMVC App Written in Vanilla JavaScript

#65

Post by msoad »

This code reminds me of Backbone. I think we all started here and then abstracted event handling and reactivity into a tiny framework like Backbone.

React and other declarative approaches are inherently different. In React I hardly think of when my component renders. In Backbone days, I remember having to debug why some part of code is not running when I'm expecting it to run. React does this really well.

Re: TodoMVC App Written in Vanilla JavaScript

#66

Post by steve_adams_86 »

msoad wrote: post #65

This code reminds me of Backbone. I think we all started here and then abstracted event handling and reactivity into a tiny framework like Backbone. React and other declarative approaches are inherently different. In React I hardly think of when my component renders. In Backbone days, I remember having to debug why some part of code is not running when I'm expecting it to run. React does this really well.

A cool thing about react is that it’s easy to reason about as well. The reconciliation algorithm is fundamentally pretty simple and there isn’t any magic happening.

It can get confusing to track down unexpected renders when you think the result of the algorithm should be different, but that’s not really an issue with react so much a the nature of managing complex state, memoization algorithms which potentially use different diffing strategies, and logic which might be mutating state in ways you don’t quite expect, and so on.

People criticize these front end libraries but I’m still impressed by how well state management has been integrated into such extensible and scalable view layers.

Re: TodoMVC App Written in Vanilla JavaScript

#68

Post by vips7L »

emteycz wrote: post #62
mattgreenrocks wrote: post #18

Earlier quoted context omitted.

Echoes of Alan Kay's recent comment on how software devs are way too concerned with the how the computer works to the detriment of what the software is supposed to do.

The battle is fought over performance and size, I think that's exactly what the user wants.

I don’t think the typical user cares about size.

Re: TodoMVC App Written in Vanilla JavaScript

#69

Post by moffkalast »

Trufa wrote: post #3

I’m sorry but this is not a fairly complex app. When things do get more complex (and not even that much) is when you start hitting problems. How would you reuse a “component”? Among many other things. I honestly don’t know if that’s the point of the author but I would agree that many framework are too heavy, but honestly there so many good compromises today that don’t make you re-invent the wheel and fix bugs that ha…

> How would you reuse a "component"?

Save the element template as a string and set innerhtml of a div as that?

> compromises today that don’t make you re-invent the wheel

Yeah but there's also no need to include jQuery and bog down your site with piles of code you won't ever call just because you don't know how to use the native api like a normal person. React/Angular/whatever are just the latest fad of that mindset, big team corporate ease of use aside.

Re: TodoMVC App Written in Vanilla JavaScript

#70

Post by realPubkey »

syspec wrote: post #67

Wouldn't this have loads of memory leaks from never removing the event listeners when the todo elements go away? I think it hides the complexity by pretending that's not a problem

Also it does not work properly when it is used in more then one browser tab.
Post reply on HN