> It becomes very obvious that this is how web development should have evolved.

I have to disagree with that. I’m happy htmx exists and that it works for many but in my professional life I've found few cases where it's the best choice. And that’s fine! It’s a wonderful thing that the web has been able to grow in so many diverse ways, there should be no one way it “should have evolved”.

IMO this is the biggest mistake in web dev in the last decade or so: that there should be One Right Way. No matter if you’re making the next Gmail or if you’re making a static blog the cargo cult of an industry tells you it should all be done the same way when common sense would tell you that’s not the case at all.

That's fair. I agree - that type of blanket statement is not helpful in the technical realm. I should have kept it at just: HTML should have continued to be expanded into what htmx is doing.

I would have love to see rather than JS evolving to include HTML and CSS, HTML should have evolved to include JS and CSS as more first-class.

Being able to write components in a single HTML file would be wonderful.

I've mentioned it here on HN before, but I've been using https://jhuddle.github.io/ponys/ for this and I still think it's pretty great.

Woah woah woah. This is a game changer.

I'm kind of guessing / reading into their comment here but. Using htmx doesn't give me the feeling of "this is the only way I ever want to do this" but more "if html worked like this I wouldn't use js most of the time." The sense that an opportunity was missed and now we're paying for it in complexity.

The complexity is just shifted around from JS to HTMX (or hypothetically, html). Not a noticeable improvement.

That's not my experience based on two scenarios:

1. Server-side rendered sites in Python using either Django or FastAPI/Jinja2 and htmx;

2. Dotnet back end with Angular front end.

In practice - for the apps I've been involved with - option (1) provides a more than acceptable user experience. There's no doubt Angular can go beyond the capabilities of SSR+htmx. But, in practice, it's in the long tail. Throw in the odd js lib, e.g. for charting, and option (1) is good enough for the vast majority of things.

The complexity is not comparable: (1) is much simpler. For a start, all logic is in one language. There's no separate build for the front end and back end; no need to reconcile state in a front end cache with the back end. There's no need to export every view as a REST API; it's a native function that gets called from the view handling function.

Others will have different experience: I'm not saying this is universal. But in my experience, objectively, it's not true that the complexity moves from js to htmx. At least, not if that implies the complexity is equivalent. It's just not the case.

Not sure you've solved the complexity when you've just slotted in another front to a general solution that is over-engineered. You could have replaced either scenarios with a single NextJS or SvelteKit solution. Go above and beyond in "complexity", write your Node backend (keeping it one language, JavaScript), and use vanilla HTML and JS to consume that.

To me, htmx isn't as revolutionary as people make it out to be, and possibly that's due to the fact I'm just not burdened by the old days of gigantic Angular apps and massive ASP.Net stacks. My history was mostly JQuery where needed (which was all the time before JS got its act together).

> My history was mostly JQuery where needed (which was all the time before JS got its act together).

htmx should remind you of those times.

I certainly has for me - it's just (fundamentally) a fancy and clever wrapper around jQuery ajax requests made via HTML attributes.

> You could have replaced either scenarios with a single NextJS or SvelteKit solution.

But then I would be using only JS. I want a backend to be something else so that I don't go insane.

The difference is those were already tools we were using. You _(hypothetically?)_ can't eliminate the complexity of dynamic apps without limiting flexibility. However you can move the complexity in-band, to a domain you are already using and preferring.

Plus, if it's done right, you can get a lot of functionality while remaining No-JS friendly.

With JS you must use JS or TS and the steam factory that comes with it. With htmx you can use any language. That's a very high improvement for many.

> With JS you must use JS or TS and the steam factory that comes with it. With htmx you can use any language.

Can you elaborate on what you mean by this? Front-end framework don't care what language back-end logic is written in. For example, I have a Vue/Vite site that calls back-end functions that I'm gradually migrating from one language to another, and no front-end changes have been required.

Much of your business logic can live in the backend, and it keeps your frontend really tiny. The idea is to generate HTML on the backend, instead of using a front-end framework to generate HTML on the client from an API call.

You can also do the same in Node if you want to, I currently have a TS website that is mostly templated HTML in production (without htmx). Htmx would be perfect for that site.

> Much of your business logic can live in the backend, and it keeps your frontend really tiny.

Ah, so "with htmx you can use any language" is true because its users are no longer using a programming language per se for the front-end, but instead are defining logic with htmx's DSL?

htmx extends html to generalize a behaviour that already exists, so it's as much a DSL as html itself is a DSL

Or Vue, yes! ("DSL" wasn't meant as a negative, I just didn't know what else one would call htmx additions.)

Yes but vue is far more involved than htmx though. Vue has its own way of architecturing your project. htmx is closer to a progressive enhancement of html

Yes, but you still need to write the frontend code in JS/TS

Yep, indeed. But htmx can reduce that a lot (to 0 even, in some instances), which is why it's really nice.

There's also WASM, which is slowly gaining steam, but it still isn't a first class citizen like JS is.

I mean, that literally the core concept entire field of programming: making abstractions to shift complexity around (else where)

For many basic & routine web page interactions, I have not found that to be true.

