> Both are resolved so that you can have an SPA that basically starts out as an MPA and upgrades itself to an SPA, though it’s common for scripting to still be required where it shouldn’t be.
Yuh, I guess my disconnect is that I tend to avoid sites that don't work at all without JS. I'm willing to enable JS if I care about the site (and it at least renders something without JS), but I'm not prepared to drop my pants for some random sales site that gives me a white screen if JS is disabled - someone else gets my business.
> Some people don't seem to understand what the whole JS SPA thing is about, and it's quite strange to me.
Most people understand the promises of SPAs, but there are several forces that play against everything you said:
- Some websites don't need a desktop experience yet they go the SPA route.
- SPAs are -in my experience- significantly harder to get right than server-rendered apps. For sites that are a good fit for "the regular old web" we are speaking about at least an order of magnitude here.
- Oftentimes it is companies/products with significant resources that embark on the SPA ordeal. This usually means that they also have several teams demanding product analytics, A/B testing and what not, and hence their sites end up loaded with random shit (gtm, analytics, optimizely, facebook pixel and the kitchen-sink).
For all these reasons, it takes an extraordinary (i.e: significantly better than average) team, from the developers all the way to management, to deliver on the SPA promise.
As a result, most SPAs suck, and hence a lot of people cultivated an aversion to them. It really is that simple.
> doing SPAs without fallback for non-js clients is horrible
Why? The number of customers that a) don't use javascript and b) would pay for a service only if they have a non-javascript version is incredibly small in my experience. If the service has value, non-javascript users will enable javascript to use it.
> the code errored or something else went wrong. You need to refresh the whole page if something goes wrong, which results in having to load a ton of JS every again, negating all possible savings in time and data usage.
Not to mention that some SPA doesn't maintain state, and all the sudden one need to jump through the the process all over again. Personally SPA seems to try reimplement a lot of browser feature all over again in client side JS.
>I don't fully understand why packages like this are so popular.
I consider 'iseven' and 'isodd' to be signs that Javascript is a hellaciously engineered piece of crap that should be avoided at all costs. They're popular because Javascript is garbage.
How to say "I haven't listened to the talk" without saying "I havent' listened to the talk".
The accompanying commentary to that slide is "Here's a non-exhaustive list of thing people will tell you are terrible about SPA: You will need to load a bloated JS framework. It's always bloated, of course."
And then he goes on to explore the validity of these claims ("They are largely valid").
>I have seen too many sites collapse into an empty white page because whatever javascript they were running couldn't access a resource and the shitty JS framework just stopped, leaving me with an empty page.
It is even worse when these pages are basically images and text. SPAs have their place and people can develop them as they wish, but I fail to understand why these frameworks have become the go to solution for every page.
> In Toggle if you click start stop too quickly, to create a bunch of tasks to add, it doesn't register it.
> That's SPAs for you, there's always something a bit wrong with them, they're extremely hard to get right, unlike traditional web apps. I often find myself rolling my eyes at YetAnotherPointlessSPA because there will always be something you have to fight with in it.
Okay, I'll bite: What would have been the alternative in these cases? Having each action submit a form POST to refresh the entire page, like in the 90s? Then you wouldn't have been able to click it multiple times in the first place, because each one would have caused a page refresh. Or are you saying that they could have implemented it in JavaScript without implementing an entire SPA? In which case, the problem sounds like it's with the logic, and has little to do with the fact that it's a SPA, so you would have likely seen the same bug regardless.
I totally understand all the frustrations people have with modern web apps, but your frustrations are with sloppy engineering, not with the idea of SPAs. I believe that, in most cases, the superior user experience that SPAs provide far outweighs the extra margin for error that comes with the territory.
> Some SPA implementations of SPA throw away progressive enhancement (a notable and noble exception is Remix). Therefore, you must have JavaScript turned on for most SPAs.
These are all issues, but the real issue is JavaScript itself (i.e., programming with wet noodles).
reply