The same API that serves data to the web browser can serve that data to mobile apps and to third parties as well.
The idea of bringing HTML rendering back on to the server just doesn't seem useful to me.
The same API that serves data to the web browser can serve that data to mobile apps and to third parties as well.
The idea of bringing HTML rendering back on to the server just doesn't seem useful to me.
One of the reasons why we have front end apps pulling
from an API is because it allows for interoperability.
The same API that serves data to the web browser can
serve that data to mobile apps and to third parties as well.
I agree with the benefit of API interoperability, but I'd call that orthogonal to server-side rendering. Your server-side web app could be just another consumer of that repurposable API. The idea of bringing HTML rendering back on to the server
just doesn't seem useful to me.
It's a streamlined developer workflow, for one. You have one renderer, not an infinite amount of client-side renderers. Easier one-stop-shopping debugging. And in reality, I feel that the promised performance gains of client-side rendering never truly materialized for many use cases.For projects involving small teams and non-trivial amounts, this is a boon. Any backend dev can, at least, write code to spit out some semantically correct HTML. Somebody is going to need to work on the UI/UX at some point but not necessarily full-time.
Contrast with a client-side rendering approach. If there is any significant amount of backend engineering behind the site (there isn't always, of course) now you have two apps with two divergent skillsets and more often than not, you need a minimum of two developers.