|
> That's an implementation issue. Right, but like I said, I'm not a purist about this, I just think that maybe SPAs should only be rolled out if the implementation actually works. To circle back around to Google Maps, this is an app that had working links, and the introduction of more Javascript made them worse. So I'm not saying get rid of all Javascript, I'm saying that if you swap out `<a>` tags and it results in broken browser functionality, that's a scenario where just using native tags would result in a better experience. Twitter/Youtube/Maps are choosing to go down this route even though the implementation is worse. If they didn't have implementation bugs and navigation didn't break on sites like Youtube, and I could copy and paste links from Google Maps, and I didn't have laggy text input on Twitter -- well, then I wouldn't be complaining about any of this. It's not really about Javascript being bad, but we can both agree that if a company tries to rewrite a website as an SPA and it results in a more buggy experience, then they should hold off on that and they shouldn't just plow forward with the implementation anyway. That has nothing to do with SPAs in general being evil, but even the act of saying "a Javascript-heavy SPA solution should only be pushed if the experience is better than the normal one" feels like I'm saying something revolutionary, and I don't really get what would be controversial about this opinion. Only push a Javascript heavy solution if your solution works, if it results in more breakage than the site had before that solution, then the engineers are moving in the wrong direction. I don't know if this is a controversial thing to say, but I would say, "only push an SPA if you don't have a bunch of implementation issues". And I think that's where sites like Youtube and Twitter are falling over, in those cases their implementations are either broken because of tracking or just complexity, or something -- but it would have been better for them specifically to have not turned their sites into SPAs, because they can't seem to get rid of the implementation issues and their older sites didn't have as many showstopping bugs or performance issues. I agree with you that sometimes this kind of partial updating can result in great, quick apps. But in practice, Nitter is faster Twitter is for reading tweets. So if I go to Twitter and I'm not signed in, and I'm just reading Tweets, that's an experience that Nitter is just flat-out better at providing in a more performant way. So it's not that all SPAs are evil or that they should always be avoided, but clearly in Twitter's case the introduction of an SPA didn't make the site faster or better, the low-JS solution ends up outperforming it on multiple key metrics. |