Htmx: Simplicity in an Age of Complicated Solutions(erikheemskerk.nl)
erikheemskerk.nl
Htmx: Simplicity in an Age of Complicated Solutions
https://www.erikheemskerk.nl/htmx-simplicity/
7 comments
SPA is Single Page Application.
htmx is capable of SPA as well. What we must remember is that htmx is a javascript library. Its just htmx provides an extension to html attributes.
This does not mean we cannot add Javascript to solve problems... its just htmx eliminates the need of writing hundreds (or thousands) of javascript code to get things done.
I do not claim htmx to be the one-and-only solution to building web applications but it has DRASTICALLY cut many hours away from adding new features (and bug fixes) to our relatively complicated company portal.
We no longer have to write backend AND frontend code. Previously our website were using frontend libraries. Why? Because we are told this is how your are SUPPOSE to make them, now. However, when you are a small team without dedicated frontend developers (ie React devs, etc) you have to allows extra time to replicate/duplicate code on the frontend as well.
Yes, there have been trial-and-error issues with htmx where we had to stop and think how we would solve certain things. For the most part, it is accepting the "htmx way" of doing it and are now comftable with it. Its not perfect but we make it work well.
Point is - very little is done on the client side. It is easy to see whats going on, and which Views or Partial Views to amend, etc, on the serverside. I would even argue that if we hired a "front end" developer they would fit into our environment relatively easy, knowing where the HTML code is, how to test it, alongside CSS styling and, if needed, to write additional javascript. The only ones that wont are dedicated JS framework guys who refuse to see or understand our decision process. This is fine, of course. If they do not like our methods then they can reject the 2nd Interview process.
I want to repeat - I do not claim htmx solves all website issues. Its just the websites I am involved with, htmx has been a great choice moving forward, and they are a combination of simple to complicated websites.
htmx is capable of SPA as well. What we must remember is that htmx is a javascript library. Its just htmx provides an extension to html attributes.
This does not mean we cannot add Javascript to solve problems... its just htmx eliminates the need of writing hundreds (or thousands) of javascript code to get things done.
I do not claim htmx to be the one-and-only solution to building web applications but it has DRASTICALLY cut many hours away from adding new features (and bug fixes) to our relatively complicated company portal.
We no longer have to write backend AND frontend code. Previously our website were using frontend libraries. Why? Because we are told this is how your are SUPPOSE to make them, now. However, when you are a small team without dedicated frontend developers (ie React devs, etc) you have to allows extra time to replicate/duplicate code on the frontend as well.
Yes, there have been trial-and-error issues with htmx where we had to stop and think how we would solve certain things. For the most part, it is accepting the "htmx way" of doing it and are now comftable with it. Its not perfect but we make it work well.
Point is - very little is done on the client side. It is easy to see whats going on, and which Views or Partial Views to amend, etc, on the serverside. I would even argue that if we hired a "front end" developer they would fit into our environment relatively easy, knowing where the HTML code is, how to test it, alongside CSS styling and, if needed, to write additional javascript. The only ones that wont are dedicated JS framework guys who refuse to see or understand our decision process. This is fine, of course. If they do not like our methods then they can reject the 2nd Interview process.
I want to repeat - I do not claim htmx solves all website issues. Its just the websites I am involved with, htmx has been a great choice moving forward, and they are a combination of simple to complicated websites.
IMO the industry vastly overestimates what a typical SPA can do.
More accurately: the industry vastly overestimates the requirement for SPA and the typical app vastly under-utilises its capabilities.
I recently had developers blink slowly and ask me to repeat the statement that an ordinary ASP.NET Razor web forms app could be used for a site that had a single form on it (with about a dozen text fields only).
"But... how... can it submit? Doesn't it need an API?"
I recently had developers blink slowly and ask me to repeat the statement that an ordinary ASP.NET Razor web forms app could be used for a site that had a single form on it (with about a dozen text fields only).
"But... how... can it submit? Doesn't it need an API?"
Can you elaborate for those who do not know what a Razor web form is and how it can persist things without an API?
Instead of sending json to an api, form submission does a post back to the form page which detects this and reads the contents of form to do work on it. HTML pages can have code associated with them to do this in a cshtml file (C# specific). Lots of older frameworks support this, PHP being a popular example. Razor replaced ASP.Net webforms which has also been around forever.
See https://learn.microsoft.com/en-us/aspnet/web-pages/overview/...
See https://learn.microsoft.com/en-us/aspnet/web-pages/overview/...
Which is a good summary, but in this specific circumstance the confusion of the developers wasn't about Razor pages, but the very concept of a "HTML" page having any interactivity of any kind without JavaScript and an API endpoint.
There is a very substantial fraction of developers who have never done anything else, and are completely unaware that such thing is even possible.
There is a very substantial fraction of developers who have never done anything else, and are completely unaware that such thing is even possible.
Ah postback. I probably missed the point of this thread then as I am not considering that to be an SPA. Or is this about it not being an SPA?
It’s a recognition that the extreme majority of websites don’t benefit from being a spa.
> The HTMX hype vastly underestimates what a good SPA can do.
I don't think there is such thing as an HTMX hype outside HN. There is definitely a SPA hype outside HN though. A shame, since a large number of applications would benefit from being a MPA.
I don't think there is such thing as an HTMX hype outside HN. There is definitely a SPA hype outside HN though. A shame, since a large number of applications would benefit from being a MPA.
Companies have full-stack expectations, so we need full-stack tooling.
Junior front-end engineers are already feeling threatened by low-code-llm-agents. LLMs have strong aesthetic sensibilities and the functional nature of modern front-end frameworks means that LLMs can get good at them, really fast.
HTMX allows junior engineers to develop as front end and backend engineers at the same time. So if one profession is threatened, they still have a backup.
We've entered the Honda civic / Toyota Camry era of visual design for standard websites and apps. The UI isn't a selling point as it once used to be. If anything, customers prefer familiarity. (Frontier tech like ML and VR are obvious exclusions)
Most front end problems are civics and camrys. Yes, LLMs won't be able to build the ferrari equivalent of front ends, but they're going to be fully capable of doing CRUD competently.
Too many engineers were trained to build the next Google or Facebook through the 2010s. In reality, calling them a tiny minority would still be an exxageration. Most engineers at google and Facebook don't build Google or Facebook, let alone those working at normal companies at normal scale with normal customers.
Junior front-end engineers are already feeling threatened by low-code-llm-agents. LLMs have strong aesthetic sensibilities and the functional nature of modern front-end frameworks means that LLMs can get good at them, really fast.
HTMX allows junior engineers to develop as front end and backend engineers at the same time. So if one profession is threatened, they still have a backup.
We've entered the Honda civic / Toyota Camry era of visual design for standard websites and apps. The UI isn't a selling point as it once used to be. If anything, customers prefer familiarity. (Frontier tech like ML and VR are obvious exclusions)
Most front end problems are civics and camrys. Yes, LLMs won't be able to build the ferrari equivalent of front ends, but they're going to be fully capable of doing CRUD competently.
Too many engineers were trained to build the next Google or Facebook through the 2010s. In reality, calling them a tiny minority would still be an exxageration. Most engineers at google and Facebook don't build Google or Facebook, let alone those working at normal companies at normal scale with normal customers.
The world vastly over estimate what needs to be a SPA.
I've used HTMX in a lot of applications but i always end up using web components or a javascript as the app grows.
The fact that's relatively lightweight makes me feel okay using it though. If you'd like a similar lightweight library you can try alpinejs.
Adds reactive stores with just a javascript link.
The fact that's relatively lightweight makes me feel okay using it though. If you'd like a similar lightweight library you can try alpinejs.
Adds reactive stores with just a javascript link.
I had a similar experience, so I took the stuff I liked from HTMX and made it into an Alpine plugin: https://alpine-ajax.js.org
> Instead, HTMX re-allocates most responsibilities from the front end to the backend.
Before we had SPAs that part of the “backend” was actually called the front-end. You had business logic, and output models in the form of json, views if substitutions and logic by itself, etc.
Before we had SPAs that part of the “backend” was actually called the front-end. You had business logic, and output models in the form of json, views if substitutions and logic by itself, etc.
> vastly underestimates what a good SPA can do
Such as?
Such as?
HTMX veering into SPA territory will produce the same kind of code we got when jQuery did it. The apps would work but they would be wholly unmaintainable. HTMX evangelists will just say "See? It CAN do it.", completely disregarding the ergonomics as if they're irrelevant in software development.
HTMX beautifully captures the zone between static and SPA, but devs already seem to want to use the hammer for everything, because all SPAs are suddenly not true SPAs. Well it was similar with jQuery too. The apps were considered to not be complex enough for a different tech stack, but eventually many apps grew more complex in their requirements and there is no sane way to move from jQuery to Angular and those projects got left in the dust.
HTMX beautifully captures the zone between static and SPA, but devs already seem to want to use the hammer for everything, because all SPAs are suddenly not true SPAs. Well it was similar with jQuery too. The apps were considered to not be complex enough for a different tech stack, but eventually many apps grew more complex in their requirements and there is no sane way to move from jQuery to Angular and those projects got left in the dust.
> but eventually many apps grew more complex
But the counter argument is also valid; if your app did not grow complex, then you paid an upfront price for that expected growth but didn't reap the rewards.
But the counter argument is also valid; if your app did not grow complex, then you paid an upfront price for that expected growth but didn't reap the rewards.
Much simpler backends for example. htmx is cool, but it seems simple because it's simply pushing the complexity elsewhere.
I don't think it is for people who refuse to learn another entire ecosystem for a project. Although smaller in size, HTMX needs to be learned as well. And although it is advertised as being simple, I certainly had a few struggles with it where I needed to spent some time figuring things out.
I would also oppose the frequently made proposition that HTMX is for people who hate Javascript. I certainly do not love Javascript, but I do not go out of my way to avoid it. My apps always have some vanilla Javascript sprinkled in where it fits.
To refer to the article: people really need to stop searching for that "silver bullet" and just use the tooling they are comfortable with.
I really have to say I'm annoyed by parties on both sides of the isle who either refuse anything but SPAs and React or others who see HTMX as the holy grail. The tooling on both sides (e.g. either React or HTMX) is being overhyped a lot. Once your app grows to a certain size or complexity you will struggle with either for some time until you "figure stuff out". No tool will ever alleviate the struggle in its entirety.
I would also oppose the frequently made proposition that HTMX is for people who hate Javascript. I certainly do not love Javascript, but I do not go out of my way to avoid it. My apps always have some vanilla Javascript sprinkled in where it fits.
To refer to the article: people really need to stop searching for that "silver bullet" and just use the tooling they are comfortable with.
I really have to say I'm annoyed by parties on both sides of the isle who either refuse anything but SPAs and React or others who see HTMX as the holy grail. The tooling on both sides (e.g. either React or HTMX) is being overhyped a lot. Once your app grows to a certain size or complexity you will struggle with either for some time until you "figure stuff out". No tool will ever alleviate the struggle in its entirety.
I really loved the ideas of HTMX but when I finally used it in a project, it was still overly complicated for my needs and yet in some areas underfeatured. Vanilla Websockets + insertAdjacentHTML works pretty well for me.
maybe i'm just an old man shaking his fist at this point but in my opinion html, css and vanilla js is more than enough and is the correct solution for any reasonable web page/site/application. if you need a more complicated solution, what you are making is not appropriate for the browser and shoehorning it into the browser is stupid.
I have never seen any technology that claims to be simple actually simple. Things that I consider simple actually aim to just be good and logical, then simplicity is the inevitable.
I would like to like this project because of the hype and the maintainer that is quite cool.
But I'm a little repulsed by what is proposed by this library. In my opinion there is too much imbrication and auto magic when you use that.
From experience, it always looks nice for a small example or a very simple poc, but once you have to do a real project,then the devil is in the details. And you have to deals of the subtle changes that you need to implement in addition of a simple common case.
And in such situations, what works best is when everything is clearly separated on its own side, well abstracted with decoupled interfaces.
So related to the examples he gives, I prefer when you have style, document, template on one side and the code logic, eventually related to dealing with requested segregated on its own side.
But I'm a little repulsed by what is proposed by this library. In my opinion there is too much imbrication and auto magic when you use that.
From experience, it always looks nice for a small example or a very simple poc, but once you have to do a real project,then the devil is in the details. And you have to deals of the subtle changes that you need to implement in addition of a simple common case.
And in such situations, what works best is when everything is clearly separated on its own side, well abstracted with decoupled interfaces.
So related to the examples he gives, I prefer when you have style, document, template on one side and the code logic, eventually related to dealing with requested segregated on its own side.
Crazy how rails pjax became an entire JavaScript framework
If we talk about simplicity, how can we forget about mighty jQuery?
$('#searchForm').submit(() => {
$('#resultsList').empty().load('/search?query=' + encodeURIComponent($('#searchInput').text().trim()));
return false;
});
[deleted]
Its a good tool for teams/individuals with a high proficiency in backend tooling, and doesn't want to learn another entire ecosystem for a project. Its not equivalent to a good frontend with modern tooling.