htmx

https://htmx.org/

by GavinAnderegg • 3 years ago

435 287 3 years ago

htmx.org

bluedays• 3 years ago

how many times has this been posted here?

vyrotek2• 3 years ago

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

dmix6• 3 years ago

I count about ~6 generic submissions to htmx root domain or direct /docs with upvotes. More generally it's higher if you include blog posts or self-HN posts. The original submission had 728 upvotes: https://news.ycombinator.com/item?id=23330881

react.dev and reactjs.org has had 2 root url submissions: (728 upvotes) https://news.ycombinator.com/item?id=35186812 and older https://news.ycombinator.com/item?id=15366446

vuejs.org only had about ~1 meaningful root domain submission: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

I suspect HTMX is more of an idea that people like to talk about on HN more generally, like Clojure and Erlang. Being the underdog matters on social media. Maybe it feels more authentic or relevant to discourse because it's still niche.

leke• 3 years ago

Not enough

laex• 3 years ago

Can HTMX be used with static site generators, such as Hugo, to create interactive documentation websites?

varenc• 3 years ago

Technically feasible? Absolutely. You can already create interactive documentation just with client side JS in your Hugo generated site. And HTMX is just a client-side JS system for building that sort of JS-required interactivity in HTML alone without directly touching JavaScript. That said, I don't think the tooling to make this simple to get started with in Hugo is there yet. Though you could certainly build it.

cpitman• 3 years ago

I think that unpoly(https://unpoly.com/) would be easier for that use case. htmx generally expects succesive http requests to only return the fragment of html that will be swapped into the target, not the entire page. So you generally want something server side that can check the request and either return the full page (either for a first hit or disabled javascript) or return just a fragment (an htmx request).

Unpoly has similar goals to htmx, but by default works with full page responses, swapping only the identified content in the page.

0xblinq7• 3 years ago

Unpoly is great. I used it a few years ago for reimplementing the UI of an application built with a traditional MVC framework and I was impressed with the results. Nobody could tell it was not React/vue/etc from the outside and the frontend code was quite simple and minimal.

adamckay• 3 years ago

You're correct that it's the general expectation, but it is possible to select certain elements from the response using `hx-select` [1], so it is possible, just not particularly efficient...

[1] https://htmx.org/attributes/hx-select/

earthboundkid4• 3 years ago

Why does documentation need any JavaScript at all beyond opening the hamburger menu?

replwoacause4• 3 years ago

Why does it even need a hamburger menu?

yawaramin10• 3 years ago

You don't need JavaScript for a hamburger menu, I am doing it with pure HTML. Hint: the <details> tag.

bmacho• 3 years ago

No need for javascript for the hamburger menu, it is doable with CSS checkbox, see for example the hamburger menu on https://lanyon.getpoole.com/ .

Or another example, the teddit reddit-frontend has collapseable threads with the summary/details tags, also works without javascript.

cosmojg• 3 years ago

Heh, the "Memes" section of their Essays page is brilliant: https://htmx.org/essays/#memes

vyrotek2• 3 years ago

And lots more if you follow him on Twitter.

https://twitter.com/htmx_org

hliyan• 3 years ago

I actually found their haiku quite insightful:

    javascript fatigue:
    longing for a hypertext
    already in hand

shearos• 3 years ago

so good

winrid7• 3 years ago

Those are great.

What's the logo of the cornucopia looking thing next to the django and rails logos?

DarkCrusader2• 3 years ago

Flask, a python micro framework.

4111111111111112• 3 years ago

A lot are also missing the point entirely for comedy's sake. Which is admittedly fine for a meme...

While I love making projects with htmx, doing the equivalent for the complicated frontends we've got at my dayjob would not be enjoyable to maintain either. You'd end up with with fragment routes all over the place and will have serious issues finding where which is used, as the routes are all just strings with variable substitutions. Its also annoying to write non-e2e tests for the resulting backend IME, which is totally fine for a lot of applications, but forces you to restructure your code awkwardly to be able to write unit-tests in the backend

Nextgrid• 3 years ago

There's a class of applications where JS-heavy SPAs make perfect sense. HTMX should not be viewed as a general anti-JS movement. It is indeed unmaintainable to deliver the same functionality in HTML as a JS SPA would allow.

The catch is that very few JS SPAs actually deliver that functionality either - the functionality I'm talking about is desktop-app-grade functionality (think a trading terminal for example) that very few JS SPAs actually deliver. Most JS SPAs are just shitty reimplementations of basic browser functionality, and that is reasonably trivial to convert to server-side rendered HTML with HTML or ad-hoc (inline?) JS sprinkled in where necessary.

Keep in mind that server-side-routing doesn't prevent the use of React or similar frameworks either. If you have an application where 90% of the pages would be fine as server-side-rendered HTML but 10% require heavy interactivity, you can have your server return a page that embeds React or your JS framework of choice. (the reverse is also possible - if you have a JS-heavy website but have a few "boring" pages like for example an account details form, you can have your backend serve that as an HTML form and just have your JS iframe it)

yawaramin10• 3 years ago

You'd end up with with fragment routes all over the place

Or, you could define every route to render a full page by default and render a fragment only if you detect an htmx request. So you end up with the same number of routes as for a normal MPA.

JodieBenitez4• 3 years ago

This is gold !

chatmasta6• 3 years ago

I continue to be impressed at the effort people will put into avoiding writing any JavaScript. Is it really easier to learn yet another DSL embedded in attribute tags rather than taking a day to setup your JS dev environment and then writing idiomatic code for running inside a web browser? Surely your htmx project will eventually cross a complexity threshold where you've added enough scaffolding that you may as well have setup a JS bundler in the first place, and yet the debugging, testing and deploying challenges will continue to push you into less-trodden territory.

I believe there might be a sweet spot for small projects unlikely to grow in complexity, maintained by a Python dev who is allergic to JS. But I don't see why you would want to invite yet another abstraction into the web stack, when it's built on top of the very language you're trying to avoid, and which you'll inevitably encounter in all its automagically obfuscated glory as soon as you run into a moderately complex problem.

benatkin10• 3 years ago

The community is convinced that their form of HTML attribute salad is hypermedia and others, that look better IMO, are not. That explains some of the excitement over it.

They have a tiny bit of a point, in that the forms are able to work without client-side JavaScript* thanks to progressive enhancement, and only Svelte and maybe Remix and a handful of others do that. Svelte does a better job of explaining it and making it customizable IMHO though. https://learn.svelte.dev/tutorial/progressive-enhancement

Though Svelte has this, I think perhaps most Svelte devs prefer JSON to form data, because it's directly nestable. That in general is good for full-stack development. You don't see very much TOML in the framework written by the author of TOML, but you do see a little. :) https://redwoodjs.com/ form-data is very TOML like in its data model.

