Hacker News Reader

Comment by 88913527 | Hacker News Reader

I don't understand the pivot back to SSR. Tearing down and standing up the entire DOM and page memory between navigations is just unnecessary work. Little things like maintaining scroll position in the page's navigation bar meaningfully improve usability and are only achievable with a SPA-based approach. This doesn't discount the challenges of building SPAs: bundle sizes, performance, etc. can be concerns if not managed. That's true of any application.

View on HN

the biggest problem with SPAs is none of the devs making them seem to remember how nice it was to open different pages of a site in different tabs. it's all horribly phone/tablet centric. middle-clicking doesn't even pop links in new tabs because they break basic browser features. you're lucky if you can even tell what's a real link and what's just going to rearrange your current page.

And even big sites built by well paid engineers that should know better (I’m looking at you Microsoft Azure!) have these issues! Sometimes middle click works. Sometimes it doesn’t. Sometimes right click open in new tab works. It’s so damned annoying.

This often has little or nothing to do with SPAs though. Quoted tweets on Twitter on twitter.com, for example, can’t be right- or middle-clicked for…absolutely no good reason. They just don’t render an <a>. Yet twitter.com is an SPA, and the little “30m” time indicator on a tweet is a fully working <a> that can be right- and middle-clicked and also does a client navigation when clicked normally.

Find in Page is another common casualty, and frustratingly it’s not always re-implemented by the SPA.

I think a lot of the ire against SPAs and other flavors of JS heavy pages would dissipate if devs made a point of trying to not unnecessarily break browser features and when breakage is unavoidable, furnishing replacements for the broken features that are as good as or better than the originals.

I don't understand this. All the popular/used routing frameworks by default support "open link in new tab" (render <a href="..." />, and listen to onClick to do SPA transition). Developer have to deviate from the easy and commonly documented way of doing things to break this. Any website that doesn't do this is fundamentally broken and built by teams that deliberately disregarded this behaviour.

I don't know which sites use what particular frameworks and paradigms (and I don't recall offhand which sites I've had these problems with), but I frequently have problems with sites that will, when I command-click on a link (standard shortcut to open in new tab on Mac), either open the page in the new tab and change the current tab to it, or just completely ignore my expressed desire and only change the current tab.

"But all the frameworks support doing the good thing! But only people who are bad at it make bad UX!"—well, it's still happening. No amount of contempt for the people doing it changes that.

This only happens now with an SPA due to laughable incompetence or deliberate disregard. You have to go out of your way to not use whatever Link component or similar tool provided by your SPA library/framework of choice. Any team that incompetent or negligent would be just as likely to break link behavior even if they aren’t using an SPA.

I’m surprised the criticism is still ubiquitous: it’s either 5+ years out of date or some people run into these terrible sites a lot for some reason.

These criticisms are still ubiquitous because these sites are still ubiquitous.

For example, less than 2 years ago someone did a "Show HN" of a Shopify front end they launched for their wife that was literally almost entirely nonfunctional. Not exaggerating.

https://news.ycombinator.com/item?id=27182932

Has that page changed a lot since then? Every link out of a dozen or so that I quickly checked were all real <a> tags that worked fine with middle- and right-clicking. I couldn't reproduce the back button behavior in your complaint either.

Yeah, Looks like the store has been fixed.

Fullstack react frameworks aren't purely SSR - they're isomorphic JS apps, which can render an initial page load serverside, then use clientside routing, suspense, serverside components, and clientside rehydration to progressively update the DOM without a full page refresh.

They are basically delivered as SPAs, with an integrated, isomorphic backend-for-frontend service embedded in the origin server.

They just don't feel like SPAs, because they have a multipage (routing) framework, and isomorphic rendering means those paths can be directly loaded from the server - while any subsequent navigation just updates your UI clientside.

In the case of static conteent-based sites, that SSR can even be done ahead of time, as a static built-time render, and the pieces of data needed to load different pieces of content into the SPA ('pages') get dumped out as static JSON resources. That's what Gatsby offers particularly as its specialty versus next.js.

Next.js can also do Gatsby-like static generation, but also update those generated pages if the content changes in the backend. They call it incremental static regeneration (ISR).

Yeah, there’s a ton of overlap between what different tools can do. Gatsby is just more centered on those usecases.

> Little things like maintaining scroll position in the page's navigation bar […] are only achievable with a SPA-based approach.

That’s not true. I wrote non-SPA web applications in the mid-aughts that maintained scroll position throughout server roundtrips, using JavaScript and storing the current scroll position in hidden fields upon submit. Even multiple scroll positions for nested panes. It also adjusted the saved scroll positions correctly when new elements were added to or removed from the page during the server roundtrip. This was encapsulated in a server-side HTML rendering framework.

Bored software engineers just want to keep making changes rather than moving to a new problem space.

Typically with SSR, only the initial load is server rendered. Subsequent navigations are client rendered.

Since when have SPAs figured out maintaining scroll position? That's not my experience at all.

What is going to change the scroll position on a state or "page" change? It's not that they figured it out, it's just the nature of a single page.

Er, lots apparently. Just now I was searching through posts on a Facebook event to find more details. I thought I finally found what I was looking for buried a few months deep and clicked it. It was the wrong item so I clicked back and Facebook scrolled me to the top of the event page again.

This is a common occurrence for me on Facebook on both mobile and desktop. It happens sometimes in Gmail too. I'm certain I could find a half dozen other examples given five minutes to go test.

Meanwhile HN happily preserves scroll position perfectly.

Modern SSR is for the first page load. After this all navigation and interaction is AJAX.

I think you might be using the term “SSR” in a non-standard way. In the context of JavaScript apps, SSR refers to an initial pre-rendering of the HTML of a SPA page on the first browser page load. Subsequent navigations in that same browser tab would render on the client just like an SPA that doesn’t have SSR.

You might be talking about what the JavaScript community has started to call “MPA,” which doesn’t seem to have converged on a clear meaning but seems to usually imply that some or all page navigations do involve a trip to the web server and an HTML response.

SSR isn’t actually rendering though… it’s generation of markup just like PHP does… sure sometimes it contains data to rehydrate the page just like early .Net components used to

The various JS frameworks seem to have taken a concept that was common and tried to rebrand it which just adds more confusion

In React I think it’s pretty fair to call it server-side rendering, to distinguish it from the usual client-side React render which manipulates the DOM. It’s just like that, except it renders to a string that can be returned in an HTML response (or streams: https://react.dev/reference/react-dom/server/renderToString#...).

It might be a little clearer now to call it “pre-rendering,” to distinguish it from React server components which also run on the server but which are quite distinct from SSRing client components.

Reply on news.ycombinator.com