> 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).
With the way Reddit tries to shove it's app down your throat while using their SPA the cynic in me wonders if it's not designed to be as painful as possible if you persist. The last time I tried, I got THREE separate UI components prompting me to use the app.
I am not a proponent of SPAs, in fact quite the opposite, but I think Reddit has done a disservice to the pro-SPA community because their engineering team is completely useless and their redesign is a train-wreck. Thus I think using Reddit as an example of what SPAs can or can't be is dishonest.
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.
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.
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.
As with many things, the answer is it depends on what you do. I inherited an app that serves about 1m requests a day, and server-side rendering of the HTML is one of the reasons why we're going to decommission this app, as the performance of the server-side rendering here is atrociously bad/unacceptable. We reimplemented many of the same features in a SPA that does a lot more overall and the performance difference is night and day between the two.
Been here for just about all of this "web" thing. When I'm pleasantly surprised by how fast & light something is it's almost always server-side rendered or static. Only benefit of SPAs is that at least they're more likely to employ responsive layouts, but then they so often also manage to have bugs that break the page in certain layouts on certain browsers (overlays/modals are a biggie) that it's kinda a wash. And that's not an inherent benefit to SPAs, just one thing they usually get sort-of right that's less likely to be correct in oldster template/static sites.
I'm old enough to remember when AJAX was supposed to make the web feel faster. It has failed spectacularly at that goal, in fact, whatever potential it may have had. It gave us much better spying on users though, so... thanks?
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.
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.
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.
If you need state management, build a very complex app, etc. ... don't.