4 ms·

> ...might end up rediscovering up close why people moved to Vue/React/Angular in droves instead of jQuery Vue, React, and Angular are fundamentally MVC in di

> ...might end up rediscovering up close why people moved to Vue/React/Angular in droves instead of jQuery Vue, React, and Angular are fundamentally MVC in disguise: a "controller" modifies some state (model) and on the next render cycle, the "view" is updated by the library/framework to draw the change. (Simplifying here to ignore details of the implementation like vDOM, components, etc.) Not so with jQuery. You draw the change directly. You can write a framework on top of jQuery to achieve something similar where a model/state gets updated -> detect the change -> jQuery to draw the change. (That might be interesting or perhaps something like this already exists.) In other words, in Vue, React, and Angular, you are discouraged from doing direct DOM manipulation; you always modify some state from which the framework applies the DOM changes and in jQuery, it's the opposite: you directly manipulate the DOM in reaction to some action. So the reason why people moved is that an MVC-aligned paradigm is ultimately more productive and a better abstraction than directly manipulating trees of rectangles.

kijin 2y ago
Very true. But it doesn't matter if you're building a typical website instead of an SPA, and the only "state" you care about are little things like whether a checkbox is checked. Even in that case, many of the fancy effects people used jQuery for can now be implemented in pure CSS. These days, when I'm working on a simple blog or landing page, I find that I don't even use much JS at all. It's HTML and CSS, not full-blown SPA frameworks, that have gradually replaced jQuery for me.
- CharlieDigital 2y ago
  Yes, agree. I do think that using either web components or Lit offers a nice layer of encapsulation and reuse as well as some convenience. There are a lot of options nowadays.
spinningslate 2y ago
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/ https://htmx.org/
- CharlieDigital 2y ago
  > 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.
stogot 2y ago
Why is it more productive? I like your description, but this statement needs elaboration. When I look at modern frameworks, all I see is unconstructive complexity that sucks productivity
- SquareWheel 2y ago
  I would say that it is structured complexity. Modifying a reactive variable is more complex than editing the DOM directly, true, but it minimizes the number of sources of truth. The developer no longer has to worry about keeping the on-page elements and JS variables in sync; that happens automatically. Managing just your application's state, while letting some template logic know where to embed that info into the app, scales far better. If you measure complexity strictly by the amount of code running, then a React or Vue app will likely be more complex. If you consider just the actual application logic, it's usually far simpler. This is especially true if you utilize components, which lend themselves well to rapid development with fewer side effects.
  - alerighi 2y ago
    The complexity is the infrastructure you need to build an application with a JS framework, versus just including the libraries that you needed in script tags and done. Do we really need a build system for JS? Probably to make something as complex as Google Docs that is an application that runs in the browser yes, but not for 99% of web pages that you see each days.
    - SquareWheel 2y ago
      Complexity has to live somewhere. We use abstraction to better manage it, and keep our codebases scalable and manageable. Yes it's not as efficient as it would be if every single function call were carefully planned for and orchestrated, but that's not feasible for modern applications that do many things. It's the same way on the desktop side. Writing everything in assembly instructions would technically be the least "complex", but it'd also be utterly insane and error-prone to do it that way. Even mid-level abstractions like C++ are hard to get right. It's why many modern apps are built in higher-level abstractions, because they're easier, more reliable, and fast enough. It's really no different for a website. You can put all of your state in one place, bridge different libraries, and manually sync DOM changes, but you're essentially just frontloading the complexity. Abstraction is an important concept in structuring your codebase into clean and maintainable code, even if it is technically more complex. I won't argue that React doesn't get overused for otherwise-simple pages, but many pages are not simple. The web today is full of interactions, tabs, dropdowns, search bars, notifications, modals, and tooltips. It all needs to respond to your device's form factor and input method. Every network request requires error handling. It needs to be routed, cached, and served smoothly and correctly. It's a lot. It's a lot to manage in one layer. I am content to let some of that complexity be managed by Vue, or React, or whichever framework we're discussing. If it lets me worry just about my application's logic, and it simplifies the templating, error handling, routing, and so on, that makes things easier and less error-prone for me. Honestly, I've written plenty of web apps in vanilla JS. I've experimented enough with closures, IIFEs, classes, and other techniques for managing state. It really doesn't matter how careful you are, any sufficiently-complex project will always turn into spaghetti. Frameworks help us stave that off, at least for a little while. Their component-based architecture makes relationships more explicit, and much easier to isolate. I particularly like Vue's Single-File Component (SFC) concept which organizes components into logic, template, and styling. Not all frameworks require a build system though, and there's plenty of options available for tackling smaller problems. Alpine is great for reactive data. htmx helps manage apps with many server calls. You don't necessarily need the full React or Vue package, if your app isn't so complex. But if it is, I think you'll be glad to have them.

