Hacker News Reader

Comment by recursivedoubts | Hacker News Reader

hi there, as many of you know, i am the creator of htmx and I'm happy to answer any questions about it

htmx has seen a surge in popularity, triggered by a video by fireship dev (https://www.youtube.com/watch?v=r-GSGH2RxJs) and a series of videos by ThePrimeagen, a popular twitch streamer on it

hacker news readers might be interested in the essays I have written on htmx & hypermedia in general here:

https://htmx.org/essays

and in a book I authored with a few other writers that we recently released on hypermedia, htmx and a mobile hypermedia called Hyperview:

https://hypermedia.systems

while I am a fan of htmx, obviously, I think the deeper concept that it touches on is hypermedia, which is a worthwhile idea for people to explore even if they don't plan on using it in day-to-day programming.

There are also lots of other great hypermedia-oriented libraries worth checking out such as Hotwire from 37signals, or, my favorite after htmx, https://unpoly.com

View on HN

https://twitter.com/foxy4096/status/1691432812870828032?s=20

This is a boon to many django developers.

I remember few month ago I was making a post liking system, before htmx, I had to use jQuery to fetch the json api server and update the like count, but with the use of HTMX, oh boy it was like I was just writing plain html along with my django logic.

This is one of the greatest thing I've found.

Also, handling forms with HTMX is also very easy.

HTMX really improve both user and developer experience.

I've also found htmx a great way to retain server side rendering with minimising the recalculation cost of client changes.

By avoiding needing to add lots of client side logic to still get very low latency updates, it's given me the best of both worlds.

The way Django's template system works also makes it so easy to render a full page initially, then expose views for subcomponents of that page with complete consistency.

On a tangent, Django's async support is still half-baked, meaning it's not great for natively supporting long polling. Using htmx to effectively retrieve pushed content from the server is impeded a little by this, but I slotted in a tiny go app between nginx and gunicorn and avoided needing async he'll without running out of threads.

The other day I wrote an htmx extension for aws api. You could describe an element using the common htmx tag such as for confirmation, triggers etc, but the ajax fetched any aws object like ec2 instances, pipelines, whatever. It's awesome!

I'd be interested in learning more about this can you share any links?

It's still very early and a wip, I haven't published anything yet.

If I get the time I will publish and link it for you.

The way it works is by leveraging the existing aws client libraries to sign and (de)serialise parameters and responses, so you can do something like:

hx-ext="aws" hx-post="aws:ec2:us-east-1" aws-action="DescribeInstances"

and it will just work with any params such as form inputs or hx-vals etc

the reason i haven't posted it yet is i want to find a good way of mapping parameters since the aws api can have some notoriously complicated parameter formats

i'm very glad to hear you are finding it useful :)

Anyone using it with Phoenix and want to share their experience?

I would think in most cases someone using Phoenix would use LiveView for these sorts of dynamic updates instead of htmx.

I think HTMX makes alot of sense for content that is a bit static but still needs some update and interactivity. Im building a job site right now and using htmx for job postlistings, search etc. And liveview for logged in view of creating and managing job posts.

a lot of elixir devs dont even believe in liveview so that's a harder sell than a phoenix backend with some more popular framework on the frontend

> htmx has seen a surge in popularity

For those curious, here's some numbers for the last 6 weeks to put things into context:

- 4147 new stars

- 86 new contributors

- New contributors account for most of the commits and issues created which is a very strong sign of growth. Even in very popular projects, it is usually existing contributors that contribute most of the code.

https://devboard.gitsense.com/bigskysoftware/htmx

Full Disclosure: This is my tool

very cool tool!

we've had a new person come on the project who is focused on auditing PRs and getting the good ones in front of me, which helps a lot w/ getting new contributors in

> focused on auditing PRs

Something like this

https://reviews.gitsense.com/insights/github?q=pull-age%3A%3...

might help as well. Click on the different pills (Authors, Targets, Days open, ...) to get a different view of the contributions.

This is a great project, and reminds me a lot of where folks saw hypertext going many years ago.

I have read a little of the website and picked through many of the online examples. One thing I did notice is the preference to update client state (DOM rewrites) based on server HTTP request responses containing full-blown markup. Does the HTMX framework provide concessions for client-side-only triggers and client generated content?

The reason why I ask is that an advantage of the current crop of JS heavy-client frameworks is they offload as much work to the browser as possible. This can result in less resource use on the server end (e.g. data, CPU), which is a big deal for web-scale apps. Is HTMX able to meet these kinds of engineering goals or is the project intended to do something different entirely? I totally get that something like a Facebook client is not at all hypermedia oriented, but folks are going to draw the comparison anyway.

we do have a client-side template extension:

https://htmx.org/extensions/client-side-templates/

however, I would encourage most folks to use HTML as the network format: it typically isn't much more CPU to generate the equivalent HTML string that corresponds to a JSON string (sometimes even less, as with tables)

for pure client-side, htmx is largely hands off. We support an `hx-on` attribute to address the fact that HTML doesn't support general `on*` attributes, but that's it

it does, however, emit a large number of events that you can hook into to extend things:

https://htmx.org/reference/#events

And it plays well w/ scripting solutions like Alpine.js or, our our own scripting solution, _hyperscript: https://hyperscript.org

Another benefit of using HTML is ease of progressive enhancement. If the default behavior of the server is to render a full HTML page, anyone hitting that URL directly will get the full HTML from the server with no additional back-end work. Additionally, if JS is disabled in the browser, links still work as traditional links.

Thanks for the thoughtful reply, and the thoughtful architecture.

Generating some HTML instead of JSON isn't that much data/CPU. But doing all that in the browser might have a big impact on UX performance-wise.

This doesn't make sense. Can you elaborate? If it's not much work for the server, why would it be work for the browser?

Mobile phones have less powerful CPUs. Parsing large json objects and then building up a corresponding html structure may be more difficult than on the server (where you already have it loaded into memory anyway).

> Mobile phones have less powerful CPUs

True - but not by much

> Parsing large json objects and then building up a corresponding html structure may be more difficult than on the server

I doubt it. And you'd only be doing "large JSON objects" for a desktop web app, where CPU differences vs web servers are even smaller

> where you already have it loaded into memory anyway

Likely not true if implementation uses streaming semantics

> true - but not by much.

False. https://infrequently.org/2022/12/performance-baseline-2023/

I always see these claims but isn't network the more limiting factor?

Or do people study this while thinking about IoT which may use more limited resources while still relying on the internet?

Especially since a server has to handle multiple request concurrently, it doesn't seem to be remotely the same workload that a single device CPU would see anyway?

I can't speak to any kind of general principle here, but viewing any standard modern web page e.g. Twitter, Discord in a Web browser reliably takes more CPU and memory than running a late-game Factorio save.

I will allow that it is probably theoretically possible to do client-side rendering in a CPU-efficient way, but it sure isn't the standard.

I'm not the GP but I'd say it's not "just" doing that render-blocking work on a single thread on a potentially under-powered mobile device, it's also introducing significant latency to fetch, parse and execute the code that will render to the DOM.

JavaScript is single-threaded, so whatever CPU work is going on will compete with the UI responsiveness. Even mobile apps, which run a dedicated thread for each, probably won't do one single clean UI update in response to the server-response.

Nolan Lawson demonstrated using a web worker to perform virtual DOM updates in 2015. Sad it hasn't caught on in any of the major frameworks. https://pocketjavascript.com/blog/2015/11/23/introducing-pok...

It's not enough to be a novel approach. It also has to be demonstrably better from a performance standpoint, a developer experience standpoint, or arguably both.

Frameworks like SolidJS and Svelte simply got rid of the virtual DOM and reaped massive performance wins from it. I find it hard to believe that adding a worker and a virtual DOM back would end up making them faster. Quite the opposite in fact.

Then there's the dev experience. Would it be easier for a developer to work out what to do in a separate thread and post messages back into the UI thread? Seems like extra cognitive overhead to me.

Ideas are great. They move the state of the art forward. But if your idea doesn't comport with positive results from testing, it's not useful. Intriguing, to be sure, but not useful.

Very fair assessment, though not everyone is using, or will use, Svelte or Solid. Including people who are using htmx.

I meant to suggest that frameworks might be able to take this approach internally and make the DX transparent. I actually had a go at this using Mercury back in the day, but didn't have the motivation to finish it properly.

Congrats on the GitHub program! Very cool.

I just had a fresh read of the docs and htmx is refreshingly, gloriously simple--such a breath of fresh air. So natural, self-documenting, and well thought out. It _does_ feel like a natural extension of html.

To me, the only "missing" piece of htmx is a component model, but for anyone looking for that, htmx would pair amazingly well with Astro[1] which allows you to define and use html components without the runtime overhead of say Vue or React.

[1] http://astro.build

Also: I think every project / saas service should be required to have a footer haiku:

   javascript fatigue:
   longing for a hypertext
   already in hand

Not sure what you mean by html components. That's kind of missing the point of HTMX, no? Most backend frameworks like Django or templating engines like Jinja2 have the concept of blocks or fragments so its easy to render out component pieces to send back to the frontend. If you combine that with the OOB options in HTMX and/or the Hyperscript or Alpine libraries, then I'm not sure what you would gain by using Astro.

I mean, I just don’t think you should have to have Django for a simple website. Astro is an alternative to those backend frameworks. It’s a backend framework itself in many ways.

>a video by fireship dev (https://www.youtube.com/watch?v=r-GSGH2RxJs)

That's a great video explaining the core use-cases of htmx in 100 seconds. Would be great if all projects had such a thing! Htmx reminds me of tailwind in that you've created a set of attribute names and values that are picked up at runtime by a singular library. There's no front-end build required, which is a Very Big Deal for most devs who don't want (and shouldn't have to) to mess with npm and webpack. It looks like the "breaking point" for page size is something like a small SPA - when it gets to big, make another SPA.

Particularly for react/vue devs I think the thing they'll miss is the idea of a uniform, singular object representing global state that is rendered by a single function (defined hierarchically in your component codebase) into the UI. However, it must be accepted that this idea is very demanding in itself, resulting in lots of opinions and hurt feelings, and in addition comes with the weight of a front-end build (and all the confusing variation there).

I don't use it but I'm already a big fan. Congrats!

Are you also the writer of https://grugbrain.dev/?

> javascript developer get what deserved let grug be frank

yes :)

"danger, however, is agile shaman! many, many shiney rock lost to agile shaman!

whenever agile project fail, agile shaman say "you didn't do agile right!"

LOL

Huzzah! I laughed harder at that than anything in a long time.

:) i'm glad you found it funny and I hope useful as well, at least in parts

Yes. Funny because it was so true and full of hard won wisdom!

This is hilarious!

One minor thing. This is not an issue directly with htmx, but more on the backend. This always feels clumsy for me:

I land on the index page, and get the full site, then click on about page, and now htmx swaps the content for the about page. However if i refresh the url stays the same, but i now only get the content without the container.

I know this can be solved with checking for a htmx header, but i feel like "there must be a better way" like raymond httinger of python fame has said multiple times.

i typically have a middleware component that decides whether to render the "chrome" around a given response, so my controller methods aren't junked up with it

worth thinking more about though

This annoyed me a bit but it's not a big deal.

You make two skeleton templates: One for full documents, one that has nothing in it except the parts that change (say, the meta > title, the body > main and the body > header > nav parts) each wrapped in a hx-swap-oob.

In general, out of band swaps are really, really convenient for non-hierarchical layout relationships.

This can be solved by returning the full about page always, but swapping only the content part of in the index page by selecting which element to swap from the requested page. Htmx supports it

I've enjoyed using htmx and created a simple library in golang to help out. Here is an example app https://github.com/pyrossh/gromer/tree/master/_example

Legend. Well done for supporting, and for putting your money where your mouth is and laying down some code.

Gonna try this out!

> my favorite after htmx

That's interesting. I discovered Unpoly after HTMX (which I like) and decided to stay with Unpoly for a few reasons. Do you think hypermedia libraries will converge or do you think there is space for different interpretations ?

i definitely think there is room for multiple implementations

unpoly is higher level than htmx, with different design sensibilities and concepts like 'layers' (https://unpoly.com/up.layer) which is something that doesn't make sense from htmx's "just extend HTML" perspective

Exactly! I love the sweet spot that htmx hits; please don't change that!

:) i will not

Same path for me here. In particular, I found unpolys codebase to be of higher quality.

henning is an excellent programmer, I really admire him and his work

The htmx author is an excellent programmer, I really admire him and his work

:) thank you I appreciate you saying that

