14 ms·

I can't relate to this at all. I've been happily working on SPAs with React and Redux for nearly 6 years. Hotwire makes no sense: switching to managing client-

I can't relate to this at all. I've been happily working on SPAs with React and Redux for nearly 6 years. Hotwire makes no sense: switching to managing client-side state on the server and sending HTML over the wire introduces a ton of problems: you are going to have to write and debug JavaScript eventually. Now your server is running client-side code to update every local browser state? How is that scalable at all? React has a ton of great libraries for UI that these articles always ignore: Something like react-select to manage a dynamic dropdown- you can't implement that on the server. You need SPAs for complex dashboards, and React is a great library to store and update local state. I don't understand what the controversy is.

sanderjd 5y ago
I've always thought some of it stems from the nomenclature and the cultures that flow from it. A lot of people (reasonably) don't think the best architecture for their application is a "single page". But many of those same people nonetheless have (often large) portions of their application that benefit from complex client side interactivity. But the whole thing can seem really all or nothing, either you have a "single page application" that does everything client side or you do everything through html from the server. Of course in practice everybody does some hybrid in between these two extremes. But the apparent split creates a cultural battle between the extremes, which is not helpful.
- lsalvatore 5y ago
  I come from a financial reporting background where pages needed to be dynamic and update through filters / sorting / etc- think Excel or Robinhood- these are applications, not pages. When you are building an application, users don't want to experience a page refresh. You either want a dynamic behavior without page refresh, or not. React Router gives you client-side routing- I don't know why you wouldn't want that even if you were building something like AirBnB where there is mostly static content- to argue against dynamic search and filtering without page refresh seems silly to me.
  - sanderjd 5y ago
    Yep exactly this. I even just used Coinbase Pro vs. Vanguard in another thread as a concrete example of application vs. website where the Vanguard approach would really suck for an actual trading application.
yurishimo 5y ago
Meh, I think you can get 98% of the way there. Look at the explosion of these "server side SPA" frameworks popping up. Hotwire for Rails, Livewire for Laravel, LiveView for Phoenix, etc etc. I think Elixir is a super interesting case given how insanely fast it is. If your request to fetch new data and patch the DOM takes 5ms, who cares if it's slower than React? It's plenty fast for a ton of use cases and lowers complexity. And then, if you do need the super slick interactive element, you bust out React and code up a nice little inline thing that writes it's value to a hidden input field that you can send along with a the submission of a normal form. Webdev swung heavy to building entirely frontend solutions and I think the past year or so has been the potential beginning of the pendulum swinging back as teams are now feeling the pains of maintaining these huge frontend applications, on top of already needing to maintain the complexity of their backend. Time will tell!
- thebean11 5y ago
  > If your request to fetch new data and patch the DOM takes 5ms Even in the US people are still dealing with pretty bad internet in a lot of places. Even with the best internet, and assuming it takes 0ms to handle the request, 5ms sounds insanely optimistic. I'm in a big city and my ping (to my ISP's datacenters in the same city) is 10-20ms...
  - ericb 5y ago
    So, latency is certainly one locus of optimization. Another locus of optimization might be development speed and cost. An SPA is really two apps, a front-end, and a back end. It costs 2x to do an SPA, and all things being equal, features come out 1/2 as fast. Which wins the app with latency, or the app that gets features twice as fast?
    - thebean11 5y ago
      It doesn't cost 2x. Yes you go from two apps to one, but that one app is more complex than either of the original two.
ithrow 5y ago
No need to go full SPA, dynamic dropdown can just be a component(with react-select) in your MPA. You create coupling between your front-end server and the browser but that's not bad at all for many type of webapps.

sanderjd 5y ago

I've always thought some of it stems from the nomenclature and the cultures that flow from it. A lot of people (reasonably) don't think the best architecture for their application is a "single page". But many of those same people nonetheless have (often large) portions of their application that benefit from complex client side interactivity. But the whole thing can seem really all or nothing, either you have a "single page application" that does everything client side or you do everything through html from the server. Of course in practice everybody does some hybrid in between these two extremes. But the apparent split creates a cultural battle between the extremes, which is not helpful.

lsalvatore 5y ago
I come from a financial reporting background where pages needed to be dynamic and update through filters / sorting / etc- think Excel or Robinhood- these are applications, not pages. When you are building an application, users don't want to experience a page refresh. You either want a dynamic behavior without page refresh, or not. React Router gives you client-side routing- I don't know why you wouldn't want that even if you were building something like AirBnB where there is mostly static content- to argue against dynamic search and filtering without page refresh seems silly to me.
- sanderjd 5y ago
  Yep exactly this. I even just used Coinbase Pro vs. Vanguard in another thread as a concrete example of application vs. website where the Vanguard approach would really suck for an actual trading application.

yurishimo 5y ago

Meh, I think you can get 98% of the way there. Look at the explosion of these "server side SPA" frameworks popping up. Hotwire for Rails, Livewire for Laravel, LiveView for Phoenix, etc etc. I think Elixir is a super interesting case given how insanely fast it is. If your request to fetch new data and patch the DOM takes 5ms, who cares if it's slower than React? It's plenty fast for a ton of use cases and lowers complexity. And then, if you do need the super slick interactive element, you bust out React and code up a nice little inline thing that writes it's value to a hidden input field that you can send along with a the submission of a normal form. Webdev swung heavy to building entirely frontend solutions and I think the past year or so has been the potential beginning of the pendulum swinging back as teams are now feeling the pains of maintaining these huge frontend applications, on top of already needing to maintain the complexity of their backend. Time will tell!

thebean11 5y ago
> If your request to fetch new data and patch the DOM takes 5ms Even in the US people are still dealing with pretty bad internet in a lot of places. Even with the best internet, and assuming it takes 0ms to handle the request, 5ms sounds insanely optimistic. I'm in a big city and my ping (to my ISP's datacenters in the same city) is 10-20ms...
- ericb 5y ago
  So, latency is certainly one locus of optimization. Another locus of optimization might be development speed and cost. An SPA is really two apps, a front-end, and a back end. It costs 2x to do an SPA, and all things being equal, features come out 1/2 as fast. Which wins the app with latency, or the app that gets features twice as fast?
  - thebean11 5y ago
    It doesn't cost 2x. Yes you go from two apps to one, but that one app is more complex than either of the original two.

ithrow 5y ago

No need to go full SPA, dynamic dropdown can just be a component(with react-select) in your MPA. You create coupling between your front-end server and the browser but that's not bad at all for many type of webapps.