Just Use HTML

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

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

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.

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.

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

  if (request.headers["user-agent"].Matches("Safari")) {
     // wheeeee
  else if (...Matches("Firefox")) {
     // those where good times

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.

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.

I don't think having the server render the table HTML and you injecting it is a good idea. You rely on the server returning valid HTML. What if the server has downtime, and returns a 200 response but with a "maintenance mode" page, or something similar? Having it render only on a successful response and correct parsing of JSON data is more reliable. You also start complicating things in terms of separation of concerns. You potentially have to adapt any styling considerations in your API, for instance if the table needs a class adding to it. Overall, not a good idea, imho.

The first point is about using an onSubmit event that is triggered by an onClick of a button. Why? Just add type="submit" to the button and the onSubmit event will be triggered by a click or by hitting the enter key. I'm confused as I feel like this is so simple that I must be missing somethng?

These 'just use HTML' shitposts really miss the mark. Every time I see this stuff it is a form with two fields, come on. Realistically, a lot of applications are forms, but they are much more complex. E.g. fields that can be added and removed, conditional logic depending on selected state, and most importantly a non-flat data structure.

Once you start bolting on all this stuff to HTML, congratulations, you have built a web framework.

I am not advocating that everyone should start using React. But HTML forms are severely underpowered, and you cannot escape JavaScript at some point. I would love it if forms could consume and POST JSON data, that would make this all a lot easier in a declarative manner.

  form:has(.conditional-checkbox:not(:checked)) .optional-part-of-form {
    display: none;
  }

I find this advice overly simplistic to the point of being completely misguided.

Let's take the table example. Sure, you can fetch an HTML snippet and insert it directly in the DOM tree with innerHTML. But then, how do you handle:

  1. Formatting based on client-side preferences (e.g., formatting dates based on the client's time zone)
  2. Changing the sort order (e.g., by clicking a column header)
  3. Filtering rows (e.g., by typing in a search box)

These are all super common features of tables, especially larger ones, and all of this functionality is way easier to implement client-side than server-side.

And yes, if you really want you can make the server generate custom tables by passing query parameters of the form: ?sort=price&tz=Europe/Berlin&query=foo, but that has several downsides:

  1. You're now sending potentially privacy-sensitive information to the server.
  2. You have to make a roundtrip for every change in any of the parameters, which is slow and wastes bandwidth and server resources.
  3. Arguably the worst: your presentation logic is now spread between the frontend and backend, instead of being concentrated in the frontend, where it belongs.

For these reasons, it's much preferable to have the server return just the data (often in JSON format) and let the client sort, filter and format it.

I can think of two rebuttals. One: what about the simple case, though? Isn't client-side formatting overkill in that case? Yes, it is, but people use it anyway, because it's generic: it works well for simple and complex cases alike. It's easier to learn a small set of well-understood general solutions than a large set of niche solutions.

Two: what about performance? node.innerHTML = 'bla' is faster, isn't it? Yes, it probably is, but for small-to-medium-sized tables the difference won't be noticeable, and tables that are so large that the time it takes to render them begins to matter, it's probably a better idea to reduce the size of the rendered page anyway, e.g. by introducing pagination. So even if we don't need any fancy features, cases where the "fast" solution is clearly beneficial are rare.

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.

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.

nit: the pure HTML example is not the same as the other examples. It would make a POST request to the server with the data using a form encoding instead of a JSON encoding. It's not a given that your server supports this encoding!

I'm not a fan of React (and not use it at work), but imagine that you have multiple login forms, either to same service or to different ones. With React (or any similar JSX framework) you can embed such form component in your application = it will behave the same way in any place you put it in (or can be customised dependent on the parameters). Then it can also be tested that it behaves in a certain way and conforms to business rules.

How would I do the same with plain HTML?

Isn't this server-side rendering?

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.

> 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

> 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.

A feature of ES6 I really like are custom HTML components: https://lindseymysse.com/blog/2025/04/23/custom-html-element...

For a lot of internal and personal projects I use a combination of custom HTML elements with XSLT: https://lindseymysse.com/x-s-l-t/

Still requires Javascript, but makes writing HTML a lot more fun.

Nice idea - but 10K lines of css and 1M lines of js offer me far more social cred, pay, and job security than some stupid little html stuff that just works.

/s?