Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If Not SPAs, What?

macwright.com

Post reply on HN
Print view View original

21–30 of 456 posts

Re: If Not SPAs, What?

#21

Post by dfabulich »

IMO, TurboLinks + service workers are the way to go.

Not many people know this, but a service worker (previously called "local server") allows you to run a little web server in the user's browser that intercepts requests to your own web site. (There's no open IP port.)

The service-worker web server can proxy requests to the remote server, and even build/store entire pages on the client side, enabling offline support. Service workers also have access to a local database, IndexedDB, running in the user's browser.

You can build a very fast web experience this way. You can easily cache individual pieces of a web page and glue them all together.

For example, you can easily implement server-side includes https://en.wikipedia.org/wiki/Server_Side_Includes or edge-side includes https://en.wikipedia.org/wiki/Edge_Side_Includes but running on a server that's running on the client.

Re: If Not SPAs, What?

#22

Post by firefoxd »

Maybe this is more suited to stackoverflow but, how do you load with turbolinks when the two pages use different assets? Let's say each page have different js script tags.

Re: If Not SPAs, What?

#23

Post by deefour »

ForHackernews wrote: post #20
ckorhonen wrote: post #18

I used Turbolinks for the first time on a new Rails app about 2 years ago and was floored by the impact - it felt like a SPA in terms of no page loads and overall speed. I'm convinced that this is the solution for the majority of use-cases, combined with selective usage of either React components or something like Stimulus where you need more sophisticated UI components.

Is there an equivalent of Turbolinks for something like Django? Or even for MVC PHP apps?

Turbolinks isn't specific to rails.

Re: If Not SPAs, What?

#24

Post by Griffinsauce »

stevebmark wrote: post #11

The future is Next.js with SSR first and selective client side hydration. Ignore the jamstack, it's going to lose and go away. Requiring a JS download first to show a dynamic site is a recipe for bad performance.

Isn't SSR (or even better SSG) the M in JAM? It's a marketing term anyway and it doesn't really need to "lose", we can just talk about the technologies instead.

Next.js gives you a great toolbag to choose from for each challenge, it's definitely going to stay around and keep growing like crazy.

Re: If Not SPAs, What?

#25

Post by candiddevmike »

vmception wrote: post #16
candiddevmike wrote: post #13

Our app ( https://domestica.app/login ) is a pretty good (IMO) example of a blazing fast SPA. It uses Mithril and copious amounts of chunking to make the bundle size extremely small.

while breaking my back button nothing to do with the SPA of course

Which part breaks your back button?

Re: If Not SPAs, What?

#26

Post by vmception »

candiddevmike wrote: post #25
vmception wrote: post #16

Earlier quoted context omitted.

while breaking my back button nothing to do with the SPA of course

Which part breaks your back button?

on ios safari when I click that link, and then swipe back or press back, instead of showing me this hackernews thread it shows me that site again

Re: If Not SPAs, What?

#27

Post by eyelidlessness »

stevebmark wrote: post #11

The future is Next.js with SSR first and selective client side hydration. Ignore the jamstack, it's going to lose and go away. Requiring a JS download first to show a dynamic site is a recipe for bad performance.

I would also prefer something like Next.js with partial hydration. But what I want in that is probably a much bigger ask: I want the partial hydration to be performed automatically with static analysis. Something like Svelte (real DOM codegen, no need to ship a library to the browser) would be especially nice, but I don’t want to give up JSX. In the end, this is probably well outside the scope of a framework coupled directly with React, and I suspect that if I want it badly enough it’s something I’ll need to build myself.

Re: If Not SPAs, What?

#28

Post by ceejayoz »

candiddevmike wrote: post #25
vmception wrote: post #16

Earlier quoted context omitted.

while breaking my back button nothing to do with the SPA of course

Which part breaks your back button?

On my browser (Firefox, on OSX) it loads /loading then /login. When I go back, that takes me back to /loading, which forwards me to /login again immediately.

Going back requires holding down the back button so I can skip that history record. Illustrated: https://imgur.com/a/zFaGw4a

(Quite a few sites screw this up. It's very annoying.)

Re: If Not SPAs, What?

#29

Post by k__ »

Griffinsauce wrote: post #24
stevebmark wrote: post #11

The future is Next.js with SSR first and selective client side hydration. Ignore the jamstack, it's going to lose and go away. Requiring a JS download first to show a dynamic site is a recipe for bad performance.

Isn't SSR (or even better SSG) the M in JAM? It's a marketing term anyway and it doesn't really need to "lose", we can just talk about the technologies instead. Next.js gives you a great toolbag to choose from for each challenge, it's definitely going to stay around and keep growing like crazy.

I thought so too.

JAMStack is Next.js with SSG+CSR.

Re: If Not SPAs, What?

#30

Post by candiddevmike »

ceejayoz wrote: post #28
candiddevmike wrote: post #25

Earlier quoted context omitted.

Which part breaks your back button?

On my browser (Firefox, on OSX) it loads /loading then /login. When I go back, that takes me back to /loading, which forwards me to /login again immediately. Going back requires holding down the back button so I can skip that history record. Illustrated: https://imgur.com/a/zFaGw4a (Quite a few sites screw this up. It's very annoying.)

This is great, thank you for sharing. We primarily test in Chrome which doesn't seem to display this for whatever reason. Should be an easy fix to remove the history for the loading page.
Post reply on HN