"Everyone wants a SPA" is such bullshit. GitHub used to just load for a hundred milliseconds and then show me everything I needed; now it loads for a hundred milliseconds and shows me a spinner while it does another roundtrip for some javascript, then parses and executes that giant truckload of code, then does _another_ roundtrip to get the JSON or whatever describing the data I actually want to see, then executes its boatload of javascript to update the DOM. Reddit is the exact same story; in the time it used to take to show the content, it now manages to load a spinner. Facebook also just spends the first few hundred milliseconds loading loading indicators. YouTube too.

Browsers are awesome at rendering HTML. They render each element the instant just the necessary bytes have crossed the wire. Browsers can't help you if you need to first load the HTML, then load the scripts, then load the complete giant JSON blob from your API, then add the elements to the DOM.

I'm in Norway, with high ping to the US. My ISP isn't the most reliable all the time. That nice server you have 0.01ms ping to, where you can't notice the difference a few extra roundtrips makes? Well, each roundtrip might take an extra few seconds for me.

The worst example I can think of right now is: GMAIL..

God it went downhill lately. It can take 20 seconds on a decent machine for it to load all the shitty plugins i dont even need but still block me from using a mailbox..

Loading "html only" version is pretty much instant and has everything I need to use the demn mailbox..

Wow, I had this exact thought the other day. I loaded the page, and just sat there and watched this animation on the screen. "What is it doing" was all I could think. All I need it to do is load the subject line of the first however many emails in my inbox. It can't be that complicated.

try adsense / adwords / google search console if you think gmail is slow. will be an interesting experiuence

GitHub works without JS just fine. Switch it off.

In fact, I'm pretty sure Github is rendered server side for the first load. You shouldn't be seeing any spinners. I'd check if I wasn't on my phone.

Nope, the content is loaded dynamically from their API after the rest of the page has loaded: https://i.imgur.com/Kxs9l7j.mp4

Sure, the list of my repositories is server rendered, but I already know my list of repositories. The thing I'm waiting for 99% of the time when loading github.com is to see if there's any new activity.

Sorry about the graphical glitches, blame nvidia or xorg or gnome or something.

That's disappointing. You're absolutely right that that particular page should be SSR'd.

Likely because the list of repositories changes infrequently, so it's a better candidate for caching. They serve what then can quickly, quickly, then pull in the naturally slower stuff later.

Like 5-10 years ago, writing.com updated their content from loading static pages to be more dynamic.

What they actually did was continue loading the content statically, then hide it behind a 1 or 2 second loading spinner that wasn't actually loading anything.

Seems like users have just come to expect spinners...

(I don't know how the site currently works, haven't been there in a long time)

Github is annoying. Some pages are SSR some aren't. The js is quite resource hungry so I tend to keep js off for github until I get to a page that needs it.

Have you considered just stop using these shitty "websites" ?

I think we’ve done a great job of convincing each other within our tech bubble than everyone wants a SPA. Not sure the general public cares for our enthusiasm though.

This, this, this. Users didn’t ask for magazine websites - which should be serving up, y’know, images and text - to sit and spin on my phone while all the Javascript libraries load. Users didn’t ask for these things; we as a community just decided to foist it on them.

A lot of the slowest stuff on websites are trackers that are being foist on developers to foist on the users (if the developers even have control over the trackers, like with GTM)

so you say, but i get the same when using ad blockers or visit sites without ads.

Everyone(well almost) wants a SPA or at the very least non reloading pages. No one wants to reload the page with every action they perform or if only a part of the area on screen needed to be updated and the page was reloaded anyways.

> No one wants to reload the page with every action they perform or if only a part of the area on screen needed to be updated and the page was reloaded anyways.

That's what developers talk about. What normal people care about is the user experience: did an action take a long time, did it reset their context or fail into a confusing state, does the reload button work / can they share a link with someone else, etc.

That's an important distinction because using an SPA means an order of magnitude more code has to work perfectly before it's not a regression on one of those points. It's a lot easier than it used to be but, as we've seen over and over again, there are still many cases where people have a bad experience because the developer assumed everyone is fine downloading 5MB of JavaScript before displaying text & images, errors never happen, etc.

I'd say I am a fairly layed back guy on web pages, I don't run no-script, I just care for being able to navigate a web page reasonably well.

To me it just seems that most SPAs that I see, are either so small that the page load of a django app would also be fast enough, or they are so overloaded with stuff and advertising, that I feel like the performance benefit of SPAs has just been reinvested in cluttering more. Also, facebook, who built react, don't seem to have embraced the SPA.

I guess there will be a sweet spot, also on whether you build "pages" or "apps". Maybe there is a point of interactivity that warrants a SPA. I just don't feel like many websites hit this, like microblogging/twitter/etc.

Yet, here we are at HN.

> no one wants to reload the page with every action they perform or if only a part of the area on screen needed to be updated and the page was reloaded anyways.

well not 'no one'. When 90% of the page is to be replaced, a full reload gives better feedback and synchronicity.

Everyone (well almost) wants a server-templated site or at the very least a functioning back button. No one wants to sit and wait for 3 million lines of JavaScript to parse and run with every press of the back button (and probably not even get to the same state as before!).

Yes, I know there are some stellar SPAs that actually work. But I can't see why they're necessary 97% of the time and it really bothers me when I see a SPA where one isn't needed that breaks basic functionality like back buttons and right-click and all that other jazz.

If it's a traditional website and not an app, then I'm totally fine with it reloading every time you navigate to a new page or submit a form. Modern servers and browsers are plenty fast for full page reloads, as long as there isn't anything extra slowing down the load or rendering.

Most people say they are, but when you actually measure it you find engagement metrics are better for SPA sites, especially for ecommerce and social. Quite simply people spend more money if they can click fewer times. And thus we have things like infinite scrolling and ajax.

Engagement metrics measure what people do. That may not be what they want.

Care to link to those measurements ?

I've never met one of those users that care wether you reload a page or not.

I've seen people that care if you create a SPA that shows a spinner for 10s before allowing the user to get any of your content, but those are not as numerous as Google's webmaster tools makes one think.

I've seen plenty of people that are perfectly fine with a page spinning for 90s before getting any content if the page has the data they care about.

So, any out of context claim like "everyone wants a SPA" is wrong.

Serious question: Why not have them learn Django/Python?

It's not that difficult if you're a decent programmer, and if they're not then why hire them?

SPAs don't need to be complicated, people have been developing native GUIs for decades. The source of the problem is the browser event and rendering loop which remains a mystery.

Yes, exactly. But to me in many ways that's application programming on the Web vs. Web programming. It may seem pedantic but it's two separate skill sets, and my teams that do each are separate (I have front-end devs that are basically application programmers using Angular/React and front-end devs who are CSS/JavaScript/Animation specialists -- they aren't the same teams).

This comment makes me realize, I need to get back to my RoR roots and build a server side rendered site again to see what I've forgotten with building React sites for a while.