> I could have chosen to rebuild the entire UI as a template string as a function of state, but instead, it is ultimately more performant to create these DOM helper methods and modify what I want.<p>I like the effort, but this is basically admitting defeat. Just naively using template strings and re-rendering the whole app on every change of state _is_ too slow, and so the author falls back instead to rendering via a series of bespoke methods that mix logic and template strings and DOM methods all interspersed. It still has all the shortcomings of 00's-era PHP, or piles of jQuery.<p>It is possible to do one step better than this still with vanilla js, if you use Web Components / custom elements. That way you can have each type of custom element (todo-app, todo-list, todo-item, etc) have its own render function using template strings, and you can still sneak in custom optimizations (like direct DOM insertion when adding and item to a long list instead of re-rendering).<p>But in the end, it's just so wonderful to be able to have reactive state and efficiently render your app from the state, and forget about all the rest.<p>We developed El.js[1] with all of this in mind, to be as little as possible on top of vanilla js and web components, to get the reactivity and efficient rendering.<p>[1]: <a href="https://github.com/frameable/el" rel="nofollow">https://github.com/frameable/el</a>