[spinningslate]

indeed, good description. Noting that vue etc. are MVC in the browser, with (typically) calls to json http endpoints on the back end to read/write data.

JQuery was born in a time of server-side rendering (SSR) where, in essence, MVC happened in the back end and it shipped html to the browser. In that model, the browser is essentially a terminal that renders output formed in the back end. JQuery was one of the early libraries to promote behaviour in the browser instead of "browser as terminal".

It feels like there's bit of a swing back to the SSR model, e.g. with the growing popularity of htmx [0] though there are still many strong proponents of the MVC-in-browser approach.

[0] https://htmx.org/

[CharlieDigital]

    > JQuery was born in a time of server-side rendering (SSR) where, in essence, MVC happened in the back end and it shipped html to the browser.

Yeah, I think this is nail on the head. It was also a time of smaller apps and smaller teams so it was easier to manage the state even with direct mutation on the DOM tree.

With bigger and more complex apps, you needed multiple teams and now it's not possible to really effectively track the state of the DOM if multiple teams could be manipulating it from different components.

You can see that shadow DOM and web components is one way of thinking about this problem. Separating the render from the state (a la Vue, React, Angular et al) is another.