> This is also why I am not a big fan of things like incremental-dom. It ignores the whole idea why we wanted declarative DOM handling in the first place and re

> This is also why I am not a big fan of things like incremental-dom. It ignores the whole idea why we wanted declarative DOM handling in the first place and replaces it with a very imperative and side-effect heavy API. In that case, just use the DOM directly. incremental-dom still solves the declarative DOM problem. You express exactly what DOM you want in a template that compiles to incremental-dom calls. It's just a more efficient way to do what React does, skipping the intermediate representation. Why does it matter if the incremental-dom calls have side effects, if the end result (of an updated DOM) is the same? If you use the DOM directly as you suggest, you end up writing a lot of manual state transitions, and probably bugs from not covering and testing absolutely every transition. incremental-dom doesn't have that problem because it's updating the whole tree for you, just like React.