Just wanted to say thank you for what you do. I've long been a fan of HATEOAS and I'm very happy that there's finally a movement towards it and ecosystem growing. Also, the memes are unparalleled.

Awesome work! I love the simplicity of htmx. It’s one of those tools that makes me feel super productive.

Will there ever be a “htmx“ for building mobile apps?

there already is!

https://hyperview.org/

Adam Stepinski, the creator of Hypreview, built it after his experience with intercooler.js, the predecessor to htmx. It is a very interesting piece of technology and, through the magic of HATEOAS, allows you to update your mobile app instantly for all your users, without dealing with the mobile store!

There is an entire section on Hyperview, written by Adam, in part three of our book:

https://hypermedia.systems/book/contents/

Looks cool but it seems it requires React which makes it a lot more difficult to use than regular HTMX. Form the GitHub repo: “More importantly, the client is designed to be incorporated into an existing React Native project”

Well, you need some cross platform native UI toolkit that can dynamically render the hxml, and React native is hard to beat there.

Amazing! Gonna check it out. Thank you!

Not the point if your post but it's amazing how influential the Fireship team is! A true developer influencer, without being a cult of personality.

yeah, he was the one that really started the madness:

https://star-history.com/#bigskysoftware/htmx&bigskysoftware...

his video posted on july 7th

