6 ms·

Exactly, the best approach seems to be where the app is composed of traditional pages with server navigation between them, but each page is implemented as an SP

by prmph 5y ago

Exactly, the best approach seems to be where the app is composed of traditional pages with server navigation between them, but each page is implemented as an SPA. This approach eliminates the need for a client-side router, keeps any centralized page state small, and improves the SEO and bookmarkability of the app. I have implemented this architecture in several projects, and it’s effective

WillPostForFood 5y ago
Do you lose performance because each page has to load the SPA?
- prmph 5y ago
  Not much, if you use dynamic loading for heavy functionality that may not be used.
- unfocussed_mike 5y ago
  Not if the SPA subsequently takes over, (internally) routing links it recognises. (Nuxt does this)
trevex 5y ago
Isn’t this basically what NextJS and NuxtJS provide, if you only leverage their static rendering?
- deleted 5y ago
  [deleted]
hughrr 5y ago
The correct answer for this stuff, and it absolutely kills me saying this, is probably something like asp.net web forms.
- manigandham 5y ago
  Why does it kill you to say that? It’s the better and more productive option.
  - hughrr 5y ago
    Because I abandoned it thinking it was terrible. Then I spent a decade finding out how bad everything else was.
- mattmanser 5y ago
  Asp.net web forms absolutely sucked. They fundamentally misunderstood HTML and how the internet even worked. Modern Razor's pretty good (not Razor Pages, they also suck) which is probably what you mean. But it's not that much different from Rails, Laravel, Django, etc.
  - marcos100 5y ago
    By Modern Razor you mean Blazor components?
    - UltraViolence 5y ago
      Razor Pages.
  - hughrr 5y ago
    Yes I mean the original version of it. I'd love to watch people attempt to implement some of the stuff I pulled off with that back in the day now. Occasionally, very complex data driven page flows are required and you could nail that entire problem domain trivially with them. There is a very large and well known company with a front-facing product used by millions of people which took 5 years pissing around with three different front end technologies to reimplement what we did in 3 months with that and it was slower and heavier and basically reimplemented web forms in python in the end. It broke the the www intentionally because it sucked. And it still does.
dlisboa 5y ago
I disagree with that. There's no real reason for each page to be a separate SPA, most likely only a small part of that page will be interactive, and most of it will be cacheable. Extracting only the interactive parts of a page into components is what I'm talking about. In some cases that'll be all of the page, but there are very few apps that meet that criteria.
- prmph 5y ago
  Of course if only a small part of your app is interactive, then SPAs don’t come into the picture in the first place. My point is that for very interactive web apps, this is a significantly better architecture that a huge monolithic SPA
- LAC-Tech 5y ago
  I mean in this model, if each page is an SPA, then the line between an SPA and an interactive page is very blurry.
- tracker1 5y ago
  Not only that but bundle splitting allows for extra areas of the application to be loaded at runtime on demand. All of that said, I'm not opposed to approaches like Next/Nuxt/Aleph.
SinParadise 5y ago
>app is composed of traditional pages with server navigation between them, but each page is implemented as an SPA. I agree with this because you affirm my bias. Also because I've also had success implementing this structure. This makes sure that state of each page doesn't leak everywhere, which simplifies the state management. It also loads faster than a big SPA because you don't have to worry about bundle splitting!
LAC-Tech 5y ago
I've had this thought experiment before, but where I get stuck is - what happens when you want to share state between the pages? URL params, storing to indexedDB, sticking them in global variables - all viable solutions but all with their own issues. I'd be very interested to hear how you solve this, or if it's less of an issue than people might think.
KwisaksHaderach 5y ago
JS frameworks with a small footprint are suitable for this.

by prmph 5y ago

WillPostForFood 5y ago

Do you lose performance because each page has to load the SPA?

prmph 5y ago
Not much, if you use dynamic loading for heavy functionality that may not be used.
unfocussed_mike 5y ago
Not if the SPA subsequently takes over, (internally) routing links it recognises. (Nuxt does this)

trevex 5y ago

Isn’t this basically what NextJS and NuxtJS provide, if you only leverage their static rendering?

deleted 5y ago
[deleted]

hughrr 5y ago

The correct answer for this stuff, and it absolutely kills me saying this, is probably something like asp.net web forms.

manigandham 5y ago
Why does it kill you to say that? It’s the better and more productive option.
- hughrr 5y ago
  Because I abandoned it thinking it was terrible. Then I spent a decade finding out how bad everything else was.
mattmanser 5y ago
Asp.net web forms absolutely sucked. They fundamentally misunderstood HTML and how the internet even worked. Modern Razor's pretty good (not Razor Pages, they also suck) which is probably what you mean. But it's not that much different from Rails, Laravel, Django, etc.
- marcos100 5y ago
  By Modern Razor you mean Blazor components?
  - UltraViolence 5y ago
    Razor Pages.
- hughrr 5y ago
  Yes I mean the original version of it. I'd love to watch people attempt to implement some of the stuff I pulled off with that back in the day now. Occasionally, very complex data driven page flows are required and you could nail that entire problem domain trivially with them. There is a very large and well known company with a front-facing product used by millions of people which took 5 years pissing around with three different front end technologies to reimplement what we did in 3 months with that and it was slower and heavier and basically reimplemented web forms in python in the end. It broke the the www intentionally because it sucked. And it still does.

dlisboa 5y ago

I disagree with that. There's no real reason for each page to be a separate SPA, most likely only a small part of that page will be interactive, and most of it will be cacheable. Extracting only the interactive parts of a page into components is what I'm talking about. In some cases that'll be all of the page, but there are very few apps that meet that criteria.

prmph 5y ago
Of course if only a small part of your app is interactive, then SPAs don’t come into the picture in the first place. My point is that for very interactive web apps, this is a significantly better architecture that a huge monolithic SPA
LAC-Tech 5y ago
I mean in this model, if each page is an SPA, then the line between an SPA and an interactive page is very blurry.
tracker1 5y ago
Not only that but bundle splitting allows for extra areas of the application to be loaded at runtime on demand. All of that said, I'm not opposed to approaches like Next/Nuxt/Aleph.

SinParadise 5y ago

>app is composed of traditional pages with server navigation between them, but each page is implemented as an SPA. I agree with this because you affirm my bias. Also because I've also had success implementing this structure. This makes sure that state of each page doesn't leak everywhere, which simplifies the state management. It also loads faster than a big SPA because you don't have to worry about bundle splitting!

LAC-Tech 5y ago

I've had this thought experiment before, but where I get stuck is - what happens when you want to share state between the pages? URL params, storing to indexedDB, sticking them in global variables - all viable solutions but all with their own issues. I'd be very interested to hear how you solve this, or if it's less of an issue than people might think.

KwisaksHaderach 5y ago

JS frameworks with a small footprint are suitable for this.