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.
[dead]
Re:Why I'm still using jQuery
by robin_reala on Monday May 27, 2019 @08:20AM
(#20021537)
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.
I trust this guy, he has more years on his counter.
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.
Re:Why I'm still using jQuery
by robin_reala on Monday May 27, 2019 @10:04AM
(#20022294)
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?
> It has failed spectacularly at that goal
No, it allows apps to don't rerender whole page on every click, so it works just fine.
Yes. That should make it possible for such pages to be faster. In practice, the opposite is usually true.
Of course re-rendering whole page (with multiple queries on the server-side) is faster then sending 1 request, how could I even have doubts.
Cool story.
So, why?
Oh great Eugene, do humble us with your knowledge. What makes an SPA a great choice?
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).