Most of the reason I switched to static front-end are bad experiences with server-side UIs. Primarily, the bad performance of round-trips back to the server to re-render the UI. A browser-based front-end can switch pages immediately and remain responsive while data is loading.
In most of the apps I write, browser (or CDN) caching of whole pages is not desired as data changes are frequent and need to be reflected quickly. It would be impractical to invalidate CDN caches as data changed. Instead, the back-end database (or caching subsystem if necessary) handles caching of data. So repeated requests for the same data remain fast. The front-end assets are still browser/CDN cached, since they don't change as often.
In general, it makes for a good separation of concerns. When I did server-side UI, it was all too easy to mix UI and integration concerns, leading to more difficult maintenance in the long term. With good practices, you could avoid this mix of concerns on server-side UI. But it is less intuitive compared to when front/back are split.
A split front/back also allows two people/teams to work effectively in parallel, provided they agree on the data structures that pass between.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Most of the reason I switched to static front-end are bad experiences with server-side UIs. Primarily, the bad performance of round-trips back to the server to re-render the UI. A browser-based front-end can switch pages immediately and remain responsive while data is loading.
In most of the apps I write, browser (or CDN) caching of whole pages is not desired as data changes are frequent and need to be reflected quickly. It would be impractical to invalidate CDN caches as data changed. Instead, the back-end database (or caching subsystem if necessary) handles caching of data. So repeated requests for the same data remain fast. The front-end assets are still browser/CDN cached, since they don't change as often.
In general, it makes for a good separation of concerns. When I did server-side UI, it was all too easy to mix UI and integration concerns, leading to more difficult maintenance in the long term. With good practices, you could avoid this mix of concerns on server-side UI. But it is less intuitive compared to when front/back are split.
A split front/back also allows two people/teams to work effectively in parallel, provided they agree on the data structures that pass between.