No post body was provided.
TodoMVC App Written in Vanilla JavaScript
71–80 of 115 posts
Re: TodoMVC App Written in Vanilla JavaScript
#72How 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 :-)
No post body was provided.
Re: TodoMVC App Written in Vanilla JavaScript
#73Earlier quoted context omitted.
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.
No, the reason React has a VDOM is because the DOM is slow to update, compared to manipulating javascript objects. It's worthwhile to calculate the list of minimum updates ahead of time rather than using the DOM as the source of truth.
Not sure where you think mutation comes into play here, that's an orthogonal concern—you can have an API that mutates some internal representation of a VDOM, and it's still faster than manipulating the DOM directly.
Re: TodoMVC App Written in Vanilla JavaScript
#74Wouldn'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
The event listeners get cleaned up by the GC. At least in modern browsers.
While events aren’t explicitly mentioned, MDN offers an insightful read:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memo...
Alternately, one can use event delegation [0]. As does React under the hood [1].
0 - https://javascript.info/event-delegation
1 - https://reactjs.org/blog/2020/08/10/react-v17-rc.html#change...
Re: TodoMVC App Written in Vanilla JavaScript
#75Earlier quoted context omitted.
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.
I agree. In over 20 years I've never had a single user ask or complain about the size of the app. They have let me know when there was something not working right though.
Re: TodoMVC App Written in Vanilla JavaScript
#76The 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.
> 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.
Re: TodoMVC App Written in Vanilla JavaScript
#77Earlier quoted context omitted.
I don’t think the typical user cares about size.
I agree. In over 20 years I've never had a single user ask or complain about the size of the app. They have let me know when there was something not working right though.
People definitely notice speed and performance. They won’t complain about it generally, sure… but there’s plenty of data and case studies on the fact that users care https://nitropack.io/blog/post/web-performance-matters-case-...
Re: TodoMVC App Written in Vanilla JavaScript
#78I’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,…
What happens when you need to update some deeply nested child element without re-rendering the whole tree? Suddenly you need some system of labeling the children, how to find them in the dom, how to update them, how to keep them in sync with the state... a vanilla JS solution becomes extremely unwieldy as soon as you step out of the "global pointers to elements" phase (what the project in the OP is). Lit-html is an example of a tool that solves this problem in tiny package- less than 1KB- and you can continue using string templates with that.
Re: TodoMVC App Written in Vanilla JavaScript
#79The 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.
Yup. The reality is that programmer time is far far more expensive than compute time. And as long as that's the case, increasing levels of abstraction are our only hope at building complex software.
Re: TodoMVC App Written in Vanilla JavaScript
#80Vanilla JavaScript feels like jQuery now. Doing this was quite awkward in ECMAScript 3 and 5.
> App.$.filters.querySelectorAll('a').forEach(el => el.classList.remove('selected'));