4 ms·

In my decades of experience building web applications, I have found it exceedingly rare for components to benefit from SPA-style state management. These framewo

In my decades of experience building web applications, I have found it exceedingly rare for components to benefit from SPA-style state management. These frameworks build layers of abstractions to replace functionality that exists in the browser. For example, web forms should never require the level of complexity that frameworks like React steer developers towards: downloading JS components, listening to events to build a local state, crafting an AJAX request, rendering the return JSON as HTML. It almost seems as though there is an entire generation of frontend developers who never learned that there are way simpler alternatives that perform just as well in the real world. htmx might not end up being a SPA-killer, but progressive enhancement has always been a worthy contender.

davedx 2y ago
I don't know about the kind of web apps you've been building, but most of the ones I've built over the last 10-15 years have had too much interactivity to be done with simpler server side rendering.
- evantbyrne 2y ago
  Everything from MPAs, to SPAs, to animation heavy websites that could only dream on being tailwind. Progressive enhancement doesn't mean giving up on frontend validation, dynamic functionality, and juice. I'm curious what problems you haven't been able to solve without converting whole applications to JSX.
  - mplewis 2y ago
    Just because problems are possible to solve in a hybrid approach doesn’t make the hybrid approach the ideal solution for complicated UI.
    - evantbyrne 2y ago
      My idea of a complicated UI challenge is not updating DOM in two trees. I have found React to be inadequate for the hardest UI challenges that I've been presented with. Things like DOM manipulation for interactive animations should not be handled by React state updates.
- endemic 2y ago
  That's the exact opposite of my experience. Completely boring biz software that was, in essence, collections of forms. Didn't need the additional development burden of an extra JavaScript codebase, but that's what's in vogue, so ¯\_(ツ)_/¯
  - LudwigNagasena 2y ago
    If so, it probably didn't need any development burden and could be done using a no-code or low-code solution.
    - skydhash 2y ago
      No|Low code solutions often generates hard to maintain code so you essentially find yourself locked to the platform and version you started with.
    - mitjam 2y ago
      Most low code/no code solutions bring back memories of Access and Excel based solutions.
- pseudosavant 2y ago
  I think the SPA and the no-JS SSR people get it wrong by making it so black and white. By choosing to use something like React, you've made everything only SPA. With SSR, you can at least choose to progressively enhance the interactions. Look at amazon.com. They have plenty of full page reloads, yet their site also has tons of interactivity. Just make sure that the thing you require a full page reload for happens at a natural transition where it isn't interrupting the user's experience.
