[danShumway]

Sure it can, but is that the way these companies are using it? Are they using Javascript to improve experience and development speed? If a Twitter textbox is lagging while someone types, then that's a degradation in user experience, and a pretty fundamental one. I like autocomplete too, but I also like my text box not to lag, and maybe there's a middle ground?

I wouldn't say I'm a "purist" about this stuff, but I do feel like at least scripting should make the site feel better, not worse. A lot of these sites are really unpleasant to use, Youtube swapped over to this single-page model that I'm sure was very difficult to build, but sometimes it just breaks navigation for me. What fixes it is I reload the page. So it feels like, to me, even as someone who has Javascript enabled on Youtube, we have gone from an experience where navigation never broke for me on Youtube, to a situation where sometimes Youtube loses track of the fact I'm online and I need to refresh the page, or I hit the back button and it reloads the same video. That's a lot of extra Javascript for an experience that feels like a step backwards. The old Youtube designs all used Javascript, but they also had working back buttons and felt just generally snappier.

I went on Google maps recently and tried to quickly copy a number of website links for businesses into a text file: right-click copy link doesn't work. I can't copy a link for an external website, Google Maps is no longer using hrefs for literally the primary thing they were designed for.

And for what? It's not faster for me to open the external websites, they don't load quicker. I don't get URL previews or some crud. It's a link that doesn't work as well, all that's happened is there's a click handler that has fewer features than the link used to have, and maybe it's easier for Google to get a pingback? This isn't an improvement.

[nawgz]

> is that the way these companies are using it?

Since when do large companies do anything that isn't user-hostile and abusive? Of course FAANGs are trying to keep their walled garden more walled by reducing outgoing links, and Twitter's incompetence is legendary

The real question should be if this type of thing is improving the web at large or the capabilities we can develop "efficiently" on it, and while I would be willing to hear arguments either way, I can tell you I use JS/HTML/CSS in combination to introduce capabilities that would not be palatable without the JS component of that, putting aside whether I would be able to develop them as a bunch of standalone capabilities. Model editors, graph layouts, plugin architectures; we can leverage client machines to do more and more, and in a business setting delivering internal tools this is a great method of reducing costs across the stack - the laptops were already going to be purchased.

[johnisgood]

YouTube is super slow for me because of all the JavaScript. Plus I have to refresh because whenever I click on a link, it just takes too long to load, so I click refresh, at which point YouTube says I lost my Internet connection, which I did not. Sometimes I ended up having with some video with comments from the previous one. That, and I hate the "more space, less content" trend.

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