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.
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.
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.
I performed some transition from django pure template solution to more javascript oriented.
- my server was running on raspberry PI, now heavy responses are returned via JSON, I think REST-like data. Which makes me offload burden to clients
- javascript makes the page more responsive. Parts can be loaded via separate calls, and it divides something that would be otherwise a monolith into subsequent small calls
- In my experience nearly all simple binary decisions "use only X", and "use only Y" solutions are bad
> Parts can be loaded via separate calls, and it divides something that would be otherwise a monolith into subsequent small calls
He's not saying don't use Javascript; he's saying that instead of having those small calls shipping JSON which is then converted into HTML, just have those small calls ship HTML to begin with.
It's surprising how far you can get with something like HTMX.
Just makes me think of my bank's site, which shows a few seconds of "loading" animations on each section of the page. Maybe if the main content loaded quickly and ancillary content was lazy-loaded it would feel faster.
This article is an oversimplification describing basic forms, but as soon as you try to implement any sort of advanced validation using just HTML, the whole paradigm falls apart. Browsers support JavaScript for a reason.
How can you ever trust validation on the client side though? The user can just mess with it and submit anything they want anyway.
Why not validate on the server and return a response or error as HTML?
I’m not trying to argue in bad faith here. I know client side validation is necessary in some cases, but IMO it’s only an augmentation for UX purposes on top of server side validation.
> Why not validate on the server and return a response or error as HTML?
If your form has files you'd want to at least check it before sending data unnecessarily to the server.
Also it's always better to have a tighter feedback loop. That is really the main reason why there's validation on the frontend and backend, not just the latter.
Typically for fetch() I return the error as "text/plain" with the appropriate status code. It is still necessary to give a preflight validation in Vanilla JS, apply an error style and helpful feedback.
HTML has come a long way since the bad old days. General constraints can be applied directly to the input element. It still makes sense add additional explanations for the invalid input with JS though.
Client-side validation is a progressive enhancement. You always have server-side validation. The validation in the browser exists to provide additional feedback that lets users have realtime feedback about their input.
Just use a generic data structure for your validation rules that you can apply on the front-end, and validate on the back-end. Using JavaScript and doing validation on a server are not mutually exclusive.
You're answering yourself here: client side feedback/validation is essential ux for any complex form. Even for simple signup forms with a few required fields.
You can have a minimal library like HTMX or if you have access to a solution Phoenix LiveView, you need minimal JS to have an interactive page, the only downside is that you could introduce some latency because of the network trip.
There's a lot of validation that can be done with HTML; I'd even say most client-side validation can be handled by HTML/the browser. You can specify input types, do RegExp matching, etc. There's a lot in the spec.
Okay, but, like, how much worse is it to re-render the whole thing? And it's not like Turbo hasn't been around for more than a decade, doing exactly that, for free, automatically.
The suggestion to have the server return the table directly starts bringing presentational concerns into the backend, which I am not a big fan of.
Having the server return plain JSON means the APIs can be reused across products effortlessly and also means that all style changes can be done in the same codebase.
I get reminded of how important this is every time I get to work on an old project that has APIs return HTML that is then being inserted into the DOM by something like jQuery. Figuring it out and updating it is typically a huge mess.
If you control the full stack like in the article, you could have a server backend server the JSON, and another backend taking that and serving HTML, if you wanted.
Edit: This could still be way simpler than the "hydration" approach which is so popular.
> Having the server return plain JSON means the APIs can be reused across products effortlessly and also means that all style changes can be done in the same codebase.
How many products actually share the same server backend?
Do they all organise the same data on the same pages? If no, then you already need per-product APIs to avoid making O(N) fetches from the client side
Having your backend be aware of what is being presented is rarely a bad thing
I often do, just use HTML, when working on a completely solo project. If anyone else is going to touch the project, I find they can't do HTML - they do not know it, and on top they have a brainwashing that makes them unable to work in HTML. It's really amazing, they will literally stand behind social pressures as why they cannot. Then the users and the finished project: if it does not look like it was made using React, those same social pressures prevent them from using the project. They will use fashion arguments why they cannot. Seriously.
I’ve done a couple of side gigs doing exactly that. I’m not really proficient in React, but I still had to do web development. For one project I used jQuery, and for the latest one I tried htmx — but it wasn’t quite enough, so I had to mix in some vanilla JS as well. Arguably, that’s not really a best-practice recommendation when working in a team, and I’d only consider it justifiable for smaller projects. Still, I got paid, so it worked out.
I avoid JS whenever I can. Those who advocate for JS typically do it because they're drawing a large salary from it.
Server-side rendering of HTML is really fast if an efficient compiled language is used. If you are using Node/PHP/Python/Ruby on the server, you will feel the pain. Server rendered HTML is also scraper friendly because the scraper then doesn't need to use a virtual browser.
Readit News
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.
Far better to have a tool that lets you define small, reusable, composable building blocks and let your team just use those.
- my server was running on raspberry PI, now heavy responses are returned via JSON, I think REST-like data. Which makes me offload burden to clients
- javascript makes the page more responsive. Parts can be loaded via separate calls, and it divides something that would be otherwise a monolith into subsequent small calls
- In my experience nearly all simple binary decisions "use only X", and "use only Y" solutions are bad
He's not saying don't use Javascript; he's saying that instead of having those small calls shipping JSON which is then converted into HTML, just have those small calls ship HTML to begin with.
It's surprising how far you can get with something like HTMX.
Just makes me think of my bank's site, which shows a few seconds of "loading" animations on each section of the page. Maybe if the main content loaded quickly and ancillary content was lazy-loaded it would feel faster.
Deleted Comment
This is often at odds with page responsiveness, and can increase server load considerably.
Why not validate on the server and return a response or error as HTML?
I’m not trying to argue in bad faith here. I know client side validation is necessary in some cases, but IMO it’s only an augmentation for UX purposes on top of server side validation.
If your form has files you'd want to at least check it before sending data unnecessarily to the server.
Also it's always better to have a tighter feedback loop. That is really the main reason why there's validation on the frontend and backend, not just the latter.
HTML has come a long way since the bad old days. General constraints can be applied directly to the input element. It still makes sense add additional explanations for the invalid input with JS though.
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
It's also essential in order to not make forms to difficult to fill in, because that means you lose customers and a lot of money.
Dead Comment
You'll need server-side validation anyway…
Deleted Comment
we've come full circle <3
An easy win is to replace just the page main content and keep headers, menu and footers between navigations in the system.
Having the server return plain JSON means the APIs can be reused across products effortlessly and also means that all style changes can be done in the same codebase.
I get reminded of how important this is every time I get to work on an old project that has APIs return HTML that is then being inserted into the DOM by something like jQuery. Figuring it out and updating it is typically a huge mess.
Deleted Comment
Edit: This could still be way simpler than the "hydration" approach which is so popular.
How many products actually share the same server backend? Do they all organise the same data on the same pages? If no, then you already need per-product APIs to avoid making O(N) fetches from the client side Having your backend be aware of what is being presented is rarely a bad thing
I'm looking at Alpine.js for that last 15%.
Server-side rendering of HTML is really fast if an efficient compiled language is used. If you are using Node/PHP/Python/Ruby on the server, you will feel the pain. Server rendered HTML is also scraper friendly because the scraper then doesn't need to use a virtual browser.