| ▲ | mmcromp 11 hours ago |
| 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 |
|
| ▲ | RUnconcerned 11 hours ago | parent | next [-] |
| 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. |
| |
| ▲ | zffr 10 hours ago | parent | next [-] | | 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. | | |
| ▲ | Izkata 10 hours ago | parent [-] | | That's why GP mentioned the Accept header, the client can choose at runtime which one it wants. |
| |
| ▲ | cenamus 11 hours ago | parent | prev | next [-] | | 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. | |
| ▲ | jonkoops 11 hours ago | parent | prev [-] | | 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. |
|
|
| ▲ | zdragnar 10 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | debo_ 9 hours ago | parent | next [-] | | Web components work ok, and so does templated html. I was making reusable html components with Django templates in like, 2008. | |
| ▲ | em-bee 10 hours ago | parent | prev | next [-] | | 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. | | | |
| ▲ | librasteve 10 hours ago | parent | prev [-] | | 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) |
|
|
| ▲ | loloquwowndueo 11 hours ago | parent | prev [-] |
| * could have |
| |
| ▲ | webstrand 10 hours ago | parent [-] | | If your going to be a pedant at least get the substitution right, it's "could've" | | |
|