nsonha 2y ago
I notice you started by a blanket statment and use a strawman that is forms in React, a framework known for being the worst for forms (if you don't know the right library). Overall a poor criticism of SPA as a whole.
- evantbyrne 2y ago
  Having an opinion on best framework and libraries does not make what I'm saying straw man. React is by far the most popular framework for building SPAs and from what I've seen everyone uses a similar-enough state pattern to what has been described. I would love to hear your recommendations though.
troyvit 2y ago
To me the part that rubs the worst, is that _after_ downloading JS components, listening to events to build a local state, crafting the AJAX request, and rendering the return JSON as HTML, the SPA will then change the URL in the URL bar so that users can (hopefully) bookmark the monstrosity. This is after 75% of the page has been re-rendered anyway. And just to echo your point, there's an entire generation of frontend developers who think this is normal.
- nsonha 2y ago
  It's more like the other way around. Veteran web devs are stockholm-syndromed into thinking the web should always work how it used to work, they tend to think about the web as some sort of sacred internet document. Most devs these days view it as just another medium for apps, and if you look at the web from the app developer point of view, this is completely normal. Is it broken in many ways, absolutely? But not because it's not now the web used to work, as it was also broken/insufficient for modern needs. There is an entire other discussion about how to keep the web as "information superhighway" (as opposed to an app medium) and accessible. I am sympathetic to that cause, but I think we should create new web standards for that. As it stands, the html/css/js trio is doing too many things and sucks at all of them.
graypegg 2y ago
> abstractions to replace functionality that exists in the browser. I was just having the conversation yesterday. We were talking about how React Query/Tanstack Query is a bit of a rats nest under the hood. We're looking into ways of taking it out to simplify things a bit, especially since we aren't using a ton of the library's features, nor will ever have a need for them. Found myself saying "I wish the native fetch() had a built in cache layer... oh yeah". The "standard browser" is pretty much the most expansive standard library that exists.

davedx 2y ago

I don't know about the kind of web apps you've been building, but most of the ones I've built over the last 10-15 years have had too much interactivity to be done with simpler server side rendering.

evantbyrne 2y ago
Everything from MPAs, to SPAs, to animation heavy websites that could only dream on being tailwind. Progressive enhancement doesn't mean giving up on frontend validation, dynamic functionality, and juice. I'm curious what problems you haven't been able to solve without converting whole applications to JSX.
- mplewis 2y ago
  Just because problems are possible to solve in a hybrid approach doesn’t make the hybrid approach the ideal solution for complicated UI.
  - evantbyrne 2y ago
    My idea of a complicated UI challenge is not updating DOM in two trees. I have found React to be inadequate for the hardest UI challenges that I've been presented with. Things like DOM manipulation for interactive animations should not be handled by React state updates.
endemic 2y ago
That's the exact opposite of my experience. Completely boring biz software that was, in essence, collections of forms. Didn't need the additional development burden of an extra JavaScript codebase, but that's what's in vogue, so ¯\_(ツ)_/¯
- LudwigNagasena 2y ago
  If so, it probably didn't need any development burden and could be done using a no-code or low-code solution.
  - skydhash 2y ago
    No|Low code solutions often generates hard to maintain code so you essentially find yourself locked to the platform and version you started with.
  - mitjam 2y ago
    Most low code/no code solutions bring back memories of Access and Excel based solutions.
pseudosavant 2y ago
I think the SPA and the no-JS SSR people get it wrong by making it so black and white. By choosing to use something like React, you've made everything only SPA. With SSR, you can at least choose to progressively enhance the interactions. Look at amazon.com. They have plenty of full page reloads, yet their site also has tons of interactivity. Just make sure that the thing you require a full page reload for happens at a natural transition where it isn't interrupting the user's experience.

nsonha 2y ago

I notice you started by a blanket statment and use a strawman that is forms in React, a framework known for being the worst for forms (if you don't know the right library). Overall a poor criticism of SPA as a whole.

evantbyrne 2y ago
Having an opinion on best framework and libraries does not make what I'm saying straw man. React is by far the most popular framework for building SPAs and from what I've seen everyone uses a similar-enough state pattern to what has been described. I would love to hear your recommendations though.

troyvit 2y ago

To me the part that rubs the worst, is that _after_ downloading JS components, listening to events to build a local state, crafting the AJAX request, and rendering the return JSON as HTML, the SPA will then change the URL in the URL bar so that users can (hopefully) bookmark the monstrosity. This is after 75% of the page has been re-rendered anyway. And just to echo your point, there's an entire generation of frontend developers who think this is normal.

nsonha 2y ago
It's more like the other way around. Veteran web devs are stockholm-syndromed into thinking the web should always work how it used to work, they tend to think about the web as some sort of sacred internet document. Most devs these days view it as just another medium for apps, and if you look at the web from the app developer point of view, this is completely normal. Is it broken in many ways, absolutely? But not because it's not now the web used to work, as it was also broken/insufficient for modern needs. There is an entire other discussion about how to keep the web as "information superhighway" (as opposed to an app medium) and accessible. I am sympathetic to that cause, but I think we should create new web standards for that. As it stands, the html/css/js trio is doing too many things and sucks at all of them.

graypegg 2y ago

> abstractions to replace functionality that exists in the browser. I was just having the conversation yesterday. We were talking about how React Query/Tanstack Query is a bit of a rats nest under the hood. We're looking into ways of taking it out to simplify things a bit, especially since we aren't using a ton of the library's features, nor will ever have a need for them. Found myself saying "I wish the native fetch() had a built in cache layer... oh yeah". The "standard browser" is pretty much the most expansive standard library that exists.