* Except nowadays most of them depend on it to be usable.

n2d4• 3 years ago

thanks to progressive enhancement, and only Svelte and maybe Remix and a handful of others do that.

Notably, since a few weeks ago, Next.js (by far the biggest of the pack) has support for progressive enhancement with Form Actions.

https://nextjs.org/docs/app/building-your-application/data-f...

jgoodhcg• 3 years ago

I think there is something to HATEOAS. It gets around the state sync issue of a distributed system in a clever way. As someone who has mostly built React based SPAs it’s like the network is just part of the unidirectional flow of a reactive app. It doesn’t work for all cases but I think it might work for 80% of them. It also feels right to be so close to just html in the browser.

pphysch7• 3 years ago

htmx isn't about avoiding JS, it's about removing arbitrary limitations from HTML that have elsewhere been circumvented with JS. Users write less JS as a side effect of having an actually useful, modern "HTML", and with any luck the core features of htmx will eventually make it into standard HTML

candiddevmike• 3 years ago

That makes no sense, HTML is by design not supposed to be dynamic, that's the point of JS. There's a nice, clean, separation of concerns with HTML, CSS, and JS.

As an aside, htmx uses JS under the covers to make HTML dynamic.

qbasic_forever• 3 years ago

I view it more as server-side first modern app development. If you have a Django app for example htmx is a fast and easy way to make it feel fluid and dynamic like a modern SPA, but still using all your server generated Django logic, templating, etc.

I seriously doubt many people decide they prefer coding up logic in attributes. It's just what HTML gives you as an extension point.

0xEFF• 3 years ago

Is it really easier? Yes.

The project I’m currently building is an enterprise b2b SaaS and I’ve gotten it fully functional without writing a single line of JavaScript. By functional I mean it looks and behaves like there is JavaScript, because there is with HTMX, but it’s abstracted away to the point of taking none of my time, which is what matters.

There’s no way I could learn the JavaScript ecosystem in a day. Maybe I could get something functional in a day but the technical debt would be too costly. I’m not sure any human could learn it in a day with acceptable technical debt trade offs.

For my situation of an enterprise app that’s mostly declaring resources in the backend via API, it’s been much faster to write in my preferred backend language only. I build the API, make a command line tool in the same language that calls the API, then add a basic HTML form for the demo and it’s great.

benatkin10• 3 years ago

I think what you're saying demonstrably doesn't apply to the majority of developers. You could follow something like this: https://learn.svelte.dev/tutorial/welcome-to-svelte

However you would just be able to do what you can do with SvelteKit (Parts 3 and 4). Not too different from what you can do with HTMX.

You would need to deploy SvelteKit but could have SvelteKit call your backend API for all of the heavy lifting and its deployment requirements would be minimal.

Yes, a bigger chunk of the JavaScript ecosystem takes longer to learn, but you can also do more with it. If you make an apples to apples comparison I think they're effectively in the same ballpark, and JavaScript is better just by having more resources.

tomberek• 3 years ago

Is any of this available or would you be willing to share or discuss? I’ve done some HTMX/_hyperscript for prototypes and hobby projects and loved it; contributed a few of the cookbook examples. Overall it is a pleasant ecosystem. I’m curious how this worked out in your use-case because I’m considering it myself. What are the hurdles? Any lessons learned? Recommendations?

austin-cheney• 3 years ago

Software developers, especially DOM fearing front developers love using the word easy. It isn’t so much an infatuation but more like a fatal attraction obsession where obstruction means war on a very emotional level. Ironically, people are loathe to confront these feelings openly and thus cannot define the word easy with any kind of clear practical application.

So, I did the world a favor and wrote just such a definition: https://github.com/prettydiff/wisdom/blob/master/Easiness.md...

