> only to discover it doesn't include the fields you want anyway because it is assuming it should only be used for the specific table UI

It sounds like you're complaining that a server isn't shipping bits that it knows the client isn't going to use?

> wasting bandwidth for UI which could be defined once in JS and cached is annoying

How much smaller is the data encoded as JSON than the same data encoded as an HTML table? Particularly if compression is enabled?

ETA: And even more so, if the JSON has fields which the client is just throwing away anyway?

What seems wasteful to me is to have the server spend CPU cycles rendering data into JSON, only to have the front-end decode from JSON into internal JS representation, then back into HTML (which is then decoded back into an internal browser representation before being painted on the screen). Seems better to just render it into HTML on the server side, if you know what it's going to look like.

The main advantage of using JSON would be to allow non-HTML-based clients to use the same API endpoints. But with everyone using electron these days, that's less of an issue.

▲

coneonthefloor 12 hours ago | parent | next [-]

> What seems wasteful to me is to have the server spend CPU cycles rendering data into JSON, only to have the front-end decode from JSON into internal JS representation, then back into HTML (which is then decoded back into an internal browser representation before being painted on the screen). Seems better to just render it into HTML on the server side, if you know what it's going to look like.

Well put. I think the main issue is that we have a generation of "front end engineers" who have only ever worked with javascript apps. They have no experience of how easy it is to write html and send it via a server. The same html works now, worked 20 years ago, and will work 20 years from now.

▲

tdeck 11 hours ago | parent | next [-]

This is why many websites (even ones light on interactive functionality) now display a progress bar after loading the website. It's a big step backward for user experience and I even see it on blogs.

▲

javcasas 11 hours ago | parent | prev [-]

Your average veteran "front end engineer" has implemented las month half a dozen features that almost impossible to do server-side only, "just send the HTML, dude".

Progressive enhancement, forms with fields depending on other fields, real time updates, automated retries when the backend is down, advanced date selectors, maps with any kind of interactivity.

Any of the above is an order of magnitude harder to do backend-only vs backend API + any frontend.

▲

cenamus 11 hours ago | parent [-]

Who says you can't use any JS when doing server side rendering?

And why would you even want progressive enhancement if you can just send the proper full version right away, without waiting for MBs of JS to "hydrate" and "enhance" the page

	▲	javcasas 11 hours ago \| parent [-]
		You know, you went direct for the "bait" case, while ignoring all the others. Progressive enhancement is often done to mask the fact that fetching the data takes an unacceptable amount of time, otherwise no effort would be done to mask it. Your plan is to take that same unacceptable time, and add the server side render-to-html time on top of it, and that will improve it via...

▲

javcasas 12 hours ago | parent | prev [-]

> How much smaller is the data encoded as JSON than the same data encoded as an HTML table? Particularly if compression is enabled?

Well, as many things in life, it depends. If the cells are just text, there is no much difference. But, if the cells are components (for example, popover things or custom buttons that redirect to other parts of the site), the difference of not shipping all those components per cell and rendering them on the frontend starts to become noticeable.

▲

swiftcoder 11 hours ago | parent [-]

How lucky then that WebComponents exist, and we don't actually have to ship the whole DOM for each cell...

▲

javcasas 11 hours ago | parent [-]

So a backend-focused team that minimizes frontend is going to start fiddling with the DOM and shipping web components.

Sure, tell me more. I always enjoy a cool story.

	▲	swiftcoder 10 hours ago \| parent [-]
		Eh, I don't really think the frontend/backend distinction in webdev should exist. Your react components still get served from a backend too (even if they are static html).