3 ms·

Maybe I'm missing something, the article isn't very clear. One of the reasons why we have front end apps pulling from an API is because it allows for interopera

Maybe I'm missing something, the article isn't very clear. 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. The idea of bringing HTML rendering back on to the server just doesn't seem useful to me.

Karrot_Kream 6y ago
That's if you're making an application, sure, but on the web I view all sorts of sites and most of them are just styled text containers, maybe with an optional way to mutate things. HN, Reddit, News, recipes, forums, galleries, these are things I regularly consume that don't need APIs to return content. For applications, like Facebook, it's understandable, but if you don't spend all of your time in Social Media, then you probably are not really using an application.
- dndvr 6y ago
  You must use old.reddit.com
  - Karrot_Kream 6y ago
    On mobile I just use a client that requests data from the API and renders it for me. On desktop, yes, for now, but I'm in the process of writing views that load faster and don't require a browser.
bdcravens 6y ago
You're correct, but for many companies, APIs and multiple interoperable clients are a YAGNI.
pgm8705 6y ago
Having both is still an option with minimal effort. In Rails it can be as simple as adding .json to your request and you get the data, otherwise the HTML.
JohnBooty 6y ago
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.
deadbunny 6y ago
Maybe I'm being dumb (I'm a sysadmin, not a developer) but wouldn't you just shift those API calls to the server rendering the page rather than the browser?
- astura 6y ago
  Yes
pmlnr 6y ago
You mean the locked down apis that are not available to the puclic? Those can rot in hell.

Karrot_Kream 6y ago

That's if you're making an application, sure, but on the web I view all sorts of sites and most of them are just styled text containers, maybe with an optional way to mutate things. HN, Reddit, News, recipes, forums, galleries, these are things I regularly consume that don't need APIs to return content. For applications, like Facebook, it's understandable, but if you don't spend all of your time in Social Media, then you probably are not really using an application.

dndvr 6y ago
You must use old.reddit.com
- Karrot_Kream 6y ago
  On mobile I just use a client that requests data from the API and renders it for me. On desktop, yes, for now, but I'm in the process of writing views that load faster and don't require a browser.

bdcravens 6y ago

You're correct, but for many companies, APIs and multiple interoperable clients are a YAGNI.

pgm8705 6y ago

Having both is still an option with minimal effort. In Rails it can be as simple as adding .json to your request and you get the data, otherwise the HTML.

JohnBooty 6y ago

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.

deadbunny 6y ago

Maybe I'm being dumb (I'm a sysadmin, not a developer) but wouldn't you just shift those API calls to the server rendering the page rather than the browser?

astura 6y ago
Yes

pmlnr 6y ago

You mean the locked down apis that are not available to the puclic? Those can rot in hell.