In all cases you're going to store and manage your state some place. What you describe is managing the state using the DOM itself, which would indeed be easier

In all cases you're going to store and manage your state some place. What you describe is managing the state using the DOM itself, which would indeed be easier if the DOM wasn't directly tied to the screen, but which would still be very cumbersome because of the lack of appropriate APIs for managing the DOM as an application state. If you were to go in this direction, you would eventually make the DOM less DOM-ish, and the painting mechanism more DOM-ish, effectively shifting everything one place and going full circle back to the frameworks.