This isn't scalable for any kind environment with multiple services and teams. Can you imagine "actually the table display will be handled by the User service BE, we'll just inject it". The reason why people reach for react and js for simple projects is because that's what theyre familiar with at work (that or they're training in hopes of work), even when theoretically they could of used something way more stripped down
There's nothing stopping an HTTP API from returning both HTML and JSON from the same endpoint. Just have the client send "text/html" or "application/json" in the Accept header, depending on what it needs.
One challenge is that JSON is for data and HTML is for UI. When a client gets JSON it can transform the data to make it ready for the UI. With HTML, the client is locked into the UI chosen by the server.
What if the client wants to render the output of an API in different ways depending on what screen is visible? If the server API outputs JSON, this is trivial. If it outputs HTML the client is stuck into rendering what the server gives it.
That's why GP mentioned the Accept header, the client can choose at runtime which one it wants.
However it would make sense to have a separate json api for other applications. That way the html endpoints can change without without api versioning, perfectly matching whatever the gui needs.
There absolutely is, this is just extra cruft you need to maintain, and who says that the HTML is universal enough to be used everywhere? This is exactly where a front-end or a backend-for-frontend (BFF) makes sense.
It's not scalable to a small team either. The amount of copy/paste of markup I had to clean up on a site that didn't actually contribute to style, presentation or information was insane. Just divs and divs of tailwind classes all overriding each other or having no effect copy pasted everywhere.
Far better to have a tool that lets you define small, reusable, composable building blocks and let your team just use those.
Web components work ok, and so does templated html. I was making reusable html components with Django templates in like, 2008.
exactly, even for a single person maintaining just a few pages with a bit of style and navigation is already a chore. i'd rather use a js framework or even xslt than edit the menu on every page, every time i need to add a new page.
With jinja you’d use template inheritance and just update the base template for this:
https://jinja.palletsprojects.com/en/stable/templates/#templ...
sure, that's just one of the many frameworks or tools i could use. the point is, there is no way to do that without any processing, either on the server or in the browser.
just to mention you CAN do this with HTMX using a server side library… there are many, personally I like https://harcstack.org (because i wrote it)
* could have
If your going to be a pedant at least get the substitution right, it's "could've"
*you’re