7 ms·

The problem is the mixing and matching of state management. In a traditional web app all of the state is in the back end, in a SPA all of the state is in the fr

The problem is the mixing and matching of state management. In a traditional web app all of the state is in the back end, in a SPA all of the state is in the front end. When we share state in between the two it's often messy. To me the answer feels like it should be "traditional web app for most things, components-as-first-intended for some things". The simplest React example is just one component that abstracts presentation and logic. The only state is its own. It does not handle an entire web app as a SPA, no Redux, prop drilling, it's just the idea of a reusable component as an HTML tag. Same with VueJS and all. If we restrict ourselves to that we're in the good path. If there was already an HTML tag for your own specific problem, wouldn't you just use it in your traditional server-rendered app? A `<photo-upload url="/photos">` tag that does exactly what you want. Or a `<wizard pages=5 logic="com.domain">` tag. We should create just those components, either in React/VueJS/Whatever or in vanilla JS Web Components, and live with the rest as we used to. We're basically saying that some parts of our apps are too difficult to mix and match state management, and we should offload all of the state to one of the two sides. In some rare apps indeed all of the state should be on the front end, but the use cases for that are just not as big as they're made out to be.

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.
deleted 5y ago
[deleted]
ithrow 5y ago
Agree, we just add React components here and there to server-side rendered HTML and it works great for us. The issue is most companies want separate teams for front-end and back-end and each team wants clear separation of boundaries and responsibilities between them.
- beebeepka 5y ago
  Adding components here and there sounds like a simple app. Nothing wrong with that, if course. Different teams exist for a reason. I've deeply regretted working in "we have real Devs that can do it all" environments. It's not so much about boundaries as it is about competence. Or lack of it with
- dzhiurgis 5y ago
  The old mythical man month strikes back. Best devops is no ops. Best team is no team. Of course eventually you need more people and I don't love anyone touch my code, but I'd rather have someone incompetent do entire stack that at least I can review than spend weeks upon weeks communicating basic assumptions.
khimaros 5y ago
this seems to be approximately what https://htmx.org/ https://htmx.org/ is trying to accomplish.
- dlisboa 5y ago
  HTMX goes about it in the wrong way, in my opinion. HTML code should not carry state and logic. The moment you need something a bit more complicated than the common examples you’re in HTML-attribute soup trying to use a real programming language. It’s better to just write that as a component in React or Svelte or whatever. It’s more testable, easier to understand, can carry state and logic just fine. It does mean you have to communicate in JSON for a small part of your app, but that is reserved to a few well known endpoints and components like a complex form. The penalty is loading React or some other lib just for that, but if used in this way the extra dependency isn’t really a big deal as it’s not your whole app. Just use React as a library for components the browser doesn’t already provide. And by components here I should really clarify as “affordances”. A “primary” button isn’t an affordance, the browser already gives you a button element and CSS classes (or HTML attribute) for that. It doesn’t give you a “multi page wizard with immediate validation” affordance, however, so that’s a good candidate for a component.
  - recursivedoubts 5y ago
    the original network model of the web was REST[1] a core aspect of REST was HATEOAS, which stands for Hypermedia As The Engine of Application State[2] htmx goes about it in the same way as the original web perhaps that is wrong, but the web was pretty successful overall [1] - https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... [2] - https://htmx.org/essays/hateoas/ https://htmx.org/essays/hateoas/
    - dlisboa 5y ago
      HATEOAS is great, but that's not my issue with HTMX. It's coding interactivity via HTML attributes that I have an issue with. It just never works. It overcomplicates things and there's an actual programming language right there in JavaScript to solve this. When it goes past the simplest examples it gets ugly real quick. Here's an example of client-side validation via HTMX: https://htmx.org/docs/#validation https://htmx.org/docs/#validation. That can't be the future.
jkcxn 5y ago
Yes this is exactly right. What I’ve done in the past is use Django to return HTML with JSX mixed in, and have a super lightweight SPA frontend that just hydrates the react components on each load. You can also use form state to communicate back and forth with the server, where sending a response doesn’t refresh the entire page, just a react render diff. With this you get the best of both worlds where your backend can do the heavy lifting where everything it needs to decide on the view is all in one place, and your frontend just comprises of really really generic JS components. I have a library I’ve been playing around with for 2 years now, I should package it up
- CRConrad 5y ago
  > I have a library I’ve been playing around with for 2 years now, I should package it up Please do.
