Earlier quoted context omitted.
In short - the DOM was often used to store state. And this just isn't a very efficient approach. By some people, sure, but separating state and business logic from presentation and rendering logic was a well-known idea many, many years before React was around. I think the basic premise of the article here is correct. The important development with React that hadn’t previously been widely seen in front-end, JS-based w…
> but separating state and business logic from presentation and rendering logic I think the parent was referring to something different. When you work directly with the DOM your _view_ logic is stateful. In the old days (jQuery, Bootstrap, Knockout, etc) you were spending a time simply keeping your data and your view in sync -- and god forbid you were trying to re-use some of that view logic in multiple places.
Sure, and we had the era of one-way or two-way data binding libraries as a response to doing that manually, which at least provided a quick, simple solution to that problem in the relatively common case where you were presenting a set of mostly independent data points.
However, we also had designs that were based on ideas like MVC (the original one, not the server-side framework style that hijacked the term later) where you had part of your code storing the real state, event handlers triggering updates to that state in response to user actions, and rendering code that was triggered in turn to redraw the relevant parts of the UI or update the contents of any affected form fields. This sort of architecture was using essentially the same set of software architecture ideas that we’d been using in desktop or more traditional client-server software for a long time and applying them in the context of JS (or Flash, Java, etc.) running the browser.