[afavour]

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

[dgb23]

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.

[charukiewicz]

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

[silver-arrow]

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.

[Spivak]

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.

[grncdr]

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.

[Spivak]

Woah woah woah. This is a game changer.

[giraffe_lady]

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.

[gochi]

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

[spinningslate]

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.

[gochi]

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

[adamckay]

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

[sznio]

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

[unshavedyak]

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.

[rakoo]

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.

[CharlesW]

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

[wrapperup]

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.

[CharlesW]

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

[rakoo]

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

[wrapperup]

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.

[andy800]

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.

[zarzavat]

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.

[andy800]

Not hostile at all, and we arent degrading the user experience -- much improving it, in my opinion. 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.

[zarzavat]

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.

[Xeamek]

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

[giraffe_lady]

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

[gochi]

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

[giraffe_lady]

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.

[thom]

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.

[Spivak]

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.