Hacker News Reader

Comment by adrr | Hacker News Reader

They work perfectly fine under a SPA. SPA pushes history which lets the back button work and you can bookmark the URls. They have real URLs so you can create tabs.

Go look at https://www.target.com/ and see if you can tell difference between SPA and regular web page except for the speed aspect.

View on HN

Long ago Ruby on rails had a feature that sort of cached all links on the current page to make navigating to them faster. What happened to that? Would that not provide the same speed benefit? I'm ignoring the inefficient use of data here, ofc.

It's still a thing: https://turbo.hotwire.dev/

HTML fragments are not all that less efficient than JSON on the wire, and they are much more CPU efficient for low-powered client devices.

I think you're referring to TurboLinks. TurboLinks is still around. Building on that technology and moving towards HTML over socket is https://hotwire.dev/

That would be TurboLinks. It's going strong, and has seen significant improvements over time. Especially when paired with something like Stimulus and/or Reflex and/or Hotwire, you can make some _very_ snappy feeling server-side rendered HTML. At this point, I won't even consider making SPAs for anything unless the product owner has an incredibly compelling reason.

If you're curious what the modern state of server-side HTML Rails can be from the user's perspective, head over to hey.com and sign up for their free trial.

If you have a history with multiple pages each with their own URI then it is not a SPA. SPA means "single page application".

That's not true. Wikipedia [0] has a nice summary:

> A single-page application (SPA) is a web application or website that interacts with the user by dynamically rewriting the current web page with new data from the web server, instead of the default method of the browser loading entire new pages. The goal is faster transitions that make the website feel more like a native app.

[0] https://en.wikipedia.org/wiki/Single-page_application

You’re getting a downvote treatment but I kinda agree with you that SPA shouldn’t change history. But also, that was like the first versions of SPAs. The name stuck around (hello AJAX) while the underlying infrastructure and mechanisms great improved.

"Page" is clearly too ambiguous as almost any acronym will be. The main tenet of a Single Page Application at least used to be, before it was buzzworded into ambiguity, that the browser loads everything it needs once and makes round trips only for new data or incremental functionality. I think the same definition is still applicable, though. It never had anything to do with the information architecture of your UI or whether the majority of the screen might change between pages. And nothing to do with the URL or history; that's all orthogonal and now can and should be done with deep linking and the history API to allow people to have faster feedback and still interact with sites in the browser the way they always have.

Single page load is the definition. The page never reloads. Even the first SPAs would uses url hashes to change the url before pushState was adopted.

Reply on news.ycombinator.com