Just Use HTML
30 comments
·September 16, 2025renegat0x0
gwd
> 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.
niux
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.
dreadnip
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.
Tade0
> 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.
graemep
You can use JS to provide validation and still submit the form from HTML.
norman784
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.
leftyspook
I think a part of the point is to question the need for things like that. Do your users actually need all of these bells and whistles?
null
sam0x17
or maybe we could do this revolutionary thing where we use code on the server side to generate different HTML for different requests!!!
we've come full circle <3
brianmcc
Perl CGI FTW! :-D
mmcromp
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
loloquwowndueo
* could have
NikxDa
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.
epolanski
> 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.
1. User experience > developer experience
2. Any API that communicates with some consumer exposes data under some kind of view, unless you're expecting your clients fetching portfolios to fetch users and then their portfolios and then the security names attached to the ids in those portfolios, etc, etc
> 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.
Let's assume you have a `Array<SomeDataType>` view, and this view maps to a string as a JSON. You can as easily have a second mapping function that returns the table.
> 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.
The web and its ecosystem moved a lot since 10 years ago.
I often have to maintain 6/7 year old projects with gulp, React 12 and very old redux-saga patterns, I'd rather maintain PHP applications using Twig any day.
In any case: I don't disagree with you per se. I just think there's different scenarios and use cases.
swiftcoder
> 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
devnull3
I am backend dev and dipping my toes in frontend dev for my side hustle.
It is a typical CRUD app (like most of them). I like the idea behind HTMX or datastar. I built a prototype in it as well. But then I pivoted to solidjs.
Some reasons for this:
1. Single backend API for web, mobile and any other platform
2. Some UI patterns which are suited for JSON REST APIs [#patterns]
3. Ability to support partial functionality offline.
#patterns
1. Showing a subset of columns in a table but have an option to view & edit each record in detail. In my case a dialog opens with editable checkbox. So it doubles-up as "view" and "edit". These actions render just another view of existing data. A round-trip to server is not desirable IMO.
2. Filtering, sorting on columns. HTML based solution becomes tedious if some of the cells are not plain text but instead a complex component like a <div>. Sorting json and rendering is much better experience IMO.
Edit: About solidjs & datastar
1. It has fine-grained reactivity which I find it appealing and it uses signals which hopefully will be standardized.
2. The compiled bundle size is much smaller than I expected. I have 24KB compressed js which is serves quite a lot of views, pages.
3. Datastar is amazing and I have added it in my toolbox.
urbandw311er
For anybody over the age of about 35, this entire article is utterly baffling because it's just extremely obvious things that we already know because this is how the Internet used to be about 20 years ago. Reading this just makes me feel very old.
saulhenrick
Isn't this server-side rendering?
indentit
> Another area where you can lean a lot more heavily on HTML is API responses
Please no - it is so much nicer and easier when using a website with poor UI/filtering capabilities/whatever, to look at the network requests tab from devtools in the browser and get json output which you can work with however you want locally versus getting html and having to remove the presentation fluff from it 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... Plus these days internet while out and about isn't necessarily fast, and wasting bandwidth for UI which could be defined once in JS and cached is annoying
gwd
> 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
> 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
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
> 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
How lucky then that WebComponents exist, and we don't actually have to ship the whole DOM for each cell...
tdeck
As someone else who does this, I think we're a pretty small audience. People shouldn't be building web apps with our reverse engineering experience in mind.
remark5396
> Another area where you can lean a lot more heavily on HTML is API responses
Then you just gotta write the same HTML generating code on the server, isn't it? It looks like just the difference of the code being on frontend or backend, then I'd prefer it to be on the frontend side.
null
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