kijin 2y ago

Very true. But it doesn't matter if you're building a typical website instead of an SPA, and the only "state" you care about are little things like whether a checkbox is checked. Even in that case, many of the fancy effects people used jQuery for can now be implemented in pure CSS. These days, when I'm working on a simple blog or landing page, I find that I don't even use much JS at all. It's HTML and CSS, not full-blown SPA frameworks, that have gradually replaced jQuery for me.

CharlieDigital 2y ago
Yes, agree. I do think that using either web components or Lit offers a nice layer of encapsulation and reuse as well as some convenience. There are a lot of options nowadays.

spinningslate 2y ago

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/ https://htmx.org/

CharlieDigital 2y ago
> 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.

stogot 2y ago

Why is it more productive? I like your description, but this statement needs elaboration. When I look at modern frameworks, all I see is unconstructive complexity that sucks productivity

SquareWheel 2y ago
I would say that it is structured complexity. Modifying a reactive variable is more complex than editing the DOM directly, true, but it minimizes the number of sources of truth. The developer no longer has to worry about keeping the on-page elements and JS variables in sync; that happens automatically. Managing just your application's state, while letting some template logic know where to embed that info into the app, scales far better. If you measure complexity strictly by the amount of code running, then a React or Vue app will likely be more complex. If you consider just the actual application logic, it's usually far simpler. This is especially true if you utilize components, which lend themselves well to rapid development with fewer side effects.
- alerighi 2y ago
  The complexity is the infrastructure you need to build an application with a JS framework, versus just including the libraries that you needed in script tags and done. Do we really need a build system for JS? Probably to make something as complex as Google Docs that is an application that runs in the browser yes, but not for 99% of web pages that you see each days.
  - SquareWheel 2y ago
    Complexity has to live somewhere. We use abstraction to better manage it, and keep our codebases scalable and manageable. Yes it's not as efficient as it would be if every single function call were carefully planned for and orchestrated, but that's not feasible for modern applications that do many things. It's the same way on the desktop side. Writing everything in assembly instructions would technically be the least "complex", but it'd also be utterly insane and error-prone to do it that way. Even mid-level abstractions like C++ are hard to get right. It's why many modern apps are built in higher-level abstractions, because they're easier, more reliable, and fast enough. It's really no different for a website. You can put all of your state in one place, bridge different libraries, and manually sync DOM changes, but you're essentially just frontloading the complexity. Abstraction is an important concept in structuring your codebase into clean and maintainable code, even if it is technically more complex. I won't argue that React doesn't get overused for otherwise-simple pages, but many pages are not simple. The web today is full of interactions, tabs, dropdowns, search bars, notifications, modals, and tooltips. It all needs to respond to your device's form factor and input method. Every network request requires error handling. It needs to be routed, cached, and served smoothly and correctly. It's a lot. It's a lot to manage in one layer. I am content to let some of that complexity be managed by Vue, or React, or whichever framework we're discussing. If it lets me worry just about my application's logic, and it simplifies the templating, error handling, routing, and so on, that makes things easier and less error-prone for me. Honestly, I've written plenty of web apps in vanilla JS. I've experimented enough with closures, IIFEs, classes, and other techniques for managing state. It really doesn't matter how careful you are, any sufficiently-complex project will always turn into spaghetti. Frameworks help us stave that off, at least for a little while. Their component-based architecture makes relationships more explicit, and much easier to isolate. I particularly like Vue's Single-File Component (SFC) concept which organizes components into logic, template, and styling. Not all frameworks require a build system though, and there's plenty of options available for tackling smaller problems. Alpine is great for reactive data. htmx helps manage apps with many server calls. You don't necessarily need the full React or Vue package, if your app isn't so complex. But if it is, I think you'll be glad to have them.