Pensacola 5y ago
> The problem is the mixing and matching of state management. This. But IMHO the right solution is to make the back-end stateless and manage all client state on the client. Each request authenticates itself, and (if you're ReSTful about it) the back-end is simply a database connector/augmenter. In this paradigm, the SPA is basically a desktop app that retrieves data from a server, built to run within a framework, which happens to be a web browser. In case you're jumping to conclusions, know that I'm a late-comer to the SPA party, having resisted from its inception until about a year ago, for all the obvious reasons, including those bemoaned by the OP. Why did I relent? SPA frameworks like React now handle pretty much all the heavy lifting for you. OP, you should check out React Router, which can render this post's examples irrelevant. I'm surprised that in 2022, someone writing to the web UI layer would bother to create code to manage the address bar when there are a thousand ways to not have to.
- unclebucknasty 5y ago
  How well does React Router solve these problems if you're not using React fully?
- catlifeonmars 5y ago
  A lot of the arguments against SPAs in TFA center on broken U/X. This is only incidentally related to SPA architecture, and has much more to do with the current SPA ecosystem. IMO it’s more just a lack of standardization and the broken U/X is just an emergent property of the vacuum. MPAs are great because the technology is old and navigation between pages has first class support in all browsers, not because of some intrinsic advantage of the way application state is managed.
unclebucknasty 5y ago
>The problem is the mixing and matching of state management Routing (history management) is also a big problem (I'm assuming you weren't including that in your definition of "state" here). Some would say, "but React, etc. have solved the routing issues", and that's perhaps the case. But what's difficult is wiring these routers up outside of a full React app. That is, if you truly want routing "solved", you generally have to go all React (or whatever) or just let the browser handle it in the traditional request/response sense. Sprinkling in just a bit of dynamic interaction wherein you want the history managed is purgatory. And, on mobile, things get even more interesting. Consider the simple case of popping a modal (especially a slide-out). Many users will hit "back" on a mobile device, which they would reasonably expect to simply close the modal. But, if your app/page doesn't intercede to manage the history, the previous page is loaded instead.
- fendy3002 5y ago
  Routing (along with hash path and query string) IMO is definitely a part of state. Different route lead to different content, thus different state. The problem is which source of truth we want to use. I find that I'll need to refer to routes as the source of truth to process information, meaning "almost" every react action become route-manipulation action and it's state is just derived from the route, which is very similar with what MPA already do.
  - unclebucknasty 5y ago
    Yeah, I think history is definitely a form of state, but didn't seem like the state the parent to my comment had in mind. And, I do think they're distinct problems (but related) when you're just adding a bit of interactivity to a page or two, as this sub-thread is discussing. In a full SPA, it's largely coupled and more inline with what you say: let the route drive the action. But, sometimes you have an MPA with a dynamic stateful feature embedded at a particular URL, but which may or may not need a sub-route of its own. In those cases, weird stuff can happen if the history is not managed correctly.
dzhiurgis 5y ago
Any non-trivial app will require some frontend state eventually.

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.

deleted 5y ago

[deleted]

ithrow 5y ago

Agree, we just add React components here and there to server-side rendered HTML and it works great for us. The issue is most companies want separate teams for front-end and back-end and each team wants clear separation of boundaries and responsibilities between them.

beebeepka 5y ago
Adding components here and there sounds like a simple app. Nothing wrong with that, if course. Different teams exist for a reason. I've deeply regretted working in "we have real Devs that can do it all" environments. It's not so much about boundaries as it is about competence. Or lack of it with
dzhiurgis 5y ago
The old mythical man month strikes back. Best devops is no ops. Best team is no team. Of course eventually you need more people and I don't love anyone touch my code, but I'd rather have someone incompetent do entire stack that at least I can review than spend weeks upon weeks communicating basic assumptions.

khimaros 5y ago

this seems to be approximately what https://htmx.org/ https://htmx.org/ is trying to accomplish.

dlisboa 5y ago
HTMX goes about it in the wrong way, in my opinion. HTML code should not carry state and logic. The moment you need something a bit more complicated than the common examples you’re in HTML-attribute soup trying to use a real programming language. It’s better to just write that as a component in React or Svelte or whatever. It’s more testable, easier to understand, can carry state and logic just fine. It does mean you have to communicate in JSON for a small part of your app, but that is reserved to a few well known endpoints and components like a complex form. The penalty is loading React or some other lib just for that, but if used in this way the extra dependency isn’t really a big deal as it’s not your whole app. Just use React as a library for components the browser doesn’t already provide. And by components here I should really clarify as “affordances”. A “primary” button isn’t an affordance, the browser already gives you a button element and CSS classes (or HTML attribute) for that. It doesn’t give you a “multi page wizard with immediate validation” affordance, however, so that’s a good candidate for a component.
- recursivedoubts 5y ago
  the original network model of the web was REST[1] a core aspect of REST was HATEOAS, which stands for Hypermedia As The Engine of Application State[2] htmx goes about it in the same way as the original web perhaps that is wrong, but the web was pretty successful overall [1] - https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... [2] - https://htmx.org/essays/hateoas/ https://htmx.org/essays/hateoas/
  - dlisboa 5y ago
    HATEOAS is great, but that's not my issue with HTMX. It's coding interactivity via HTML attributes that I have an issue with. It just never works. It overcomplicates things and there's an actual programming language right there in JavaScript to solve this. When it goes past the simplest examples it gets ugly real quick. Here's an example of client-side validation via HTMX: https://htmx.org/docs/#validation https://htmx.org/docs/#validation. That can't be the future.

jkcxn 5y ago

Yes this is exactly right. What I’ve done in the past is use Django to return HTML with JSX mixed in, and have a super lightweight SPA frontend that just hydrates the react components on each load. You can also use form state to communicate back and forth with the server, where sending a response doesn’t refresh the entire page, just a react render diff. With this you get the best of both worlds where your backend can do the heavy lifting where everything it needs to decide on the view is all in one place, and your frontend just comprises of really really generic JS components. I have a library I’ve been playing around with for 2 years now, I should package it up

CRConrad 5y ago
> I have a library I’ve been playing around with for 2 years now, I should package it up Please do.

Pensacola 5y ago

> The problem is the mixing and matching of state management. This. But IMHO the right solution is to make the back-end stateless and manage all client state on the client. Each request authenticates itself, and (if you're ReSTful about it) the back-end is simply a database connector/augmenter. In this paradigm, the SPA is basically a desktop app that retrieves data from a server, built to run within a framework, which happens to be a web browser. In case you're jumping to conclusions, know that I'm a late-comer to the SPA party, having resisted from its inception until about a year ago, for all the obvious reasons, including those bemoaned by the OP. Why did I relent? SPA frameworks like React now handle pretty much all the heavy lifting for you. OP, you should check out React Router, which can render this post's examples irrelevant. I'm surprised that in 2022, someone writing to the web UI layer would bother to create code to manage the address bar when there are a thousand ways to not have to.

unclebucknasty 5y ago
How well does React Router solve these problems if you're not using React fully?
catlifeonmars 5y ago
A lot of the arguments against SPAs in TFA center on broken U/X. This is only incidentally related to SPA architecture, and has much more to do with the current SPA ecosystem. IMO it’s more just a lack of standardization and the broken U/X is just an emergent property of the vacuum. MPAs are great because the technology is old and navigation between pages has first class support in all browsers, not because of some intrinsic advantage of the way application state is managed.

unclebucknasty 5y ago

>The problem is the mixing and matching of state management Routing (history management) is also a big problem (I'm assuming you weren't including that in your definition of "state" here). Some would say, "but React, etc. have solved the routing issues", and that's perhaps the case. But what's difficult is wiring these routers up outside of a full React app. That is, if you truly want routing "solved", you generally have to go all React (or whatever) or just let the browser handle it in the traditional request/response sense. Sprinkling in just a bit of dynamic interaction wherein you want the history managed is purgatory. And, on mobile, things get even more interesting. Consider the simple case of popping a modal (especially a slide-out). Many users will hit "back" on a mobile device, which they would reasonably expect to simply close the modal. But, if your app/page doesn't intercede to manage the history, the previous page is loaded instead.

fendy3002 5y ago
Routing (along with hash path and query string) IMO is definitely a part of state. Different route lead to different content, thus different state. The problem is which source of truth we want to use. I find that I'll need to refer to routes as the source of truth to process information, meaning "almost" every react action become route-manipulation action and it's state is just derived from the route, which is very similar with what MPA already do.
- unclebucknasty 5y ago
  Yeah, I think history is definitely a form of state, but didn't seem like the state the parent to my comment had in mind. And, I do think they're distinct problems (but related) when you're just adding a bit of interactivity to a page or two, as this sub-thread is discussing. In a full SPA, it's largely coupled and more inline with what you say: let the route drive the action. But, sometimes you have an MPA with a dynamic stateful feature embedded at a particular URL, but which may or may not need a sub-route of its own. In those cases, weird stuff can happen if the history is not managed correctly.

dzhiurgis 5y ago

Any non-trivial app will require some frontend state eventually.