3 ms·
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 (py
by 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 agoTurbo 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.