3 ms·

If JQuery is all you need to get the job done, go for it. It's still fast, simple and easy to develop. If you need state management, build a very complex app,

by JanSt 7y ago

If JQuery is all you need to get the job done, go for it. It's still fast, simple and easy to develop. If you need state management, build a very complex app, etc. ... don't.

cyberferret 7y ago
This is pretty much it in a nutshell. About the only use case where I will look at a framework outside of jQuery is if I want complex state management, or be able to handle LOTS of updating hotspots on the screen. I'm a proud user of jQuery from way back in the early days, and still haven't found anything to beat it for writing a quick AJAX call to a back end from a web page.
arp242 7y ago
> If you need state management, build a very complex app, etc. ... don't. I'm not so sure you do for many sites. Take something like Reddit for example; I don't think the new SPA redesign is any better than the old template-driven app. In fact, IMHO it's worse in every way. Part of that is just a matter of design and not technical, but part of it is just "SPA hell": CPU goes to 100% on load, takes ages to load stuff, etc. On the other hand, I find something like FastMail's web UI to be quite pleasant. So it certainly is possible, but I do think it's a lot harder to get an SPA right than it is to get a classic template-driven app right. It's also a lot more complex, which results in all sorts of problems. I don't think jQuery is the "perfect" way to develop stuff; the lack of structure means things can get messy (we've all seen that), but I'm not convinced that React is the best answer to that (just because A is imperfect doesn't mean B is the answer, a common fallacy in these types of discussions). I'm not quite sure what the best way is, and perhaps it already exists and I'm unaware of it, but in the meanwhile I prefer to stick with the "KISS" solution. If I look at the websites I really like using then they're all classic "progressive enhancement" ones, and not SPAs (in fact, FastMail is the only exception that I can think of). Either way, the post was mainly intended as "vanilla JS vs. jQuery", rather than "classic JS vs. modern SPA" (although they're obviously related discussions).
- EugeneOZ 7y ago
  SPA is by million times better than "classic template-driven" trash. I don't just "think" so, I have 7 years of experience with "classic templates" and 8 years with SPA.
  - robin_reala 7y ago
    Anyone can throw out a better-because-of-experience answer, and in fact I’ll do so now: I also have 15 years of experience in front-end dev and I disagree with your premise. It completely depends on what you’re trying to build, and SPAs are too heavily used at the light-interactivity end of the scale. We’re failing our users with brittle solutions that make us feel cleverer as developers.
    - martin_a 7y ago
      I trust this guy, he has more years on his counter.
    - EugeneOZ 7y ago
      Well, literally not anyone can "throw" such argument, only those who actually has an experience :) How many years of these 15 you are building SPApps? It's ok to disagree. I'm in a camp "API + SPA" after my experience. I know as fact that you can greatly increase UI performance this way and build multiple apps (desktop, mobile, web) using single API. So argument "I just think so" is totally not an argument for me.
      - robin_reala 7y ago
        I guess the other thing that you’re leaving out is the number of users your site will receive. For smaller numbers in a simpler market you can get away with more technically complex solutions. My last four years have been spent working on data driven platforms with a minimum of a billion individual visits a year, and for those typically prerendering the common parts and pushing them to a caching layer is much more computationally efficient and leads to a faster client. If you’re dealing with a lot of custom data for each user they that plays less well into the prerender solutions. But again, it comes down to how best to serve your users’ needs.
simion314 7y ago
It depends what you do with jQuery. Maybe you use a nice , well tested and full featured plugin (calendar, grid view) then jQuery works. Or if you want to manipulate html (you grab an html from a page and you want to export it as epub but you want to remove some stuff before, cleanup some styles, jQuery is much better at DOM manipulation then pure JS) IMO what you should never do is put your application state inside the DOM if you have a complex page/app.
- ehnto 7y ago
  Shopify is a great example. They have both, but in the right places. The websites themselves are not SPAs, because they don't need to be. A minicart is barely reason to pull in an SPA framework and architecture, so they didn't. But their live theme editor tooling makes full use of the power of an SPA.

by JanSt 7y ago

If JQuery is all you need to get the job done, go for it. It's still fast, simple and easy to develop. If you need state management, build a very complex app, etc. ... don't.

cyberferret 7y ago

This is pretty much it in a nutshell. About the only use case where I will look at a framework outside of jQuery is if I want complex state management, or be able to handle LOTS of updating hotspots on the screen. I'm a proud user of jQuery from way back in the early days, and still haven't found anything to beat it for writing a quick AJAX call to a back end from a web page.

arp242 7y ago

> If you need state management, build a very complex app, etc. ... don't. I'm not so sure you do for many sites. Take something like Reddit for example; I don't think the new SPA redesign is any better than the old template-driven app. In fact, IMHO it's worse in every way. Part of that is just a matter of design and not technical, but part of it is just "SPA hell": CPU goes to 100% on load, takes ages to load stuff, etc. On the other hand, I find something like FastMail's web UI to be quite pleasant. So it certainly is possible, but I do think it's a lot harder to get an SPA right than it is to get a classic template-driven app right. It's also a lot more complex, which results in all sorts of problems. I don't think jQuery is the "perfect" way to develop stuff; the lack of structure means things can get messy (we've all seen that), but I'm not convinced that React is the best answer to that (just because A is imperfect doesn't mean B is the answer, a common fallacy in these types of discussions). I'm not quite sure what the best way is, and perhaps it already exists and I'm unaware of it, but in the meanwhile I prefer to stick with the "KISS" solution. If I look at the websites I really like using then they're all classic "progressive enhancement" ones, and not SPAs (in fact, FastMail is the only exception that I can think of). Either way, the post was mainly intended as "vanilla JS vs. jQuery", rather than "classic JS vs. modern SPA" (although they're obviously related discussions).

EugeneOZ 7y ago
SPA is by million times better than "classic template-driven" trash. I don't just "think" so, I have 7 years of experience with "classic templates" and 8 years with SPA.
- robin_reala 7y ago
  Anyone can throw out a better-because-of-experience answer, and in fact I’ll do so now: I also have 15 years of experience in front-end dev and I disagree with your premise. It completely depends on what you’re trying to build, and SPAs are too heavily used at the light-interactivity end of the scale. We’re failing our users with brittle solutions that make us feel cleverer as developers.
  - martin_a 7y ago
    I trust this guy, he has more years on his counter.
  - EugeneOZ 7y ago
    Well, literally not anyone can "throw" such argument, only those who actually has an experience :) How many years of these 15 you are building SPApps? It's ok to disagree. I'm in a camp "API + SPA" after my experience. I know as fact that you can greatly increase UI performance this way and build multiple apps (desktop, mobile, web) using single API. So argument "I just think so" is totally not an argument for me.
    - robin_reala 7y ago
      I guess the other thing that you’re leaving out is the number of users your site will receive. For smaller numbers in a simpler market you can get away with more technically complex solutions. My last four years have been spent working on data driven platforms with a minimum of a billion individual visits a year, and for those typically prerendering the common parts and pushing them to a caching layer is much more computationally efficient and leads to a faster client. If you’re dealing with a lot of custom data for each user they that plays less well into the prerender solutions. But again, it comes down to how best to serve your users’ needs.

simion314 7y ago

It depends what you do with jQuery. Maybe you use a nice , well tested and full featured plugin (calendar, grid view) then jQuery works. Or if you want to manipulate html (you grab an html from a page and you want to export it as epub but you want to remove some stuff before, cleanup some styles, jQuery is much better at DOM manipulation then pure JS) IMO what you should never do is put your application state inside the DOM if you have a complex page/app.

ehnto 7y ago
Shopify is a great example. They have both, but in the right places. The websites themselves are not SPAs, because they don't need to be. A minicart is barely reason to pull in an SPA framework and architecture, so they didn't. But their live theme editor tooling makes full use of the power of an SPA.