Do you think that at some point in the future, browsers could bundle in htmx or something similar, and that we could imagine web pages that have javascript disabled but with great interactivity due to htmx? This could perhaps be used as a security feature.

No need to wait for browsers. You can just whitelist htmx and block any other javascript.

Thank you for all your hard work put into htmx and indeed promoting hypermedia driven applications!

Since htmx works by way of custom attributes, can you write a bit about a11y recommendations for developers using htmx? It would seem to me that a lot of things that we get from using standard attributes are lost, and we’d need to do more nuts-and-bolts type work with regards to dom structure and aria attributes. Or does the htmx engine deal with this to generate relevant aria attributes etc.? I couldn’t find any references to this in the documentation.

Hi, I've been skimming over your book. There might be a typo under [1], where you write: "An HTTP response to this htmx-driven request might look something like this", but then the next figure's header is "JSON"

Also, I love your username!

[1] https://hypermedia.systems/hypermedia-reintroduction/#_hyper...

I love you. Thanks for making the web feel like the web again <3

:) i hope htmx is useful to you

I can’t believe you aren’t crediting your hilarious and pervasive ~~psyops~~ meme campaign

first rule of psyops...

As someone relatively new (few months in) to full-stack development, what can HTMX offer me? I've been semi interested since Prime mentioned it a handful of times, but I feel maybe I'm too new to fully understand what I gain from it. As soon as I'm finish with my current project, I'd like to check it out.