PaulHoule3• 3 years ago

For a certain kind of application HTMX is a convenient way to work. It lets you write a webapp the way you did in 1999 except you can update pages partially. Here is a screenshot of an my HTMX-powered RSS reader

https://mastodon.social/@UP8/110432673973724419

This is a research project, but it's a research project by an applications programmer so it has to be solid. Yet I have to be able to change anything when I want to do it and if I used the "standard model" I'd have to change both the back end and the front end when adding a new task but this way I can add a new form once and add it to the rotation, pop it up in a modal, split it out on another page, etc. If this was a big production system with lots of people tagging things I could roll out new tasks by rolling out new forms and not force reloading of a front end.

I use it together with other client-side Javascript, for instance with D3.js for highly customized charts and visualizations.

A major time saver is that it skips the Javascript build. When I make I change I reboot a Python server and it comes up in 1.6s.

tentacleuno2• 3 years ago

You don't have to build JavaScript; it runs natively in the browser. In fact, the only time when you would have to consider a dedicated build step is if you were using something like TypeScript, or if you wish to use external modules. In the case of external modules, check out ES6's import syntax. You can import from a URL just like it's an NPM module. I believe a few CDNs are designed to facilitate this use-case too.

gen220• 3 years ago

Hey! I'm also building an HTMX-powered RSS reader, although it's more a side project than a research project. Good luck, it's been lots of fun for me so far!

I've also found the productivity of a "strong" decoupling from frontend and backend to be super satisfying.

graypegg2• 3 years ago

I think you could expand your definition of small projects somewhat.

I used to work at a marketing agency many years ago, there's a huge number of professional, revenue generating websites out there that just host a form. And that form probably just needs to send an email.

Using a form, then a network request to some service, then showing some HTML will solve 100% of the problem for the local hair salon taking reservations, some mom and pop store's contact form, or a local newspaper's letter to the editor form.

HTMX supports that flow with a couple of HTML attributes. Barely anymore "code" than authoring and styling the actual form.

To be fair, a callback and fetch() call aren't much harder but provides just enough complexity to make shooting yourself in the foot easy when you bill hourly on a $200 budget.

eduction2• 3 years ago

there's a huge number of professional, revenue generating websites out there that just host a form. And that form probably just needs to send an email.

You don’t need JavaScript or htmx for this. It’s been in the html standard since 1.0. Forms work from plain vanilla html.

Using a form, then a network request to some service, then showing some HTML will solve 100% of the problem for the local hair salon taking reservations, some mom and pop store's contact form, or a local newspaper's letter to the editor form.

All of these things can be done without htmx or JavaScript. It’s just forms.

(You “need” htmx or JavaScript if you need to dispatch a request without actually submitting the form and triggering a new page load, for example to autocomplete an email or get search suggestions. None of your examples need that.)

rafark2• 3 years ago

It’s very clear at this point that we need real browser APIs instead of implementations (real interfaces that can be implemented and run in any language using web assembly).

listenallyall7• 3 years ago

Never seen a tool where the people who don't use it seem to make up some of the craziest, most obscure, weirdest justifications for avoidance. It's totally fine if you're not personally down with HTMX!

However, stating that we're avoiding "idiomatic code" is incorrect. Are you claiming React and JSX and useEffect are idiomatic? Really? Surrounding HTML fragments with return() and attributes with braces is idiomatic? These are literally the antithesis of HTML.

Perhaps the real reason we're happy is that we're experiencing a huge productivity increase, lower cognitive load, fewer difficult bugs, terrific performance, and a great dev experience.

benatkin10• 3 years ago

Here's some code that I don't find especially idiomatic:

    <form hx-post="/test">
        <input _="on htmx:validation:validate
                    if my.value != 'foo'
                        call me.setCustomValidity('Please enter the value foo')
                    else
                        call me.setCustomValidity('')"
            name="example"
        >
    </form>

It has a multiline HTML attribute value and an unfamiliar programming language with the english word me that is sure to be confusing to some who don't speak it as a first language.

https://htmx.org/docs/#validation-example

creatable3• 3 years ago

Why do I continue to see people imply that React is the only way of writing frontend web applications with JavaScript? There are plenty of alternatives to React that I would say are far more "idiomatic". I highly recommend taking a look at Vue 3 or Svelte to get a better idea of what frontend JavaScript can be.

seattle_spring2• 3 years ago

Never seen a tool where the people who don't use it seem to make up some of the craziest, most obscure, weirdest justifications for avoidance

Sure you have: literally any frontend framework post, from React and Vue to roll-up, webpack, and everything in between. Tons of non-FE engineers or engineers that work on small and trivial apps will flood in to say why the lib in question, and usually the entire FE ecosystem, are crazy, rapidly changing, undecipherable, etc.

recursivedoubts9• 3 years ago

htmx removes abstractions from your web project, by extending the existing abstraction of hypermedia to the point that it can implement many common UI patterns without any other concepts:

https://htmx.org/examples

i have a free book available on the hypermedia approach and how it contrasts with the SPA/thick client approach (both its strengths and weaknesses) here:

https://hypermedia.systems

genmud3• 3 years ago

I might be going against the grain here, but the JS ecosystem is just a series of goalposts that are constantly moving and it has burned so many people over the years that folks just don’t want to deal with it.

