Live data from Hacker News

TodoMVC App Written in Vanilla JavaScript

github.com

31–40 of 115 posts

Re: TodoMVC App Written in Vanilla JavaScript

#31

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…

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.

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 and to let the browser determine how to get there in the most efficient way.

If the browser could do this it would make a tonne of JS code so much simpler. There's a lot that goes into making sure that there's no unnecessary DOM updates because it's just slow.

I don't write assembly and move things between registers by hand, I write a function and the compiler decides the most efficient way of doing it. UI should be the same way, I say what I want to happen and the browser decides how to get there.

Re: TodoMVC App Written in Vanilla JavaScript

#32
My app CardBoard (https://www.cardboard.team/) is no-framework vanilla js. This is a large-ish codebase with a lot of functionality, and the same code is wrapped with apache cordova for both iOS and Android apps. In 2022, browser-native WebComponents (addresses encapsulation, code organization, and re-use) with no frameworks is a hill I'd die on.

Re: TodoMVC App Written in Vanilla JavaScript

#33
How do we get 31 comments but not a single one on why this solution is subpar?

The entire TODO list is rendered anytime a single item is changed/removed/added. The biggest thing frameworks give us is fast, differential DOM updates.

Once browsers add differential update APIs, then we can kiss React and all the other players goodbye :-)

Re: TodoMVC App Written in Vanilla JavaScript

#34

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.

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

Re: TodoMVC App Written in Vanilla JavaScript

#35

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.

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.

Re: TodoMVC App Written in Vanilla JavaScript

#36

How do we get 31 comments but not a single one on why this solution is subpar? The entire TODO list is rendered anytime a single item is changed/removed/added. The biggest thing frameworks give us is fast, differential DOM updates. Once browsers add differential update APIs, then we can kiss React and all the other players goodbye :-)

I mean... You aren't wrong, but the amount of data that fits on a typical page is usually such that the speed of a full refresh probably shouldn't be that big of a deal.

Re: TodoMVC App Written in Vanilla JavaScript

#37
I wrote a TodoMVC App with React, Redux and SSR that works without JS enabled in the browser a while back, for those interested in that sort of thing :)

Demo: https://todo-react-redux-noscript.herokuapp.com/

Repo: https://github.com/wishy-gift/todo-react-redux-noscript/

Talk (updated framework): https://m.youtube.com/watch?v=3yY-Z-X3xE4

Helpers to do your own stuff: https://www.npmjs.com/package/@wishy-gift/noscript

Re: TodoMVC App Written in Vanilla JavaScript

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

Re: TodoMVC App Written in Vanilla JavaScript

#40
post #25

For me, the biggest issue with using vanilla JS is the lack of guardrails. Before even considering something like this I’d want to see a style guide and clear definition of where code should live. Frameworks like React do that well. I can expect a random React dev to mostly do similar things.

> I can expect a random React dev to mostly do similar things.

This has not been my experience. Even experienced software devs will differ stylistically, but intermediate devs often come up with very different ideas about how things ought to work. I suspect this is due to wide variance in awareness of different libraries/platform features/stylistic patterns/etc, a consequence of being in a relatively unregulated industry.

I have worked for companies using React since 2014 and no 2 projects have had the same layout. My current and previous employers have had the closest codebases, but only in terms of directory structure, and even now the current one is changing to become quite different (in a way I think is good, but only time will tell).

Post reply on HN