Please do not re-implement HTML sanitization. Just replace that escapeForHTML and innerHTML assignment with a later textContent assignment. Please. Pretty please.
TodoMVC App Written in Vanilla JavaScript
81–90 of 115 posts
Re: TodoMVC App Written in Vanilla JavaScript
#82Nice! 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.
Seriously- just do the innerHTML assignment on li.innerHTML omitting the title, followed up by a simple li.querySelector().textContent = todo.title.
Re: TodoMVC App Written in Vanilla JavaScript
#83I'm impressed this took an hour and a half. Is this the kind of timeframe someone should be able to throw something together in?
Re: TodoMVC App Written in Vanilla JavaScript
#84Please do not re-implement HTML sanitization. Just replace that escapeForHTML and innerHTML assignment with a later textContent assignment. Please. Pretty please.
That seems like a good improvement. Pull requests welcome!
Re: TodoMVC App Written in Vanilla JavaScript
#85Earlier quoted context omitted.
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…
In order to achieve immutability, large chunks of state have to be cloned whenever a single value changes. This sometimes causes a whole new DOM node to be created during reconciliation. React encourages you not to think about it too much. But some nodes can't be replaced. Like canvas or anything contentEditable. It's not orthogonal. It's a direct consequence of the design philosophy.
Re: TodoMVC App Written in Vanilla JavaScript
#86Wouldn'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.
Here's what it would look like to support that usecase: https://github.com/1Marc/todomvc-vanillajs-2022/commit/09979...
Re: TodoMVC App Written in Vanilla JavaScript
#87Please do not re-implement HTML sanitization. Just replace that escapeForHTML and innerHTML assignment with a later textContent assignment. Please. Pretty please.
That seems like a good improvement. Pull requests welcome!
How does this look? https://github.com/1Marc/todomvc-vanillajs-2022/commit/d38e5...
Re: TodoMVC App Written in Vanilla JavaScript
#88Earlier quoted context omitted.
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.
Seriously- just do the innerHTML assignment on li.innerHTML omitting the title, followed up by a simple li.querySelector().textContent = todo.title.
How does this look? https://github.com/1Marc/todomvc-vanillajs-2022/commit/d38e5...
Re: TodoMVC App Written in Vanilla JavaScript
#89Earlier quoted context omitted.
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-...
>People definitely notice speed and performance.
There's sort of a "Maslow's Hierarchy of User Needs" that exists in software though. So long as the user can do something, and their immediate needs are met, performance concerns are just a small annoyance. And generally they will continue to ask for more features rather than performance improvements as long as the app remains usable.
Re: TodoMVC App Written in Vanilla JavaScript
#90Earlier 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.
Well then you've never seen poor people uninstalling apps from their cheap smartphones because they need to install and use a different one ;-) that you don't see it doesn't mean it's not there