For reference, I'm currently working within the T3 Stack.

HTMX is just a convenient way of handling user-initiated UI updates AJAX calls (for whatever purpose). So instead of writing some JavaScript that looks for a specific element to attach an `onclick` event and subsequently makes an AJAX call then again searches for an element on the page to update with the result you can put some (very simple) HTMX code in the HTML directly and it'll handle that sort of thing automatically; "without having to think."

It's just a nice, convenient way of handling such things. The argument in the article is that "this is how HTML should've been from the start" because it lets you do some pretty sophisticated stuff just by adding some simple/intuitive attributes to the HTML.

So my apis need to return html specific to the page its called from with the data embedded? I guess my apis would need different endpoints that return json for other clients. And different endpoints for the exact same data if they need to be displayed differently? It just seems like a bad thing to couple. What about CSS? I guess you have to look at what the server returns to figure out how to select/style it.

I recognize thats how templates work but for some reason it seems weirder when applied to the element, rather than page level.

In there book, the authors specify that it is valid and normal to have additionnal endpoints for json. For exemple, Mastodon provide html endpoints as a interface for the user's browser, but also json endpoints for other clients (mobile app, cli tools, or others web app providing an alternative ui)

Interestingly enough, I have something planned that HTMX would be absolutely perfect for, can't wait to give it a try soon.

