Comment by prmph
4 years 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
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.
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
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.
I mean in this model, if each page is an SPA, then the line between an SPA and an interactive page is very blurry.
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.
>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!
Isn’t this basically what NextJS and NuxtJS provide, if you only leverage their static rendering?
The correct answer for this stuff, and it absolutely kills me saying this, is probably something like asp.net web forms.
Yeah, as much pain as it has caused me in the past I think the crucial realization Microsoft made with Webforms and maybe Blazor is that the stateless model of web is fairly crap if you are doing anything beyond displaying static text.
For its time it was some cool tech.
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.
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.
1 reply →
What’s wrong with razor pages? They’re fantastically simple and productive.
And WebForms wasn't a misunderstanding. It was a deliberate and brilliant design that brought WinForm developers and their experience to the web and allowed them to build complex web apps two decades ago that still work to this day.
5 replies →
By Modern Razor you mean Blazor components?
1 reply →
Please, go learn about Remix (https://remix.run), it is the actual correct answer for this stuff.
I don't understand why they choose an example -- a simple user dashboard -- that could be easily implemented as a traditional MPA. It seems like Remix is mainly for the "I learned to program with SPAs" audience.
1 reply →
Why does it kill you to say that? It’s the better and more productive option.
Because I abandoned it thinking it was terrible. Then I spent a decade finding out how bad everything else was.
JS frameworks with a small footprint are suitable for this.
Do you lose performance because each page has to load the SPA?
Not if the SPA subsequently takes over, (internally) routing links it recognises. (Nuxt does this)
Not much, if you use dynamic loading for heavy functionality that may not be used.