I’m fine learning JS, but with the ecosystem it isn’t just learning JS. It’s learning the new hotness for packaging / versioning, it’s the frameworks that are constantly in flux, it’s the inconsistent abstractions that seem to be mercurial and constantly changing.

If we were to sit down and write some frontend code to say, make a simple kanban board every 9 months using “current” JS best practices or popular frameworks over the last 6 years…

How many different tools might you run across?

How easy would it be to take that 6 year old code and bring it up to modern standards?

The reason you see people allergic to the JS ecosystem is because it is incredibly opinionated while simultaneously being a free for all.

marcus_holmes• 3 years ago

The "new hotness" only matters if you're going to try and get a job as a FE dev in a large team. The "old hotness" still works, and likely has the more obscure bugs worked out of it.

And you can always just write the thing in JS without any hotness at all. The JS ecosystem's obsession with frameworks is a diversion. You really only need a framework if your site is super complex. And even then, if you're careful about how you write your JS, you may not need a framework (you'll end up creating your own, probably).

I'm with you that the JS ecosystem is a seething mess, but I don't think that's actually a problem unless you want a job as a FE dev. You can just ignore it ;)

loveparade2• 3 years ago

htmx is another tool just like that, another goalpost in the frontend webdev world. It's just happens that the most recent hype is "don't write JS", but fundamnetally it's no different. Just another framework/library that has gotten some traction. In a few years we'll be back full cycle and it will be in vogue to write JS again, probably because htmx and associated projects have grown to complex.

baby2• 3 years ago

I’m pretty sure you can continue to use jquery and everything still works fine :D

hakfoo2• 3 years ago

What I hate is that you don't even write JavaScript anymore.

You write fantasy future JavaScript. Sure, it will be available in ECMAScript 23, scheduled to drop in real browsers in 2092. But for now, here's a convoluted mess of polyfills, Babel, and WebPack, that we HOPE papers over the real behaviour of browsers, and suddenly your test-and-debug cycle has introduced a flow-shattering 15-second build cycle each time you change a file.

julianeon• 3 years ago

I think this comment is a bit out of date, especially if you’ve been watching JS from a distance for the past couple decades. This would’ve been true circa 2014. In 2023 it’s obsolete.

There’s one framework that won, that’s all you have to learn, as far as the industry goes (as opposed to hobbyists) it’s been decided. React won. React is the framework you learn.

“Popular frameworks for the past 6 years” - React has been dominant over that entire time period, from beginning to end. React is what you would’ve reached for 6 years ago (it was already mature then, in 2017) and it’s what you’d turn to now. This is what I mean. You could update your React code to use hooks instead of classes - or you could not, it will continue to work if you don’t.

The “JS changes all the time” take is frankly out of date in 2023. “Which framework do I learn…” you learn React, the framework that won. It’s pretty much that simple.

throwaway2037• 3 years ago

This is a great post. I'm not a web dev myself, but I have a couple on my team. I criminally underrated the challenge of maintaining a complex web app. It is madness: endless incompatible, forced upgrades.

Real Question: Why does this ecosystem have this issue, but others have it less? For example: Why doesn't Python or Java have the same madness?

Please don't read the question as criticizing web dev / JavaScript / etc. My curiosity is genuine.

To be fair, it does feel like C++ is more maddening than Python or Java, but part of can be explained by (1) native code generation (build is way harder than languages that run in a VM) and (2) the insane complexity of the language which _traditionally_ made IDEs much weaker than other languages. MSFT Visual Studio and JetBrains CLion have come a long way. (I can already feel the HN pitchforks poking at me for these C++ comments!)

sroussey3• 3 years ago

I might be going against the grain here, but the JS ecosystem is just a series of goalposts that are constantly moving

Welcome to real life.

Beware the ecosystem that does not change (COBOL).

dmix6• 3 years ago

Just look at Wordpress for the demand for shoehorning things into something because it seems easier on the surface and accessible without learning harder programming stuff, or at least investing in the initial overhead.

There will always be demand. It's likely very practical for certain usecases but that won't stop people from abusing it in full SaaS web apps before some CTO joins and has to abandon it all when requirements evolve. Although I've seen some highly capable apps built on top of jquery plugins like Select2, which were extended well beyond their initial intent. Things that work is all that matters at the end of the day when it comes to making $$$.

pphysch7• 3 years ago

Wordpress is a platform or framework, HTMX is neither. If you don't like what HTMX offers for your next feature... just don't use HTMX attributes on those elements. So comparing it to WordPress, or React, etc. is not accurate.

dimatura• 3 years ago

I've used htmx to write some relatively simple internal tools, and it's been really useful for that. I know a little javascript, but my web skills are really outdated - I acquired them back when you rendered HTML on the server and maybe added a little interactivity with jquery. With that background, using htmx to swap out elements (rendered server-side with Jinja templates in flask) has been a lot more productive for me than trying to overcome my unfamiliarity with modern JS. The modular structure of Jinja templates actually works really well the htmx paradigm IMO.

dicriseg• 3 years ago

This is exactly what I use it for. It keeps me working mostly in python, flask, and jinja, which I know a lot better than js. For just doing some background requests and element swapping, it’s absolutely more efficient for me.

slmjkdbtl• 3 years ago

I think one big up with this html-centered approach is you don't have to worry about SSR

forgotmypw17• 3 years ago

It's not that I avoid JavaScript, it's that I want my work to be accessible to someone without JS as a requirement, for whatever reason they may be in that state and configuration, whether by choice or not.

I write plenty of JS (12% of my biggest project, according to GitHub), but it's added onto HTML in such a way that the HTML still works for:

* a security-minded person who has it turned off in their browser,

* a user of a browser without JS support, such as Links, Lynx, w3m, Dillo,

* someone with an older device using NoScript for performance reasons,

* someone with a slow network connection who can't load the included library,

* a server operator who chooses to disable JS rendering/injection and serve plan HTML, such as the website for a Bitcoin conference,

* another scenario I haven't even thought of or imagined yet.

My conscience as a developer and enabler of information access just does not allow me to write off all these people as undeserving of accessing my websites. You may feel differently, and I think that is OK, too...

unmole2• 3 years ago

I get what you're saying but I the context of the discussion, Htmx requires JavaScript, doesn't it?

chatmasta6• 3 years ago

Every site I build works with JavaScript disabled. I use Next.js with server side rendering so that the initial page load is an accessible HTML document that is progressively enhanced for those with JS enabled during hydration by adding interactivity and smooth client side page transitions without full page reloads.

None of this is possible with HTMX if the user has JavaScript disabled. The first step to using HTMX is to import a JavaScript file from a CDN, and none of the features for partial page replacement will work without it. Whereas with Next.js, with JavaScript disabled, a Link will revert to a full page load where the next page is rendered on the server. It will be progressively enhanced to what appears to be a partial page load by using the same JavaScript that would render the full page on the server to instead render it on the client starting from the current state of the DOM.

recursivedoubts9• 3 years ago

i will have you know that i wrote an awful lot of javascript to avoid writing javascript!

nbow• 3 years ago

It makes sense to me that good web developers would be multifunctual enough to implement a solution based on the complexity of the required design. React is conversely way too complicated for a lot of the stuff that's easy to do in HTMX, so you should be able to do both in my opinion.

robertoandred2• 3 years ago

Htmx is for backend devs who think frontend must be simple stuff for simple devs. Then when they realize it’s not, they come up with some crazy new framework to prove to themselves that they know better and can still act superior.

seattle_spring2• 3 years ago

I'm not saying I agree with your point, but I will say that the worst engineers I've worked with in my career are backend engineers who look down on frontend engineers/engineering.

SanderNL3• 3 years ago

You accept 5% complexity to completely drop all the rest. “Bundlers”? Please.

I know that from a webdev bubble it seems the world is made of JS - I should rather say “and its various frameworks” - but that is not the case. There are lots of places where keeping the surface area small is very much appreciated and the concept of using “bundlers” for your moderately complex crud interface will get you laughed out the room. I guess that is where htmx can shine, not in webdev consultancies.

chaxor• 3 years ago

Many people may disable js when browsing. So there's that.

chatmasta6• 3 years ago

HTMX requires JavaScript to work. If your goal is to render a usable page on the server and return it to the client, you can do that with plenty of full stack JS frameworks like Next.js, and as a bonus, it uses the same code to render it as it does on the frontend.

bee_rider• 3 years ago

I don’t do any webdev stuff, so I don’t k or about setting up a stack and all that stuff. But, it would be nice from a user point of view if this became popular enough that I could go back to browsing with JavaScript turned off.

alex_lav4• 3 years ago

I continue to be impressed at the effort people will put into avoiding writing any JavaScript

I continue to be impressed with the amount of handwaving the already-initiated do to downplay the horrors that are starting JS development in 2023.

mrcwinn• 3 years ago

For those with flexibility or a new project, also consider Phoenix LiveView. It’s been a joy to work with so far.

graypegg2• 3 years ago

Or possibly Hotwire! (Turbo frames really) [0] Also found it to be wonderful to work with.

[0] https://hotwired.dev

sodapopcan6• 3 years ago

There are a variety of these types of frameworks for most peoples' favourite web-programming language (LiveView, Hotwire, LiveWire, Blazor...).

llambda• 3 years ago

How does htmx compare with alpinejs (https://alpinejs.dev/)?

earthboundkid4• 3 years ago

Alpine is more of a Vue replacement and HTMX is more of a fetch replacement. You can use both, although it’s a little redundant.

halfcat2• 3 years ago

HTMX and Alpine pair well together.

Generally, Alpine would handle pure client-side functionality, like toggling classes, expanding a drop-down multi-select, etc.

HTMX for server interactions, fetching, posting updates, etc.

One can accomplish a lot with little to no JS, with the app primarily driven by the backend. Which is quite a benefit if you know and like PHP/Python/Go/Elixir/C++ better than JS. Or just don’t like working in JS.

jhp1236• 3 years ago

My problem with this approach is the same one raised by Dijkstra against the goto statement. These update actions are too unrestricted and don't offer any way to analyze the program's progress systematically, based on the program source code.

fallat2• 3 years ago

Could you elaborate? Genuinely curious.

jhp1236• 3 years ago

let's say that you have an upvote button

   <button hx-post="/upvote"
           hx-trigger="click"
           hx-target="#notification-bar"
           hx-swap="outerHTML"
       >
     Upvote
   </button>

Well where is this notification-bar? It could be anywhere on the page. Maybe it was introduced by another htmx action from another endpoint. Answering this simple question could take a lot of work. There is no way to work it out systematically short of auditing every interaction on the page.

halfcat2• 3 years ago

The same can be said of a React frontend that talks to a JSON API. There is some structure, organization, and convention to the API endpoints, one-way data flow, and so on. Otherwise it’s chaos.

On our most recent project we do the same with Django and HTMX. Organized endpoints by component. Composable, reusable server-side components with django-components [1]. And we’ve been orders of magnitude more productive, shipping more in 1-2 months than we did the previous 12-18 months working with React.

[1] https://github.com/EmilStenstrom/django-components

roguas• 3 years ago

How same could be said? React makes calls to json api typically - both sides are very inspectable. Given that you have to resort to session for state, things can get messy on the data layer (a poison pill for stateless rest json api)

panic• 3 years ago

"Load HTML from a URL and replace part of the page with it" is a powerful technique for progressive enhancement, even if you don't want to use a framework like this. A button can send users without JavaScript to the URL directly, while users with JavaScript can have that part of the page replaced inline.

scoofy• 3 years ago

I use htmx heavily on https://golfcourse.wiki

It’s nice and easy to work with, and lets me keep almost everything in python (flask).

It’s a bit more bandwidth, but it’s a hobby/bootstrapped project right now, and since it’s an api, if I ever make any money, it’ll be easy to rewrite and heavy lifting.

I like it because I’ll write 3x the code in the same amount of time if it’s python. I just don’t like js much even though I know it’s fine.

rafark2• 3 years ago

This is VERY cool. I’m very excited to see a project like this. Is it me or there has been a lack of wow-factor projects lately like when jquery was introduced. Or templating engines like handlebars. Or when angular and react took over. Browsing the htmx site felt like learning about those aforementioned projects for the first time.

asah• 3 years ago

can htmx be used offline? i.e. am I screwed if I load an htmx page, close a laptop and get on a plane?

fredrikholm2• 3 years ago

If the page has loaded, it's loaded. There's no moving parts once you have rendered HTML from the wire.

whatscooking• 3 years ago

Ah yes…the daily htmx post

recursivedoubts9• 3 years ago

i really have no idea why this is happening and am kinda nervous...

replwoacause4• 3 years ago

Yep, I’m delighted when I see it and then I give it my automatic upvote.

robertoandred2• 3 years ago

“Aren’t you sick of new web frameworks? Here’s a new web framework!! It’s different and special because we said so.”

jedberg• 3 years ago

Seriously, why does this keep popping up? I get it, it's cool. But I feel like in a month we're going to see "How I gamed the HN front page to put my website on the top every day for a month".

jaxrtech• 3 years ago

This vaguely reminds me of Adobe's ColdFusion except in the browser for better or worse.

pbohun• 3 years ago

This is the first time I've been excited to learn about a new web technology in a while. I'm going to have to play around with this to see how I want to use it. I wonder what other little things like this could be used to simplify webdev?

nneonneo• 3 years ago

The filler text on some of the examples (e.g. https://htmx.org/examples/tabs-hyperscript/) seems to be generated by Hipster Ipsum https://hipsum.co/. Cute.

I kinda like the aesthetic. It feels a bit like what HTML might have looked like if XHR had been baked in.

sgc2• 3 years ago

Does this cause problems for web crawlers indexing sites, since these are not typical js event listeners etc? Even though they must use them in the background, there is an abstraction the crawler must be able to navigate. I had an entire site de-indexed for getting too fancy once, so I worry about this type of thing perpetually now.

psnehanshu• 3 years ago

It won't matter as long as you are using regular `a` tags for links. You anyway don't want robots to submit forms and perform any actions that are meant for users.

8organicbits• 3 years ago

I'd think HTMX would work with even the most basic of crawlers, since it doesn't require JS at all to be usable. But I don't know how well a JS aware crawler would do with it.

I guess you could block htmx.js in robots.txt to force them to the non-JS experience?

PrimeMcFly2• 3 years ago

I personally don't see the utility in this too much, but then I'm old fashioned and go out of my way to use as little JS as possible, doing everything via CSS as much as I can.

Even though JS is ubiquitous and small, well written JS is harmless, I still try to avoid it like the plague. Maybe just to somewhat fight back against all the excessive JS that plagues every site.

quacker• 3 years ago

I'm old fashioned and go out of my way to use as little JS as possible

The point of HTMX is to avoid writing custom JavaScript.

PrimeMcFly2• 3 years ago

But it does that by including a bunch of JavaScript and obscuring it. So not exactly including as little JS as possible.

replwoacause4• 3 years ago

I love htmx and have used it to build internal tools quite successfully. It allows me to work in my preferred language on the backend, write some basic ass html and spinkle in a few attributes and get some frontend reactivity that I otherwise wouldn’t have because I hate Javascript.

KevinChen62• 3 years ago

Learning to use any new tool comes at a time cost, and if I learn this and then a newer, more convenient tool emerges that can replace it, I get stuck in the question.

Are people driving the tools?

Or are the tools binding people?

emodendroket4• 3 years ago

Perhaps too cynical from my dislike of frontend but I sometimes suspect the churn is spicing up monotonous work for some people.

KevinChen62• 3 years ago

Yes, I also don't like doing front-end development work, not because front-end development work itself is offensive, but doing front-end development work is a very meticulous thing, which requires me to invest a lot of time, which will reduce my energy investment in other work content.

adamredwoods• 3 years ago

I'm not a fan of adding functionality to hypertext attributes. I want an expected set of attributes to a component, not a new set of attributes that extend existing components. A lot of functionality can get obfuscated.

emodendroket4• 3 years ago

Strictly speaking you could already do this with x- attributes and plain JS, right?

L0stLink• 3 years ago

how do you feel about JSX?

chatmasta6• 3 years ago

JSX is a templating language, not hypertext.

sandGorgon2• 3 years ago

HTMX + Java is almost as good as react!

I think people mistake what htmx is - they think it is a way to not write react/js in a node environment.

Where HTMX really shines is being able to bring the experience of writing React-like code without a nodejs environment in Java for e.g. (or Golang, Rust, etc)

davidatbu2• 3 years ago

Where HTMX really shines is being able to bring the experience of writing React-like code without a nodejs environment.

FWIW, if that's all you're after, and you've mastered the Rust borrow checker, Yew (a React-like experience), or Leptos (a SolidJS-like experience) might be interesting to look at.

sandGorgon2• 3 years ago

not its not the same thing. I work in Java (not rust), but the analogy will hold.

Yew is writing Rust to create html. Same as Java Thymeleaf. Here's the problem - Java developers are bad at UI. And good UI designers/developers think in HTML. I am not pro or anti this situation...im just talking about the reality.

The tooling is also around html. Figma-to-HTML is the most effective way to have your design cycle work.

This is where HTMX shines. HTMX is just HTML++. It is is not Rust or Java. Which means your design cycles will continue to work.

ulrischa• 3 years ago

A lot of this what htmx does is a one-liner in Jquery. I know: the unpopular old thing :)

TekMol6• 3 years ago

Hmmmm... no.

This:

    <button hx-post="/clicked" hx-swap="outerHTML">
        Click Me
    </button>

Should be just this:

    <button onclick="htmx.post('/clicked', 'outerHTML')">
        Click Me
    </button>

This way, no magic would be needed, a lot of indirection and complexity would be avoided and everybody who knows HTML and JS could immediately read and understand it:

    - When does something happen here?
      When the button is clicked.

    - What does happen?
      htmx.post() is called.

the_gipsy4• 3 years ago

You're missing the "swap".

TekMol6• 3 years ago

It's always an interesting question how explicit one wants to get.

In this case, I would say the 'outerHTML' parameter is enough to define what will be done with the post result.

yscodes• 3 years ago

I like your change. Much clearer.

Makes me more interested than the current syntax.

listenallyall7• 3 years ago

Your opinion is totally valid. However, is it really difficult or tricky to recognize that 'click' the default event of a 'button' tag? Isn't 'onclick=' kind of redundant?

mekoka• 3 years ago

no magic would be needed, a lot of indirection and complexity would be avoided

Is this an informed criticism based on your experience having worked with htmx, or is it just an off the cuff opinion?

Personally, I don't think the goal should be "no magic", or "no indirection", or "no salt", or no "sugar". I feel that aiming for just the right amount of those things, to have the goody without crossing over to disgust, is a sound goal.

renerick6• 3 years ago

You are missing the fact that html has very restricted list of events that can be defined in an attribute. Htmx allows to listen on any event, plus some extra features on top, such as event throttling, polling, synchronization between elements. Stylistically I can see the appeal of your proposal and even agree on some ways, but it's not functionally equivalent

https://htmx.org/attributes/hx-trigger/ https://htmx.org/attributes/hx-sync/

TekMol6• 3 years ago

What would be a simple example of an event that you want to define inline but can't in plain html?

Can you give minimal example on jsfiddle so we can compare different approaches?

the_gipsy4• 3 years ago

Think of the tags as a constraint. It's quite easy to check that certain constraints are met with tags. It's much harder to check on this <onevent>="htmx.<action>(<url>, <swap>)" convention. Soon you'll have unconstrained code creeping in (e.g. onclick="!loading ? htmx.post('/clicked', 'outerHTML') : void(0)").

TekMol6• 3 years ago

That is what function parameters are for.

If you want a parameter "not if already loading", make it part of the post() function. No reason to make it an attribute on the html element.

recursivedoubts9• 3 years ago

Do you consider the href attribute of anchors "magic"?

0xblinq7• 3 years ago

I'd still pick Unpoly over it. Seems far more high level, feature rich and easier to use although less popular. And if I wanted a popular approach I'd pick Hotwire which can be used with any backend framework anyways.

https://unpoly.com/

https://hotwired.dev/

JodieBenitez4• 3 years ago

Can you expand a bit on why you prefer unpoly over htmx ? I like htmx but I'm genuinely interested in alternatives around the same concept.

0xblinq7• 3 years ago

Just answered this on a sibling comment.

replwoacause4• 3 years ago

I am also interested in why you like Unpoly more. Genuinely curious because I use and like HTMX and don’t really understand what you get with Unpoly that you don’t with HTMX.

0xblinq7• 3 years ago

I could ask the same question I guess, what do you get from HTMX that I can't get from Unpoly?.

I think you can achieve the same thing with both, but Unpoly is higher level, that means I have to write less attributes/code to achieve the same stuff I guess.

"Compilers" are also a nice way to attach custom code. All the helpers for form validations, the extremely easy way it provides to do modals, and layers in general. The navigation feedback (a'la turbolinks) when navigating across pages, the caching, the error handling. The up-keep for keeping a video player or anything else across pages transitions, and absolutely everything of this can be accessed from a JavaScript API in case you need to perform any of this from your own code and most of these APIs also trigger events.

Probably you can do all of this with HTMX too, but it is more work.

marko-lev• 3 years ago

HTMX is just HTML.

HTMX substitutes a DOM element with the HTML response you get from an on-click HTTP request instead of redirecting to a new page.

Claims of HTMX being yet another complexity or yet another JavaScript framework fail to acknowledge this.

4111111111111112• 3 years ago

no, htmx is (technically speaking) just another JS framework.

Just look how VueJS got started, it began with sprinkled in html and was marketed as the framework for backend devs, as you were just writing html to render lists/objects etc.

And htmx does more then what you're alluding to here, as should be obvious from reading their docs about server-side events, notifications, lazy loading, JS extension api etc

pavlov• 3 years ago

Long arguments here about whether HTMX or React or something else can qualify as idiomatic HTML.

But the truth is, HTML itself does so very little that it’s barely useful as a starting point for building applications.

Arguing about idiomatic HTML in this context is like arguing about how to write a scientific paper in idiomatic toddler language. One faction thinks you should stick to monosyllabic words. Another believes drawings of colorful balloons are key. Both are held back by the fundamental assumption.

emodendroket4• 3 years ago

Seems like a horrible idea that totally breaks separation of concerns, so I’m sure it will be a huge success you’ll see everywhere very soon.

the_gipsy4• 3 years ago

There are multiple ways of separating concerns. Htmx is faithful to the original HTML separation of structure / presentation / behavior. Elm cuts this way too but with a completely different approach. React does components.

Pick your poison because in any case there will be crossing of those concerns.

Personally I've never seen react code that doesn't go sour beyond a toy demo.

emodendroket4• 3 years ago

More of an Angular fan though I haven't used post 1.x much.

justusw• 3 years ago

On the one hand I see the appeal of staying inside, say, Django the whole time and getting 3x done.

On the other hand I am so pampered by front end component based templating especially with Tailwind.

It would be cool if I could just import my Svelte components from Django.

adieth• 3 years ago

Have you looked at something like Slippers[1]? It allows you to have a set of components that you use in Django templates. I'm using Bulma, not Tailwind, for my project and I like how it creates an abstracts over e.g. CSS classes.

[1] https://mitchel.me/slippers/docs/introduction/

winrid7• 3 years ago

I really want to use htmx on the next project but I am not sure how to make it handle poor network connections yet. The app I'm building will be used in areas with poor mobile connections - I want to submit a form, add it to a list and say it's pending saving, while the user can add more. Have to use hyperscript probably?

Can trivially do it in vanillajs so I'm sure it's possible?

yavor99• 3 years ago

Hmmmm... can you define a "poor connection"? The web used to work the "htmx"/hypermedia through all the dial-up years where things were REALLY slow. I see no reason it would not work now.

winrid7• 3 years ago

literally no connection at times. A queued request cannot be lost.

winrid7• 3 years ago

"Hmmm I know better than you". Peak HN lol. This is for middle of the desert time tracking.

winrid7• 3 years ago

I'll probably just build a native app with godot or something...

thinkingemote• 3 years ago

Browser dev tools have a throttle mode, might help.

timetraveller26• 3 years ago

stop trying to make htmx happen, it's not going to happen

silver-arrow• 3 years ago

I have immensely enjoyed and benefited from using htmx for the past 18 months on projects with Clojure as the backend language. I had done years of full-stack Angular then React on the front-end and Java Rest endpoints on the back-end with teams of all sizes.

htmx has been a revelation and has really opened my eyes to the nuances of hypermedia development modalities that I was ignorant of. For me, it has become very clear that htmx and hypermedia development is far more simple, productive, beneficial, and FUN for 90% of web dev use cases. I feel huge disappointment how unnecessarily web development evolved into bad client server rpc json protocol for basically everything web.

Kudos to the htxm creator and his vision of what should have been. My experience absolutely corroborates his thinking on these things.

ChrisArchitect• 3 years ago

Anything new here?

Some discussion 5 months ago:

https://news.ycombinator.com/item?id=33987578

camdenlock• 3 years ago

The crucial flaw with htmx is that it’s an enhancement of html itself; if a fancy and interesting new UI pattern is invented somewhere, the htmx devs or contributors will have to add support for it into htmx itself!

And imagine if htmx became absorbed into the real html standard. It would take much longer for the standards body (and then browser makers) to respond and implement.

So the crucial flaw is that it will always be reacting instead of innovating. And more generally, this is likely why the “thick client” approach is more popular on the web these days. Nobody wanted to wait around for standards bodies and browser makers.

htmx

Related Stories