re: When do you build a SPA vs. a server-rendered app? VIEW POST

re: Given recent developments like service workers and IndexedDB for storing data offline, could SPA's not work better in limited network situations? I...

I think it depends on the user story and your own capacity to make use of these tools. If you are getting a lot of first time users on the device or you just aren't getting enough local cache hits in general, the experience could suffer.

It's probably getting better but I feel like the last few years has seen a lot of people striving for the ideal web experience and falling short by rolling the dice on apps that take a lot of coordination to get right. But I'm mostly thinking about content-oriented websites with a basic offering that has become way to heavy and complicated on the front end. If the UI interactions are inherently complicated and require ongoing state maintenance, it's worth taking on those.

The app I'm working on doesn't require much local state, but it'll frequently be used repeatedly by the same person in low connectivity situations, so I'm thinking of going the SPA route, to make as much use of local storage as possible.

Cool. I think you're making the right call then. Any idea what the stack will look like specifically?

(P)Reat on the frontend, Django on the backend. Possibly preact.io in between the two, but I'm not sure about this, since it potentially increases the amount of data you download again; The cached JavaScript may already have the template you need in order to render the frontend, yet the server sends a bunch of markup.

If I remember correctly, you're using Preact on dev.to, right? Are you noticing the differences with React much?

That's the plan, but so far it's still just a plan and has only been fooling around with it outside. Haven't implemented it yet in anything on the site yet. We're pretty methodical with this stuff.

Code of Conduct Report abuse