4 ms·

It is. And it's very much domain dependant. One of my projects is a CRM application, which is a SPA. Years ago, I had a similar incarnation of that projects as

by harel 2y ago

It is. And it's very much domain dependant. One of my projects is a CRM application, which is a SPA. Years ago, I had a similar incarnation of that projects as a "traditional" html+js model. It works much much better as an SPA on many levels. It's a complex app with a lot of UI elements. A simpler application might not benefit from being an SPA. So it all depends. I'm just allergic to that style of "X is dead to me so X must be dead to you".

evantbyrne 2y ago
That's interesting because a CRM sounds like a strong use case for server-rendered HTML: Relatively low interactivity outside of form handling, which is consistently a weak point for SPAs. I wonder how different your experience would have been back then if you had modern browser APIs and something like Turbo, because the manner in which you go about the JS makes a huge difference. I would not advocate that people use HTMX for example, which strikes me as just being inline JS.
- harel 2y ago
  An SPA is actually very suitable for this type of app. It was simple forms in the 00s, but it's not that anymore. First, in my case, the back end is an API (python). It is also serving mobile apps, and 3rd party integrations. Turbo is more suitable, if I'm not mistaken, for Javascript based applications. Second, my CRM is fast. The UI is snappy and there is little lag, which is something people comment on a lot. And third, there are many components there where a page reload will break things - for example, when you perform a telephone call from the browser. You can still navigate the data, without reloading the page and cutting the call. It's never simple, and NEVER EVER one size fits all. I'm saying this after about 30 years of doing this job commercially.
  - evantbyrne 2y ago
    Turbo is just a front-end library it doesn't matter what your backend stack is. You can do all of that with a MPA approach, including partial DOM updates, with just the JSON API for your mobile apps being the missing part simply due to not needing it for the browser implementation. Serializing JSON on the backend and transforming it into HTML via React should always be slower than just sending the same HTML over the wire. I'll have to benchmark Pocket SQL to get frontend numbers, but it is perceptibly instant with requests taking single-digit ms, so it's not like the server-rendering part of it is slow. I'm glad the SPA approach worked out back then! The point I'm making is that MPAs are worth another try with modern tooling.

by harel 2y ago

evantbyrne 2y ago

That's interesting because a CRM sounds like a strong use case for server-rendered HTML: Relatively low interactivity outside of form handling, which is consistently a weak point for SPAs. I wonder how different your experience would have been back then if you had modern browser APIs and something like Turbo, because the manner in which you go about the JS makes a huge difference. I would not advocate that people use HTMX for example, which strikes me as just being inline JS.

harel 2y ago
An SPA is actually very suitable for this type of app. It was simple forms in the 00s, but it's not that anymore. First, in my case, the back end is an API (python). It is also serving mobile apps, and 3rd party integrations. Turbo is more suitable, if I'm not mistaken, for Javascript based applications. Second, my CRM is fast. The UI is snappy and there is little lag, which is something people comment on a lot. And third, there are many components there where a page reload will break things - for example, when you perform a telephone call from the browser. You can still navigate the data, without reloading the page and cutting the call. It's never simple, and NEVER EVER one size fits all. I'm saying this after about 30 years of doing this job commercially.
- evantbyrne 2y ago
  Turbo is just a front-end library it doesn't matter what your backend stack is. You can do all of that with a MPA approach, including partial DOM updates, with just the JSON API for your mobile apps being the missing part simply due to not needing it for the browser implementation. Serializing JSON on the backend and transforming it into HTML via React should always be slower than just sending the same HTML over the wire. I'll have to benchmark Pocket SQL to get frontend numbers, but it is perceptibly instant with requests taking single-digit ms, so it's not like the server-rendering part of it is slow. I'm glad the SPA approach worked out back then! The point I'm making is that MPAs are worth another try with modern tooling.