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.
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.
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.
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.
Is it? I’ve seen devs bring complicated code to the frontend when a required attribute on the tag would have done the job just as well. Preventing user mistakes is not the same as ensuring correct input.
We've all seen bad implementations of any given thing I'd imagine. Ever submit a form that triggers a full page refresh after about 8 seconds of hanging, only to lose half the data and reveal some arcane requirement to you that wasn't stated up front? Of course this isn't the proper way to do it, but it happens.
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.
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.
> 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
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.
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'm a bit confused at the ways HTMX and Alpine AJAX differ and where they're the same. I know there are header difference, for example, and that HTMX may have some functionality Alpine is missing, etc.
For example, HTMX has websocket support, while it looks like Alpine doesn't. Alpine has Alpine AJAX, but also alpine-morph, etc.
I only saw one article specifically addressing combining the two, but also very little on server side transitioning from one to the other.
I wish there was an article on starting with HTMX and what Ajax looks like in p
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.
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.
> I don't think having the server render the table HTML and you injecting it is a good idea.
HTMX, Alpine AJAX and other similar progressive web frameworks work exactly this way, as do server side rendered React.js and friends.
> What if the server has downtime, and returns a 200 response but with a "maintenance mode" page
If the server is in maintence mode, it should not display the web application/web page, but instead show a "We're in maintenance mode" messages.
> Having it render only on a successful response and correct parsing of JSON data is more reliable.
You're comparing making a simple web page with either no secondary calls or a single secondary call using a few lines of code to writing a client side web application. It's a bit like comparing a car with a bicycle.
> 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.
This is certainly an opinion and that works for you, but HTMX and similar actually make much of my life easier, rather than harder since all that styling, etc. can live alongside my server logic, rather than being in an entirely separate second application.
We should be opening a bug report on any server that returns status 200 Ok for what would be a proper 408 Request timeout or a 503 Service unavailable.
If this happens, it sounds like a syndrome of API first endpoints that return 200 with a json error field.
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.
It's not even 20 years ago, and literally nothing is stopping anyone from doing this now. All the tech is still there, and still works. Choose it. Be the change you want to see in the world. Hell you can even have the fancy version of it like Phoenix LiveViews.
I would if I was working on anything that was just a page of text and shitty flat forms like these examples always assume.
The last company I worked for it honestly took me about two months to actually grok what they were doing with their forms because I couldn't fathom why you'd do this input-listener business on the FE while the backend was all Django APIs. They had re-engineered a form wizard flow and scattered the state management into three places (some in the API calls, some in third party API calls in the middle of the flow, and a decent chunk in the React flow via cookies/sessions). It was madness trying to debug it.
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?
Every complaint about things like this can be fixed by the dev caring. There are cons to React, but they can all be mitigated. The ideal React app would behave like a plain HTML page, but with benefits to interactivity and development speed/maintenance.
The truth, though, is that most just don’t _care_ to prioritize this.
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.
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.
I’m not saying it’s better (it’s not). Just saying there’s a lot of space between “just HTML” and “a web framework”. It’s worth considering these other options instead of going “full React” from the get-go.
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!
> 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
> 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.
> 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.
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.
Your average veteran "front end engineer" has implemented las month half a dozen features that almost impossible to do server-side only, "just send the HTML, dude".
Progressive enhancement, forms with fields depending on other fields, real time updates, automated retries when the backend is down, advanced date selectors, maps with any kind of interactivity.
Any of the above is an order of magnitude harder to do backend-only vs backend API + any frontend.
Who says you can't use any JS when doing server side rendering?
And why would you even want progressive enhancement if you can just send the proper full version right away, without waiting for MBs of JS to "hydrate" and "enhance" the page
You know, you went direct for the "bait" case, while ignoring all the others.
Progressive enhancement is often done to mask the fact that fetching the data takes an unacceptable amount of time, otherwise no effort would be done to mask it.
Your plan is to take that same unacceptable time, and add the server side render-to-html time on top of it, and that will improve it via...
> 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.
Eh, I don't really think the frontend/backend distinction in webdev should exist. Your react components still get served from a backend too (even if they are static html).
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.
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
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.
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.
That's why GP mentioned the Accept header, the client can choose at runtime which one it wants.
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.
Web components work ok, and so does templated html. I was making reusable html components with Django templates in like, 2008.
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)
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.
* could have
If your going to be a pedant at least get the substitution right, it's "could've"
*you’re
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.
> Parts can be loaded via separate calls
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.
> it divides something that would be otherwise a monolith into subsequent small calls
This is often at odds with page responsiveness, and can increase server load considerably.
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.
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.
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.
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
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 have a human in the loop somewhere. This is how we do to not lose clients who accidentally typed @gmail.co
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]
You can use JS to provide validation and still submit the form from HTML.
That’s not validation. It’s more like helpful hints.
A pointless distinction when we all know what we're talking about.
Is it? I’ve seen devs bring complicated code to the frontend when a required attribute on the tag would have done the job just as well. Preventing user mistakes is not the same as ensuring correct input.
We've all seen bad implementations of any given thing I'd imagine. Ever submit a form that triggers a full page refresh after about 8 seconds of hanging, only to lose half the data and reveal some arcane requirement to you that wasn't stated up front? Of course this isn't the proper way to do it, but it happens.
What is the difference?
The same is true for any JS "validation" and I was using common terminology.
From a user point of view as long as you keep the feedback loop short what difference can they see?
Neither is it validation when you use JS if the server doesn't check it. You can always send requests with postman, curl or your tool of choice.
Helpful hints are all you can rely on from client-side. Client-side validation doesn't really exist, true validation only happens server-side.
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.
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?
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
I think re-rendering headers, menu and footers for CRUD applications on every page change is suboptimal for CRUD web apps.
An easy win is to replace just the page main content and keep headers, menu and footers between navigations in the system.
That's a very good idea, and exactly what HTMX (and similar implementations) do.
Rails and Laravel devs happily still live in this world a lot of the time :-)
Perl CGI FTW! :-D
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.
> 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
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.
Yes, the backend-for-frontend (BFF) architecture is an excellent fit for this purpose.
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.
yeah fashion is a bit barrier to doing things better … I am trying to be anti fashion with https://harcstack.org
Clean and nice. I'll probably try this.
awesome - come over to the Raku IRCchat or Discord (invites on https://raku.org) if you need any help
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'm in a similar boat of using HTMX and finding it's 85% there, but then being stuck with another 15% that's not fulfilled.
I'm looking at Alpine.js for that last 15%.
This is the way. https://alpine-ajax.js.org provides what’s missing from HTMX.
I'm a bit confused at the ways HTMX and Alpine AJAX differ and where they're the same. I know there are header difference, for example, and that HTMX may have some functionality Alpine is missing, etc.
For example, HTMX has websocket support, while it looks like Alpine doesn't. Alpine has Alpine AJAX, but also alpine-morph, etc.
I only saw one article specifically addressing combining the two, but also very little on server side transitioning from one to the other.
I wish there was an article on starting with HTMX and what Ajax looks like in p
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:
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:
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.
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.
Let's break this down a bit.
> I don't think having the server render the table HTML and you injecting it is a good idea.
HTMX, Alpine AJAX and other similar progressive web frameworks work exactly this way, as do server side rendered React.js and friends.
> What if the server has downtime, and returns a 200 response but with a "maintenance mode" page
If the server is in maintence mode, it should not display the web application/web page, but instead show a "We're in maintenance mode" messages.
> Having it render only on a successful response and correct parsing of JSON data is more reliable.
You're comparing making a simple web page with either no secondary calls or a single secondary call using a few lines of code to writing a client side web application. It's a bit like comparing a car with a bicycle.
> 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.
This is certainly an opinion and that works for you, but HTMX and similar actually make much of my life easier, rather than harder since all that styling, etc. can live alongside my server logic, rather than being in an entirely separate second application.
We should be opening a bug report on any server that returns status 200 Ok for what would be a proper 408 Request timeout or a 503 Service unavailable.
If this happens, it sounds like a syndrome of API first endpoints that return 200 with a json error field.
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.
It's not even 20 years ago, and literally nothing is stopping anyone from doing this now. All the tech is still there, and still works. Choose it. Be the change you want to see in the world. Hell you can even have the fancy version of it like Phoenix LiveViews.
I would if I was working on anything that was just a page of text and shitty flat forms like these examples always assume.
The last company I worked for it honestly took me about two months to actually grok what they were doing with their forms because I couldn't fathom why you'd do this input-listener business on the FE while the backend was all Django APIs. They had re-engineered a form wizard flow and scattered the state management into three places (some in the API calls, some in third party API calls in the middle of the flow, and a decent chunk in the React flow via cookies/sessions). It was madness trying to debug it.
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?
Every complaint about things like this can be fixed by the dev caring. There are cons to React, but they can all be mitigated. The ideal React app would behave like a plain HTML page, but with benefits to interactivity and development speed/maintenance.
The truth, though, is that most just don’t _care_ to prioritize this.
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.
Isn't this server-side rendering?
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?
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.
> Every time I see this stuff it is a form with two fields
Yup. No-one is suggesting using React for a login form with 0 interactivity
"why do we even need forklifts?! people can pick their laptops up with their hands!" ok thanks
Well, nowadays, you can implement a lot of logic for forms using HTML and pure CSS, without JS at all. Example:
I’m not saying it’s better (it’s not). Just saying there’s a lot of space between “just HTML” and “a web framework”. It’s worth considering these other options instead of going “full React” from the get-go.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!
> 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
> 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.
> 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.
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.
Your average veteran "front end engineer" has implemented las month half a dozen features that almost impossible to do server-side only, "just send the HTML, dude".
Progressive enhancement, forms with fields depending on other fields, real time updates, automated retries when the backend is down, advanced date selectors, maps with any kind of interactivity.
Any of the above is an order of magnitude harder to do backend-only vs backend API + any frontend.
Who says you can't use any JS when doing server side rendering?
And why would you even want progressive enhancement if you can just send the proper full version right away, without waiting for MBs of JS to "hydrate" and "enhance" the page
You know, you went direct for the "bait" case, while ignoring all the others.
Progressive enhancement is often done to mask the fact that fetching the data takes an unacceptable amount of time, otherwise no effort would be done to mask it.
Your plan is to take that same unacceptable time, and add the server side render-to-html time on top of it, and that will improve it via...
> 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.
How lucky then that WebComponents exist, and we don't actually have to ship the whole DOM for each cell...
So a backend-focused team that minimizes frontend is going to start fiddling with the DOM and shipping web components.
Sure, tell me more. I always enjoy a cool story.
Eh, I don't really think the frontend/backend distinction in webdev should exist. Your react components still get served from a backend too (even if they are static html).
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.
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
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.
relevant: Remove mentions of XSLT from the html spec - https://news.ycombinator.com/item?id=44952185 - Aug, 2025 (545 comments)
[dead]
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]