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

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.

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

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.

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.

[1]: https://github.com/frameable/el