yeah, the payload is almost zero difference, a round off error compared w/ connection latency

a lot of folks conflate AJAX w/ JSON apis, and can't easily imagine an endpoint returning partial bits of HTML that have nothing to do with a public JSON API

worse, people have been misled to believe that JSON APIs are REST-ful

we have a lot of work to do

> a lot of folks conflate AJAX w/ JSON apis

That matches by experience and is kind of ironic, considering that the X in "AJAX" once stood for XML. ;)

Because oftentimes you’re retrieving data that will be stored in one central store and displayed / used in different ways in various components. Eg I might fetch user data and sometimes display their name, maybe another time compute their age from their birthdate, etc...

If you take a few minutes to build seperate endpoints, you'd get better performance. Both in latency/bandwidth and in system resources for your DB query.

What's the difference between building seperate code paths on the client vs. 2 server endpoints though? Very few scenarios can't afford the behind-the-scenes extra http round trip...

Because I don't want to build and maintain an API endpoint to give me an HTML blob for the users age, and another one for their full name, and another one just for their first name, and another one for figuring out what day of the year is their birthday. I want adding these features to my UI to be a client-side-only change.

Probably fine in some use cases. But another reason on top of what's already been said: Because you might be sending the data back to a non-browser client such as a mobile application.

Maybe one could make a service worker to intercept and transform the JSON to HTML.

That is a really interesting place to stick what amounts to a template engine. Not saying it is right or wrong. Just very interesting.