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 ?

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

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

   javascript fatigue:
   longing for a hypertext
   already in hand

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

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

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

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

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/

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.

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

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

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

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

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.

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.

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.

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

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.

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

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!

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

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

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.

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?

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

and then work through the rest of the essays:

https://htmx.org/essays/

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.

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

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

Or

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

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

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.

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

his video posted on july 7th

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.

worth thinking more about though

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.

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

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.

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

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?

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

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

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

LOL

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

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

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

but please don't feel the need to do so

Also, I love your username!

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

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.

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.

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

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.