6 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!
- lsalvatore 5y ago
  There is no "pain" managing large React / Redux applications for experienced frontend software engineers. If you don't want to write JavaScript, you probably shouldn't be building interactive applications for the web. The Browser manages HTML, CSS and JavaScript and provides Developer Tools to debug and manage these languages. When you build with a javascript framework, you package a user experience that is entirely run by the browser, only to dispatch and save to the server when necessary. I doubt there is a future for "backend SPA" frameworks- no one will take seriously the idea of, instead of two REST calls to get and put data, every client must connect through a socket to manage user input. Surely that will dramatically increase server bandwidth, and ignite the same type of "bloat" arguments that SPA critics use.
  - resignThis2021 5y ago
    I agree with you. My only, personal, issue with front-end is typescript - I don't enjoy it for some reason.
  - ramchip 5y ago
    > Surely that will dramatically increase server bandwidth LiveView can actually decrease B/W and load, because the HTML diffs are more efficient than sending JSON, and the statefulness means you don't need to constantly refetch user information from DB/cache, etc. The details depend on your app and how carefully you optimize it, but it's far from being an unconditional "dramatic increase". > If you don't want to write JavaScript, you probably shouldn't be building interactive applications for the web. That's gatekeeping and just plain insulting.
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!

lsalvatore 5y ago
There is no "pain" managing large React / Redux applications for experienced frontend software engineers. If you don't want to write JavaScript, you probably shouldn't be building interactive applications for the web. The Browser manages HTML, CSS and JavaScript and provides Developer Tools to debug and manage these languages. When you build with a javascript framework, you package a user experience that is entirely run by the browser, only to dispatch and save to the server when necessary. I doubt there is a future for "backend SPA" frameworks- no one will take seriously the idea of, instead of two REST calls to get and put data, every client must connect through a socket to manage user input. Surely that will dramatically increase server bandwidth, and ignite the same type of "bloat" arguments that SPA critics use.
- resignThis2021 5y ago
  I agree with you. My only, personal, issue with front-end is typescript - I don't enjoy it for some reason.
- ramchip 5y ago
  > Surely that will dramatically increase server bandwidth LiveView can actually decrease B/W and load, because the HTML diffs are more efficient than sending JSON, and the statefulness means you don't need to constantly refetch user information from DB/cache, etc. The details depend on your app and how carefully you optimize it, but it's far from being an unconditional "dramatic increase". > If you don't want to write JavaScript, you probably shouldn't be building interactive applications for the web. That's gatekeeping and just plain insulting.

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.