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.

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

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

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

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.

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.

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.

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.

Isn't this server-side rendering?

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?

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.

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?

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 mean, IF the API is primarily tailored for UI presentation, there's already a text/html that you can use. I don't see the real problem here. Unless it's a type of API that has multiple purposes. In which case you got to tailor the response/presentation based on the needs.

Either way, the time needed to build a HTML elements will be eventually spent somewhere, on the server or on the client side. Server provides you with the data, you pick the form in which it is sent, and then work around the presentation layer.

I'm helping up the team behind https://voiden.md so I can tell you, it's easy to present the HTML even in the API clients, let alone the website itself.

> 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

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.

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

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?

[dead]