Simplicity. You don't have to become another React Andy and deal with all of the complexity that comes with it.

Loved the memes on the essays page. It has motivated me into checking the project more thoroughly

Stupid question, why doesn't htmx parse the response html and extract from that the relevant data out needs to fulfill the configuration? Feels a bit cumbersome to return the exact part of the response on server side, like the next page of the table, if it was requested with htmx, else return the full page.

This way htmx would be even easier to implement in any front-end.

Or maybe I am just crazy.

Edit: or is it this? https://htmx.org/docs/#selecting-content-to-swap

Rails does this with Turbo Frames [1]. When clicking a link that is contained in a <turbo-frame> element, the frame is automatically replaced if the response contains a frame with the same ID.

1: https://turbo.hotwired.dev/handbook/frames

This is how unpoly works (it receives the whole response and patches the page with the correct part of that response).

Oh that's cool!

It is that, yes.

I owe you a beer or 6. Let me know if I can pitch you a few bucks.

if you want to support htmx development you can do so via github sponsors:

https://github.com/sponsors/bigskysoftware?o=esb

but please don't feel the need to do so

How do you organize a backend for a htmx based frontend? Specifically getting templates that serve as reusable components, but also endpoints (there is some proliferation of endpoints which I remember from my days with ASP.NET MVC partials.

So you start by just re-sending the entire page but with content changed. Generally you'd use query parameters, like say you have a page with a table and you need to sort it. Add to your query parameters what order you want them in, re-render the whole page.

Then once you've got it figured out you just return the part of the template that you actually need to. Makes sense when you think of it as a progressive enhancement on a plain html page.

depends a lot on what your backend gives you

i agree it can spiral out of control if you try to do too much, e.g. a routes file that is just incomprehensible

i often end up reusing the same controller method to handle a few related routes, using pattern matching in the route declaration

i think also picking your battles and not getting too fiddly with screens that don't matter so much also helps a lot here

Does unpoly try to solve the same problem and how does their approach differ compared to htmx?

Curious to hear thoughts, I haven't done web in a while, so understanding your thoughts might help understanding the whole thing better.

What plans do you have for 2.0?

No major changes, it should be about 99% API compatible with htmx 1.x. Big things:

- Websocket & SSE support will be completely pulled out to extensions (already available in 1.0)

- We will drop IE support

- We may include a "morph" swap strategy based on idiomorph (https://github.com/bigskysoftware/idiomorph/)

- We will change a few defaults around how HTML is parsed, taking advantage of the removal of IE support

Hopefully transparent to the vast majority of htmx users.

Will HTMX 2.0 have a smaller bundle size since you are removing things? I don't think HTMX is too big or anything but I have a love tiny libraries.

And on that note do you think that a smaller striped down version of HTMX is feasible like petite-vue is for vue

I don't think the bundle size will shrink too much, especially if we include the morph-style merge, which is somewhat complicated

yes, I think you could do a stripped down htmx that doesn't support a lot of the stuff htmx does, particularly life cycle events and more elaborate swapping mechanism

for example, most response headers could be just done as the HX-Trigger response header + some client side scripting

history support and form-value gathering is likewise a source of complexity and code that could be omitted or done less completely

Sounds like reasonable places to strip out stuff while keeping the fundamental features. I think the history support would be important enough to keep though.

It might be a weird question,

But why are the websockets and SSE are migrating to extensions?

doing them right requires a fair bit of code and I'd like to keep the core AJAX-focused functionality as small as possible

Hello,

Maybe stupid question, but what are the downstream implications for folks like Vercel/Netlify/etc. who bet the farm on complex server rendered JS pipelines?

i don't think there are major implications: the web development world is still very react/javascript/JSON-centric

there is no reason that they can't tweak their services to be more hypermedia friendly if and when this approach becomes more popular

netlify (which offers free hosting for https://htmx.org, so is a sponsor of the project) is very HTML/hypermedia friendly as far as I can tell, and I don't have enough experience w/ vercel to say much other than a vague sense that they are extremely react-oriented

no reason that can't change as the market changes though: hypermedia pushes the main value locus of applications back on the server side and so server-side companies should like that

Fuck those hucksters...

https://twitter.com/rauchg/status/1619492334961569792

can you epxlain this to the <100 iq

Guillermo Rauch is the ceo of vercel. In this tweet, he's effectively saying that the bulk of what his company was built upon (SPAs) is bullshit (zero interest rate phenomenon is a reference to when financial interest rates are very low/zero, as they've been for many years, all sorts of things will seem great and successful because you can borrow money for free. When rates go up, only actually viable projects will survive - as we're seeing in the startup world now).

can htmx work for restful backend that requires client side rendering and routing? my understanding is that htmx only fits for server side rendering such as Django.

HTMX pulls text from your backend, so normally folks serve HTML snippets... but you could have a bit of js that takes JSON and turns it into HTML in the browser, and HTMX will pull the JSON (or any other text) into the browser, so you could still use it with a JSON api, if you wanted to

I use DRFs renderrers so my Django backend can render either JSON or HTML, so my API is still "restful", it just serves HTML to clients that request HTML like browsers with HTMX and JSON to other clients that request JSON.

interesting,using DRF for json and Django for html at the same time for browser and nonbroswer clients.

my use case is embedded systems that can typically do client side rendering in browsers, the only server side rendering I can afford is some simple lua or c/c++ mvc alike backend,Django is too 'fat' on resources. there are some of them but none that is great and actively maintained as far as I know.

This will just die like Web Components and RxJS after a few people write blog posts and do conference talks on it for hype, right?

Does this work with Web Assembly? Of course Web Assembly will die too since it can't do SEO.

In all seriousness though, what is the "core" reason to actually adopt this over the current approach?

> This will just die like Web Components

You mean "This just won't die"? Because it seems to me that Web Components are here to stay, especially since something like htmx boosts their functionality with absolutely minimal added cognitive load.

I feel that, pretty soon, the choices for a full-functioned web application that is easy to maintain with high development velocity is going to be:

1. Master HTMX and Web components in a day, and be productive

2. Spend a month learning React, and still get hit by all the footguns.

if you sincerely wish to understand how htmx is different than the current SPA-talking-to-a-JSON-API approach I would start here:

https://htmx.org/essays/hypermedia-driven-applications/

and then work through the rest of the essays:

https://htmx.org/essays/

Thank you, reading now - do genuinely want to know. I understand how my message came across, but I do intentionally reflect how many attempts there have been to change the paradigm so far.

Not a valid excuse, dude. You have every right to be skeptical or to avoid "bleeding edge" but to assume the whole thing is just a front to raise someone's speaking/blogging/social media profile, to buzz in from nowhere and start off by declaring that it's going to "die" is not the way to act if you "genuinely want to know."

Recursivedoubts has legitimately demonstrated he's not a one-trick pony (previously built intercooler, concurrently building hyperscript) and he deals with skeptics like yourself dozens of times every time an HTMX article gets posted on this site (which all seem to go to #1, if that serves as an indicator of the library's popularity). He handles himself with grace and patience and humor, far better than most of us would do.

You don't even state what your "current approach" happens to be in order for him, or anyone else, to provide you with a satisfactory answer.

no problem, i try not to take things personally online: i've said plenty of things that either were mean or came across as mean in my life, especially when I was younger

i think one of the strengths of htmx is that it isn't really trying to change the paradigm to something brand new, it is instead going back to the original web paradigm of hypermedia and asking how HTML could have advanced within that paradigm, in contrast with the SPA paradigm that replaced it

so less of a wild bet, with more known advantages and disadvantages

Reply on news.ycombinator.com