I can only see that experience being true if you've never used jquery (aka the same shorthands you're relying on within htmx and likely hyperscript).

I think the biggest change from jQuery flows is that the behavior is attached to the elements themselves instead of a script over here poking at the dom from the outside.

My frontend experience predates the rise of react etc. I have used jquery.

The advantage of htmx over jquery is declaring the replace condition & behavior inline as part of the component. Conceptually this is easy to reckon with as a separation of concerns thing as well as a sandi metz-ish "when would this code need to be changed" thing. The html tag is responsible for its own update, and so its update is part of the html tag.

Jquery does the same things but requires you to declare the behavior separately from the component, decide on & maintain abstractions and reuse patterns. And manage code organization so that for any updatable template code you can find the corresponding behavior declarations and understand their scope w/r/t other template code.

Most of my experience using jQuery was on sites that required progressive enhancement, and the easiest way to do that was to create an htmx-style framework anyway.

I see it as much more, many things can be stripped out altogether. Client-side state management. Client-side input validation. Fallbacks for when data hasn't been loaded yet. Less async-based code, less coordination-required and event-driven code (this stuff happens but much easier and often code-free with HTMX).

Its not a fit for every site or use case but more than any other front-end tool or library or framework, it has enabled me to actually realize the UI concepts in my head to the actual screen, and usually a lot quicker than I'd expect.

So you only do input validation on submit? Isn’t that user hostile?

This is what I don’t get about HTMX, you can’t give a good experience without client-side JS, sure some developers might love it, but that shouldn’t be the yardstick.

Not at all. With HTMX you can do real-time validation on each input element on the server and provide instant visual cues to the user anytime one fails. https://htmx.org/examples/inline-validation/

Moreover, HTMX makes it incredibly easy to change the whole paradigm of submitting data. You can eliminate some forms entirely and just enable a series of individual questions/inputs/selects one at a time, especially useful when a single static form isn't always appropriate (multiple pathways, questions/options that are contingent on the response to a previous question, etc).

In my experience the UI flow and degree of detail for avoiding common errors is greatly improved.

Disagree that it’s good UX. Now the user only gets feedback when they lose focus on the field, forcing them to go back and refocus it. In conventional React they get feedback on each keystroke allowing errors to be fixed while the field is still focused.

So when the person is starting to enter an email address, the page goes red until he enters the .com at the end? He gets an error for the first 9 digits of a phone number? Do you implement debouncing?

There isn't one thing called "conventional React", there are all kinds of validation libraries on npm and many strategies laid out on Stack Overflow. https://stackoverflow.com/questions/41296668/how-do-i-add-va...

I think it's fair to say we have different opinions on good UX, no need to debate it any further

I fully agree with you. I'm a fan of htmx, can recommend it and have used it in some projects by now. But...

For one, htmx is not a full solution to avoid JS. It's excellent for the parts that are AJAX/CRUD, which certainly covers a lot of ground. You still need something more if you're doing stuff that doesn't fit here like interactive visualizations and many other use cases. However, it integrates very well with other lightweight libraries.

Secondly, htmx is great if you're developing full-stack (like GP). Meaning you touch every part of a site from the data model to coordinating messages to the frontend etc. If you want a much clearer separation between frontend and backend of a site, especially in terms of contributors/teams, then it might not be the right tool. IMO there are plenty of good reasons to do either.

Third, and this is a bit of a combination of the first two points, if you directly fetch data from a third party, say a JSON API, then htmx doesn't help you at all.

So really as you said, there is no one right way. For me it has been working very well though. People should look into it for sure though. There's an opportunity to combine htmx with orthogonal libraries that do the dynamic parts like lit etc.

> If you want a much clearer separation between frontend and backend of a site, especially in terms of contributors/teams, then it might not be the right tool.

The point to take away from htmx and hypermedia more broadly is that there isn't a clean separation between the front end and back end of a site. The concept of completely separate front and back end teams building SPAs/JSON APIs has been a very costly development that has brought substantial complexity that is wholly unnecessary for most applications.

Your banking/project management/todo list/budgeting/insurance/education/whatever app almost certainly doesn't need to be an SPA and would be developed faster or for less money if it leaned into server side rendering (SSR) and used a library like htmx or Stimulus to enhance the user experience as needed.

> I have had good success and a rewarding experience using htmx the past year. It has been so great in tandem with Clojure using hiccup for SSR.

What kind of app are you working on?

Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken.

https://news.ycombinator.com/newsguidelines.html

You don't do your conspiracy theory any favors by making absurd blanket statements

>You can't believe that this isn't how HTML evolved to as a hypermedia.

That is why I wish HTMX to be merged into HTML5 spec. For something like 98%+ of the web it will be good enough. You then have a small JS library for the other 1.9%.

The 0.1% left is just pure JS Web Apps.

i very much hope that htmx serves as inspiration for future HTML releases, I agree that this ideally should be part of the HTML infrastructure

Out of curiosity, I presume you were working on the frontend part using Clojurescript? Have you used some kind of wrappers around htmx or just a simple js interop was enough?

