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:
and in a book I authored with a few other writers that we recently released on hypermedia, htmx and a mobile hypermedia called Hyperview:
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
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.
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.
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
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
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.
javascript fatigue:
longing for a hypertext
already in handThat'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!
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.
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
Will there ever be a “htmx“ for building mobile apps?
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://star-history.com/#bigskysoftware/htmx&bigskysoftware...
his video posted on july 7th
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.
Also, I love your username!
[1] https://hypermedia.systems/hypermedia-reintroduction/#_hyper...
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.
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
https://github.com/sponsors/bigskysoftware?o=esb
but please don't feel the need to do so
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.
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
Curious to hear thoughts, I haven't done web in a while, so understanding your thoughts might help understanding the whole thing better.
- 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.
But why are the websockets and SSE are migrating to extensions?
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?
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
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.
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?
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.
https://htmx.org/essays/hypermedia-driven-applications/
and then work through the rest of the essays:
I have had good success and a rewarding experience using htmx the past year. It has been so great in tandem with Clojure using hiccup for SSR.
Once htmx clicks for you, you are almost left stunned by how simple and flexible it is. You can't believe that this isn't how HTML evolved to as a hypermedia. It becomes very obvious that this is how web development should have evolved. I hope someday that what htmx is doing through javascript becomes baked right into HTML and the browser clients.
If you are mistakenly believing it is just some derivative of Angular or you are not grasping the significance of its advancement of the architecture of hypermedia, please do yourself a favor and read the excellent essays on their site; you will then truly understand what REST is and what the importance of real HATEOAS means: https://htmx.org/essays/
They also have a free book here: https://hypermedia.systems/
We made a costly wrong turn 10 -15 years ago by attempting to rebuild thick clients on the web with a JSON API architecture instead of expanding and enriching the new and powerful idea of the early web: hypermedia.
I have to disagree with that. I’m happy htmx exists and that it works for many but in my professional life I've found few cases where it's the best choice. And that’s fine! It’s a wonderful thing that the web has been able to grow in so many diverse ways, there should be no one way it “should have evolved”.
IMO this is the biggest mistake in web dev in the last decade or so: that there should be One Right Way. No matter if you’re making the next Gmail or if you’re making a static blog the cargo cult of an industry tells you it should all be done the same way when common sense would tell you that’s not the case at all.
For one, htmx is not a full solution to avoid JS. It's excellent for the parts that are AJAX/CRUD, which certainly covers a lot of ground. You still need something more if you're doing stuff that doesn't fit here like interactive visualizations and many other use cases. However, it integrates very well with other lightweight libraries.
Secondly, htmx is great if you're developing full-stack (like GP). Meaning you touch every part of a site from the data model to coordinating messages to the frontend etc. If you want a much clearer separation between frontend and backend of a site, especially in terms of contributors/teams, then it might not be the right tool. IMO there are plenty of good reasons to do either.
Third, and this is a bit of a combination of the first two points, if you directly fetch data from a third party, say a JSON API, then htmx doesn't help you at all.
So really as you said, there is no one right way. For me it has been working very well though. People should look into it for sure though. There's an opportunity to combine htmx with orthogonal libraries that do the dynamic parts like lit etc.
That is why I wish HTMX to be merged into HTML5 spec. For something like 98%+ of the web it will be good enough. You then have a small JS library for the other 1.9%.
The 0.1% left is just pure JS Web Apps.
If I had to pick an “Angular-1-like” framework, I would pick the one that clearly documents it’s boundaries and provides a clear way to use a mature SPA framework when there is a need to cross those boundaries. If anyone is aware of such framework, please share.
as much as possible, htmx tries to take HTML to its logical conclusion (from my perspective) as a hypermedia, rather than imposing other ideas on top of it
What kind of app are you working on?
Yeah, so moving to htmx has allowed us to jettison ClojureScript which just entailed too many parts. As a matter of fact, before going more htmx with our projects, we had moved away from ClojureScript to React directly.
For instance, inside an HTMX application, I just coded up a plain ordinary <script> (no framework, no build system) that displays a count of how many characters are in a text field and also disables or enables a submit button according to that size. It's 9 lines of code plus an attribute on the input. It might be less if I did it in
Immediately it faces the problem that there are two paths: (1) the initial setting of the length display (the field is pre-populated with text, I ended up setting it in the SSR) and (2) what happens when the text content changes.
If you use signals or hooks or useEvent or lifecycle methods or whatever you always see a certain amount of awkwardness that stems from the above.
Note I could have done the above with "pure HTMX" in that I could have had the event handler trigger a server round trip that repaints the text field and the submit button, it wouldn't be as bad as it sounds in performance, but boy it seems like a waste.
I've built applications that were a lot like Figma, Photoshop, or Eclipse, where the user could update some data and it could have very arbitrary effects on the UI because the user is able to add and remove many different UI elements and in a case like that you need some system that can manage dependencies at runtime.
React has revolutionized how people build widget-based frameworks, there is never going to be anything like Tk, Cocoa, GTK, WPF, Spring, JavaFX ever again, or if it is it is going to be influenced by React. There's the awkward fact that React is overkill for the typical form processing and e-Publishing applications people write with it but it is not up to the task (without an additional state management frameworm) of applications like Figma.
Personally I'd like to see a mostly declarative form processing framework with a sprinkle of scripting: before there was the iPhone there was WAP
https://en.wikipedia.org/wiki/Wireless_Application_Protocol
which had a way to send multipart forms to the client. Something like that designed to work with a software factory
https://www.amazon.com/Software-Factories-Assembling-Applica...
(one of the most visionary books of all time... the authors built an enterprise software development framework for Microsoft that was nowhere near as cool as their vision)
or a "no-code" app builder could be great.
I'm still trying to get my head around websockets. I've built some small demos that are awesome, like a program that controls the volume of my smart speakers and has the sliders move when I change the volume with the remote control. I really wish my RSS reader could update my "favorites" window as soon as I add a favorite in another window, but doing that efficiently requires answering questions all the way from the front end to the back end to the database. I'll probably find a half-baked way to do it but it's sad that I'm settling on a web application to have the limitations web applications had 15 years ago.
Very happy for the recent attention and "success". Also enjoying the shitposting and backlash mostly from the front-end crowd who believe the Web was invented in 2013 and they "made that city". :)
I'm biased since the time Backbone.js came around, I understood part of the pain but was moderately skeptical, fast forward to React with the young energetic bros building dead simple 5 page websites with a Rube Goldberg setup of front-end frameworks, I've cashed out my tech chips and never touched those things.
We unfortunately weren't able to win hearts and minds around these concepts in the long run, and blog driven development (a.k.a. cargo culting) replaced our efforts. I feel somewhat redeemed now that HTMX seems to increase in popularity, it's nice to see that we weren't alone in thinking along these concepts.
Of course, if the concepts were strong that implies my execution wasn't, so maybe I shouldn't feel so good about it after all... :o)
A good idea or a good product are never enough. You have to sell the product in order to have it be successful.
In your situation, you were at a bank, so your TAM was roughly 1 enterprise (or maybe a dozen, tops, if divisions had federated or siloed tech). And your 1-to-a-handful of potential customers were probably of the large and difficult to change variety. That's a huge constraint, and not landing it there doesn't mean your idea was bad, it just means you weren't successful in selling it and I'm going to tell you that you probably _couldn't_ have been successful in selling it where you were, when you were there. I worked for your lazy cousins at the same time - big insurance - and had the same issues selling my own ideas internally, if that makes you feel any better.
HTMX has no such constraints. It's a decade later and the TAM is more or less everyone doing or preferring to do SSR. The same/similar good idea, but different place and time.
Ironic considering what the OP attributes to HTMX's current popularity.
Like angular, react got the huge initial boost in popularity because of the brand behind it.
I hear that you and your band have sold your guitars and bought turntables.
I hear you rewrote your http endpoints to return JSON because that was REST.
I hear that you and your band have sold your turntables and bought guitars.
I hear you rewrote your http endpoints to return templated html fragments because that was HATEOAS.
I'm losing (regaining/losing/regaining) my edge
I'm pitching a mobile app built in Unity and a custom ruby backend on digital ocean.
They questioned my tech choices on a working app! Apparently if you want VC money you must use their approved tech stacks.
But Backbone was a bit sloppy, not very enterprisey, until Angular came around.
Anyway, this string of web applications became popular (in my world) because it meant that we could separate back-end from front-end, and have one back-end (usually REST/JSON) fueling mobile and web clients separately. That was it, that was why we built SPA's, but by now that has been forgotten again.
And in my world, it made sense because the apps were behind a login. But then They wanted to make SPA's facing the internet, for things like webshops. And I get that too; I've made a few websites using Gatsby, they're crazy fast for navigating AND still indexed by search engines.
Anyway, in some cases it did get more and more complicated, then with server-side React and the like. I never had to touch that, thankfully.
on the other hand, my hope is that eventually htmx (and, more generally, hypermedia) is accepted as a tool, a useful too, but just a tool, even by the front-end folks who haven't thought very much about hypermedia in a while
i don't see the two approaches as mutually exclusive and agree w/ Rich Harris' concept of 'Transitional' web applications that mix the two approaches. I would just draw the line where you abandon hypermedia for a more elaborate client side approach in a different place than him.
I certainly do.
I went to a series of JavaScript conferences and React is extremely diverse.
Good to see diversity all around, I just wish there also would be diversity of thought and it comes to building web pages. But I guess that would lead to people admitting ~80% of all the stuff they build does not require React or equivalent js frameworks and that would be both an ego and economic/résumé problem..
Htmx asks us a good question: “does the complexity of your work reside essentially on the server or essentially on the client?”
The complexity for the vast majority of websites resides essentially on the server. Most of us are not building Figmas and Google Sheets. Most websites, even if heavily interactive, are just CRUD apps with pleasant interfaces. Frameworks like NextJS attempt to rectify the problem of overly complex clients by moving React to the server, but this often magnifies complexity rather than minimizing it.
Wouldn’t it make sense to remove React from the stack? For complex clients, skip the DOM and JS with canvas and compiled web assembly. For complex servers, use some form of server-driven granular updates to the DOM.
The problem I see with this approach is that although most complexity reside on the server for most websites, there are almost always a few high-complexity task that needs to reside on the client — image editing, real-time sorting/filtering/calculation, drag-touch gestures, etc.
A hybrid approach is necessary. It isn’t good enough to allow compatibility. Although htmx and React can be used on the same web page, they need to be kept in isolation. But I’m not looking for isolation; I’m looking for fundamental integration.
My ideal framework would allow for reactive granular updates to the DOM while also being tightly integrated with compiled web assembly powering complex client operations. I’d write all my code in a powerful language rather than JavaScript. My debugger would operate on both server and client because the difference between the two has disappeared. It would be true full-stack development — a single-stack application (SSA)
Clojure + ClojureScript comes close to being an SSA, but only superficially.
If ever there was a killer framework for Common Lisp, I think an SSA fits the bill.
> A hybrid approach is necessary.
This is "the islands" approach, as advocated by Astro, for example:
https://docs.astro.build/en/concepts/islands/
This approach is consistent with htmx and friends, and we're using it on an htmx project with simple vanilla JS for the pieces of interactivity. For small and medium projects and a small team, this can be enough, and it's a breath of fresh air to be able open up dev tools, point to part of a page, and understand everything there just by looking at the html and small snips of JS.
Blazor United promises this hybrid approach. You code in C# in one way regardless of server or client. On first page load it renders everything from server-side. Then webassembly gradually takes over and it starts loading C# code on the client to speed up UI interactions that don't require server side data.
It works well but their current challenge is reducing webassembly files size which is about multiple MBs.
https://visualstudiomagazine.com/articles/2023/04/20/blazor-...
God hear your words
I plan on using it again for a future Golang project and look forward to following it's development. If you're in need of a simple/medium complex front end for your app, and _especially_ if you're already using template fragments[0], I really recommend giving HTMX a shot. It's pretty fun to work with coming from Javascriptland.
Also, the guy who runs their Twitter account[1] is hilarious.
Could I have made it work? Yes
Could I have just made the map it's own self-sufficient component and left the rest of the app as is? Also yes
Did I do these things? No. As one tends to do, I just nuked it and started over
* Faceted search with configurable filters, like filter date on before, between or after, but only show the filter if the user wants it.
* Configure result view with different columns or even different views like maps or drawing something on a canvas like charts. You can maybe do some of this stuff with htmx but at some point you'll just need the json.
Even Angular can do this, and with something like SolidJS it is actually a pleasant thing to do.
A JSON api can be re-used by other apps while htmx feels like someone reinvented Thymeleaf
For the second part you probably go with your own javascript or get away with hyperscript
The point about a JSON API is a good point and if you need a public API then you should probably factor that into your decision making but not everything has this constraint.
> The point about a JSON API is a good point
The HTMX-specifc API applies a template/transform over the model and returns HTML instead. If one thinks of hypertext as another serialization target, it's easy to see how one would easily be able to serve both JSON for pure APIs and hypertext for HTMX.
So for such things I would give the user a very broad set of data via htmx and then allow for further (realtime) filtering via JS.
If I want them to be able to search through data that isn't displayed initially I just deliver it with a hidden css class and remove that class if it is searched for.
Htmx, like any technology, is very well suited for a certain set of problems — iif you don't try to make it do tricks it is not good at, you should be fine.
something like this is complex enough to require some front end scripting, which I am not opposed to:
This is a regression on graceful degradation.
It takes careful but not extraordinate thinking to think of ways to get consistent results with or without JavaScript turned on. Indeed, when a visitor hits a site for the first time they get the full response so everything for a graceful degradation should already be there to use. If I can figure it out, I'm sure big CS brains can.
People have typecast htmx as something to use for simple use cases that dont "warrant" getting out the serious guns. There is something to that, but it is limiting. Htmx and related 'back-to-the-server' approaches are a distinct category that could have been explored much earlier but for various reasons isnt
I think you misunderstand HTMX. It’s the revival of an old class of apps in a backend agnostic way. It’s not doing anything new, or anything that warrants a “new class of apps.” It’s a way to build hypermedia (read: content) focused sites. Classic sites like shopping catalogs, forums, admin front ends, blogs, etc.
It’s just jquery/liveview/turbolinks, but backend agnostic and without needing you to maintain much (or any) frontend js logic.
Once you need heavy interactivity (think google docs or figma) it stops providing much benefit.
I mention C# in that ASP.Net MVC + Razor seems like a very clean match to the HTMX paradigm.
Not affiliated with them in any way, but it's made with htmx and some JS for more complex features
As for "new class of web experiences", given that htmx explicitly aims to expand upon what is considered the Old Good approach, not sure if it can provide that
Maybe I should give htmx a go without hyperscript or maybe I should give hyperscript more time. But on anything that I'm expecting to be maintaining for years it's just too unfamiliar and I don't want to be stuck with it if I wind up never using it again.
1. A lot of custom middleware in controllers to decide if endpoint should return HTML for whole page or only fragment that htmx needs. On the side of htmx that sounds simple but it is something that probably every project using htmx have to reinvent.
2. Bookkeeping around `hx-trigger`. If UI is getting complicated, many elements need to react to external changes. Instead of reading some state and hope that framework will schedule updates, I have to manage a list of events to react by hand.
Anybody had similar impression?
Does anyone know what they have on the roadmap for 2.0? I'm curious what they are working towards.
I did a lot of sideprojects in Knockout and one large one in Angularjs 1.
I feel all the frontend frameworks need to talk about what they see the problems are and decide how to fix them.
I would like some solid foundations and avoidance of common pain and gotchas of scale and complexity.
My old sideprojects are broken because I didn't fix library versions. My JSBIN sqlite file with my knockout projects in is also in an unknown version of JSBIN which latest JSBIN doesn't work with.
The speed that frontend development moves has broken lots of my code.
EDIT: Screenshots of my old experiments: https://github.com/samsquire/interface-experiments
In my dream world, HTMX could become part of the HTML6 spec, and beginners could spend more time dipping their toes in the water testing their .html files in Chrome before they face getting gobsmacked by the greater JS ecosystem.
I worry it will be truly challenging without a big compromise to morals/openness/etc. I kind of wonder if stuff like htmx should just be funded with a big grant so it never needs to worry about selling out users for profits and operating income. Or at the very least that it learns to run extremely lean, to not chase expensive fads, and to build itself into something that can survive off a modest "please donate/buy some stickers/tshirts or my book" income stream. I hope we don't see the day that suddenly there's no download link on their site and it's replaced with a, "please contact our sales team for a demo!".
i have a day job (a couple) so there is no financial pressure around it
i hope that it will be a long term public asset for developers
(I don't like javascript and i think making websites sentient was a mistake)
I mean, for example, the first motivation it lists is 'Why should only <a> and <form> be able to make HTTP requests?', why is that an issue? And 'Why should you only be able to replace the entire screen?', I mean that hasn't been an issue since XMLHttpRequest or am I missing something?
I wouldn’t call it an issue, but maybe you would like individual elements to fetch their own data. Sure you can do the same thing with JS in the browser (calling fetch or XMLHttpRequest), but htmx lets one do it with attributes on tags.
The “replace the entire screen” business is a jab at React-like frameworks. Although they all claim to update only the DOM parts that change, it’s very easy for a codebase to [accidentally] force a full page redraw.
I can see the appeal, it's what ASP.Net WebForms probably should have been. And for that matter could probably cleanly fit with ASP.Net MVC and Razor views.
So many stories start with "I used htmx with (rust|go|ocaml|django|etc) and had good results".
Feels hard to not use JS/TS on the backend if you are already using it on the frontend (unless you have a specific need node can't fit). Why intentionally use two different languages, yadda yadda, etc, if you don't have too.
Its refreshing.
After seeing _hyperscript, it looks like they may have invented that first, and a lot of people's heads exploded, so they decided to try to make a "gateway drug" to sneakily introduce _hyperscript, and came up with htmx.
htmx is version 2 of intercoolerjs:
which had a proto-scripting language in it, the `ic-action` attribute:
https://intercoolerjs.org/attributes/ic-action
i dropped that attribute (along w/ the jQuery dependency) when I created htmx, but I felt there was some merit to the idea of a lightweight scripting language that abstracted away async behavior. Once htmx had stabilized I revisited the idea, remembered my experience w/ HyperTalk as a young programmer, and decided to take a shot at that, but for the browser.
I'm very happy with how it worked out, although I expect it will always be niche when compared with htmx, which has much broader applicability and isn't as insane looking. :)
Nah sorry, not convinced.
I have to assume that just like most web apps don’t need aggressive SPA front ends, many mobile apps fall in the same boat…
When accounting for the limited amount of time and mental load people have, wouldn't the best bang for your buck be doing react/vue/js?
HTMX is more limited, but also _radically_ simpler to modern frontend development.
Not that the comments are “wrong” but it feels slightly contradictory, in a way.
It's not a startup accelerator - it's a part of GitHub's efforts to support open source projects with funding and mentorship.
I've gone to the home page it poorly explains what it is and doesn't say why would you want to use something like this.
Seems like another distraction.
Seems clear to me but I've been watching this project grow for a few years now. If you read the brief introduction, motivation, and quick start on the homepage what do you think the project does?
> why would you want to use something like this
I would agree that part wasn't clear to me either, at least not right away. When compared to something like a SPA the state has to persist on the server while an ephemeral state exists on the client. With HTMX the state only needs to exist on the server. If this sounds like the MPAs of yesteryear, it is. You render the HTML using the frameworks/tools/languages you fancy. HTMX provides custom attributes you can use to update content within a page without having to reload the entire page.
There's a stable implementation for PHP too.
No frontend developer that cares about the details, the UX and has to deal with the evolution and maintenance of any non trivial UI would use this.
But as I said, this is great for everyone that just wants to make a frontend for their Go/Django/Clojure/etc backend. You’ll notice this pattern in most positive comments you see here.
Also, as someone who also used these kind of tools, I still prefer Unpoly over it. Sadly it didn’t get as much marketing.
Project is really cool, I'm itching to use it in the right side project.
Congrats on shipping !
Oh yea the https://htmx.org/essays as the author mentioned is also fantastic. Their twitter is "fun" :D
I would expect it to be "done", or maybe could be refined with a couple more little things, but definitely not needing full-time dedication on making a version 2.0 or adding new features.
Aren't we going to end up with a new react?
the 2.0 would drop IE support, remove the older SSE and WebSocket support, and switch a couple of defaults (e.g, using template wrapping for parsing partial content, which handles troublesome elements like table rows better, but isn't available in IE) so it would be a breaking change (not for most folks, but still, breaking for some) which I only like to do w/ major versions.
we may have one major addition: a morph swap based on idiomorph:
https://github.com/bigskysoftware/idiomorph/
i'm on the fence on that one: it is currently available as an extension and maybe doesn't belong in the core, still thinking about it
so, in comparison with most libraries, 2.0 is going to be very minor
https://github.com/jperla/pebbles
Later when I worked at Facebook I saw that someone later made a similar library internally.
Solution 3 gave me a good laugh though.
This is a complete non-issue in unpoly as you can have multiple targets:
<a href="/posts/5" up-target=".content, .unread-count">Read post</a>
HTMX gets a lot of attention, but I think it's not the best option in its field.
I've done tabbed UIs that worked like HTMX. But instead of trying to do div surgery it replaced the entire tab. It was like 20 lines of JS and a few lines in Rails to render without a layout based on a URL query param.
When we're talking dozens of KBs of HTML for a tab it's not the extra complexity to try and slim that down.
A sense a lot of familiarity
Very refreshing and extremely productive! Goland, browser window and Bard for code snippets and from idea to first working flow in less than an hour!
With other frameworks I would first have to struggle for a day or two setting up the tooling and understand all of the new concepts and constructs. Or worse, learn completely new language (Flutter, Typescript)
Thanks @recursivedoubts and team!
What am I missing?
It would be interesting to see how it’s been working out for folks.
Your frontend makes a request to your server, the expectation is that will respond with html.
If you have other services you need to bring in to the mix that responds with JSON then make the request to them from your server, have that parse the JSON in to HTML (most likely some kind of templating system like handlebars) and then send that back to your frontend as html for htmx to handle.
Or am I missing something?
[0] https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...
the original version of htmx was intercooler.js:
released in 2013, and that version depended on jQuery
So this is ... marketing?
Angular and React started this way on the frontend, while ASP and PHP started this way on the backend (of course eventually they all grow "full-stack" solutions).
EDIT: And how could I forget, Tailwind, whose tagline reads: "Rapidly build modern websites without ever leaving your HTML"
The fact your HTML barely reads like HTML after Tailwind, and reads more like your file is corrupted is I guess not mentioned in the tagline.
Not my experience for the record. I use Tailwind in my side project, and it is exactly as convenient as it sounds to write my styles directly into HTML rather than think of a class name, add it in HTML, switch to the proper CSS file (or create it if it doesn't exist and make sure it's part of the build step), forget what name I had decided on, check the original HTML to remember the name, then go back to the CSS file and write the class name and then finally within that block add my style.
Circa 2007 or so it seemed a to be a huge mistake because it didn’t play well with the so-called “model-view-controller” paradigm where, most importantly, the request handler could decide which view to render. (e.g. you fill out a form and if you mad a mistake it redraws the form with an error message, otherwise it might render one of several different forms depending on what you filled out on the first form.)
He thing about HTMX is that it really wants support on the server side. For instance, you might have a <select> that gets drawn as part of an HTML page or that gets updated with new <option>(s) via HTMX when you push a button. Similarly you might have a form that can be rendered as the only form on a page or that can be rendered as a modal dialog that is pulled from the server when you open the modal (as opposed to unhiding it.). Either way the code that draws the HTML fragment (both the template and any database fetching/thinking) has to be runnable in more than one context. (Modal dialogs are so fun to implement with HTMX.)
It’s something you can do in a situational way or that you could have a framework to help with, but it is part of the HTMX puzzle.
So many web revolutions touted as "don't use Java and all that big stack, instead use our SUPER SIMPLE stack called:"
Rails: wow did rails eventually encompass a massive stack of dizzying extensions options and frameworks.
React: I laughed when I saw basically a full rewrite of various Java unit testing frameworks in javascript.
But HTMX seems to get love that angular/react/etc never got from a HN front page perspective.
I take a dim view of AI so far, but one thing it could be fantastic for is "take this basic HTML application and write it in framework X" so I can finally see a good comparision.
The web framework landscape has needed a "reference web app" since the year 2000 where frameworks could demonstrate their way of doing rendering, layout, validation, forms, routing, error handling, data binding / data retrieval, tables/grids, media. As in your web framework isn't even close to prime time unless you can show WHY it is novel or useful.
There are a ton of ways to solve this issue but most people just look at tailwind on the surface and go shitpost about it on social media.
Its the equivalent of saying "I wrote this 2k line program in one file, its so bad and disorganized <insert language here> is bad!"
> looking for a nice framework for website
> ask dev if their framework is hypermedia or javascript
> doesn't understand, pull out long essay on hypermedia as the engine of application state
> dev laughs and says "its a good framework sir"
> check github
> its javascriptHtmx is JS in string.
Goodluck stringify :))
It’s extending html to make the most of http by adding some simple attributes.
Like all great things - the building blocks are simple, but the possibilities of what you can build with them is vast.
I think this is really well dealt with in the “opportunities” to extend html in this chapter of the Hypermedia Systems book: https://hypermedia.systems/extending-html-as-hypermedia/