[vbo]

> Are they using Javascript to improve experience and development speed?

Some, yes. This was in the spec sheet for a large ecommerce website I helped rebuild with modern(er) technologies.

> If a Twitter textbox is lagging while someone types

That's an implementation issue.

re Youtube, I haven't had the experience you describe, but having had to develop the framework side of SPA navigation into something robust and useable, keeping the current page on screen after the a new url was history.push'ed while preloading the data necessary for the next render and managing the scroll position, I can confirm it is a pain. I expect Youtube has the right kind of resources for the task but it happens, probably at a higher rate of bug incidence than regular frontend button-broke-the-site issues.

Implementation issues are going to happen whether you use JS or not, but I find building with JS and with modern frameworks a joy (although a lot of things can be improved) compared to server side alternatives. As with everything though, this is a matter of preference.

[kaba0]

But what’s the whole point of rewriting the URL and rerendering in JS the whole page? I’m fairly sure that browsers are really great at caching, so no additional HTML, JS should be downloaded and the change might very well be faster with better history and UX if we drop SPAs.

[vbo]

The overall experience feels (and is) faster as you only need to update the DOM, not recreate it from scratch, so you're not rerendering the whole page. There's also less processing required on the server as you're only requesting the piece of data you know will change and the response comes back faster. The history API makes going back and forth seamless, as if you were browsing the "classical" way. But this comes with additional complexity which is sometimes not dealt with correctly.

[tommek4077]

Only if you use 8k$ Macs. Not for normal people.

[johnisgood]

Perhaps it is just poorly written, or maybe it is the animations that are making it look like it is slower than it should be. I created a simple website where I update parts of the DOM, and it is super fast. I have the opposite experience on known websites.

[bmeski]

Totally agree. I implemented a page with tons of posts on it that will hide the posts before the provided cursor in the url and I simply show hide them with display: none. Even if it’s 100 posts hidden, the images are lazy and clicking “show” unhides all of them immediately. If new posts come in we simply append to the top of the parent container with basic DOM apis.

The app were replacing with this page is heavy react and there’s a long visual stutter during the show hide because it has to render them all. Not simply show/hide. They actually load more bits to lazy load the posts in JS than to simply send the html and hide/show.

[danShumway]

> 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.