We moved away from ClojureScript entirely. We just run a plain ole java uberjar with the Clojure/ring/hiccup/Compojure spitting out the HTML with whatever htmx attributes and response headers we need. There are instances where we may need to sprinkle in some javascript for some extra dynamic things - which turns out to be very infrequent. Instead of sprinkling in the javascript, we have been using _hyperscript instead - love _hyperscript.

Yeah, so moving to htmx has allowed us to jettison ClojureScript which just entailed too many parts. As a matter of fact, before going more htmx with our projects, we had moved away from ClojureScript to React directly.

I am happy with HTMX for my RSS reader. The issue with front end apps is, and always has been, the complexity of updating the UI after a user makes a change.

For instance, inside an HTMX application, I just coded up a plain ordinary <script> (no framework, no build system) that displays a count of how many characters are in a text field and also disables or enables a submit button according to that size. It's 9 lines of code plus an attribute on the input. It might be less if I did it in

https://hyperscript.org/

Immediately it faces the problem that there are two paths: (1) the initial setting of the length display (the field is pre-populated with text, I ended up setting it in the SSR) and (2) what happens when the text content changes.

If you use signals or hooks or useEvent or lifecycle methods or whatever you always see a certain amount of awkwardness that stems from the above.

Note I could have done the above with "pure HTMX" in that I could have had the event handler trigger a server round trip that repaints the text field and the submit button, it wouldn't be as bad as it sounds in performance, but boy it seems like a waste.

I've built applications that were a lot like Figma, Photoshop, or Eclipse, where the user could update some data and it could have very arbitrary effects on the UI because the user is able to add and remove many different UI elements and in a case like that you need some system that can manage dependencies at runtime.

React has revolutionized how people build widget-based frameworks, there is never going to be anything like Tk, Cocoa, GTK, WPF, Spring, JavaFX ever again, or if it is it is going to be influenced by React. There's the awkward fact that React is overkill for the typical form processing and e-Publishing applications people write with it but it is not up to the task (without an additional state management frameworm) of applications like Figma.

Personally I'd like to see a mostly declarative form processing framework with a sprinkle of scripting: before there was the iPhone there was WAP

https://en.wikipedia.org/wiki/Wireless_Application_Protocol

which had a way to send multipart forms to the client. Something like that designed to work with a software factory

https://www.amazon.com/Software-Factories-Assembling-Applica...

(one of the most visionary books of all time... the authors built an enterprise software development framework for Microsoft that was nowhere near as cool as their vision)

or a "no-code" app builder could be great.

I'm still trying to get my head around websockets. I've built some small demos that are awesome, like a program that controls the volume of my smart speakers and has the sliders move when I change the volume with the remote control. I really wish my RSS reader could update my "favorites" window as soon as I add a favorite in another window, but doing that efficiently requires answering questions all the way from the front end to the back end to the database. I'll probably find a half-baked way to do it but it's sad that I'm settling on a web application to have the limitations web applications had 15 years ago.

What are technical differences between HTMX and early versions of Angular 1? It has the same idea of sprinkling some attributes over HTML to make it dynamic for easy cases. There were many frameworks that started like this (Angular 1, Vue, etc), and after getting some traction they grew into full-blown SPA frameworks, because there is a real need for more difficult cases.

If I had to pick an “Angular-1-like” framework, I would pick the one that clearly documents it’s boundaries and provides a clear way to use a mature SPA framework when there is a need to cross those boundaries. If anyone is aware of such framework, please share.

htmx uses hypermedia, rather than client-side managed state

as much as possible, htmx tries to take HTML to its logical conclusion (from my perspective) as a hypermedia, rather than imposing other ideas on top of it

Does this ideology lead to significant technical differences from early versions of Angular 1 and early versions of Vue?

Ok, I see, the idea is to render parts of the page on server and swap those parts on the client with things like: https://htmx.org/attributes/hx-swap/

So it's not really an "Angular-1-like", but more like Vaadin in JS.

You keep using the term hypermedia and I'm not certain what is meant by that term (I was thinking it referred to linked media). Hyper means over, right? So is hypermedia more about the environment media is in than it is about links?

I think he meant just hypertext

yes, I prefer the term hypermedia over hypertext because it stresses the systemic nature of a hypermedia system: a hypermedia (e.g. HTML, a hypertext), a hypermedia client (e.g. a web browser), a hypermedia protocol (e.g. HTTP) and hypermedia servers.

we have written a book on the topic here:

https://hypermedia.systems/

you can read chapters 1 & 2 for an overview of what hypermedia is at a systems level:

https://hypermedia.systems/hypermedia-reintroduction/

https://hypermedia.systems/hypermedia-components/

As far as what the term _hypermedia_ means: it is a media, such as a text, that includes within it _hypermedia controls_. Those hypermedia controls allow non-linear branching and interactions with the media, hence the term _hyper_, that is, above, "normal" media, which is consumed passively.

The hypermedia controls we are all most familiar with are anchors/links & and form tags. htmx attempts to generalize the concept of a hypermedia control.

The book goes into gory detail if you are interested in further exploring the idea.