Great news.
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've been a HTMX fan "since before was cool"..
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.
I started with Perl in ā96 and have lived through what feels like everything ā PHP, jQuery, Drupal, Backbone, Node, Angular, ClojureScript, React, GraphQL, and NextJS. Htmx feels like a divergence from the trend, and is worth thinking about.
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.
Congratulations! I had a fun time making a little project with Htmx, though ultimately went with something else as I ended up heavily using a openlayers, and map libs are notoriously heavy with clientside javascript and Svelte ended up being a better tool for the job.
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.
I've a hard time taking htmx serious for building a modern web app/site. It makes is impossible to build features that users have come to expect:
* 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
The twists and turns my career has taken had me pretty much skip the whole front-end JavaScript framework wars so it's nice to see "plain old HTML" make an enhanced comeback.
I think we need an impressive "made with htmx" example that will trail blaze an new class of web experiences.
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 like the look of htmx at first but then when I want to do something where I would usually reach for JavaScript (vanilla or framework), such as a dropdown button, I inevitably consider hyperscript and then I see an example like "<div class="dropdown" _="on mouseenter toggle .is-active on me until mouseleave">" and decide I don't like having sentences in code like that and I move on to something else.
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.
I was helping with an application that used htmx and had two issues. Iām wondering if anybody had similar experience and if these issues are from misusing technology or maybe thereās some ongoing work to address them.
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?
Have loved HTMX for small projects so far, quite delightful.
Does anyone know what they have on the roadmap for 2.0? I'm curious what they are working towards.
HTMX reminds me of pjax which I really liked
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
This is great news. It's an unfortunate fact, but the validation of htmx simply by its inclusion in the GitHub OpenSource Accelerator may unstick some folks that were on the fence about its "legs"; not its utlity as such, but more about its safety for adoption. Nobody wants to be fired for selecting a library that may just go away. It's a very good library and it (and things like Turbo) are incredibly useful when developing canvases that slot into SFDC with the least amount of friction, allowing you to simplify interactions between SFDC and your back-end systems, where those systems themselves depend on SFDC data.
There are many applications where htmlx is objectively the best tool. But i really hate all the hype around it and people pushing it as react replacement.
For first-time-devs, configuring + understandings development environments is usually 10 times more daunting than "learning to code". With respect to Typescript, NPM, Webpack, React, transpiling, sourcemaps, broken IDE probably makes webdevnewbies quit before actual code syntax.
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.
Congrats. I will be very curious to see how this (and other companies that are built around an open source frontend/web library) work on monetizing themselves. Are there any successful businesses in that space?
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!".
A refreshing lists of startups, nothing related to HealthTech, Crypto, or AI.
Love Htmx but confident the hardest part of implementing will be convincing managers and designers to fully rethink how to approach UX and product in a way that privileges simplicity over presentation.
Can someone explain to me how state management is done in HTMX? I'm a native Django developer, and I really do like HTMX and wrote my own personal website with it (nothing special, a digital garden). But for my startup, I chose react, and it has pretty much become a SPA, where I need to keep track of so much state. Now, I would love to transition to HTMX, because I find Django a lot more ergonomic to work with. But I couldn't imagine not running into issue managing state.
I haven't written anything meant to be seen by the wider web since geocities/myspace and I don't know anything front end besides apache and PHP -- is this a return to roots?
(I don't like javascript and i think making websites sentient was a mistake)
Can anyone explain why Htmx is such a big deal? I really don't get their 'motivation' section on their landing page.
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?
Htmx's biggest upside is no pressure to use JS/TS on the backend.
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.
Great news! I'm not using the full feature set (e.g. hyperscript) but really like the general approach as opposed to usual suspects like react or svelte. One of my last projects runs just fine on htmx + 3-4 stimulusjs controllers for all interactivity
If you think htmx is cool, check out _hyperscript https://hyperscript.org/. Made by the same people, available with htmx I believe.
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 the framework that sends a server request to put a textfield into edit mode?
Nah sorry, not convinced.
Htmx strikes me as what we would've gotten earlier if we didn't throw XHTML and namespaces out with the bath water. Namespaced attributes, perhaps even tags, that already package and compose behavior seems like the natural outcome of browser spec writers reifying community conventions over time, and that kind of superimposing is precisely what XML facilitates.
Personally I dont like it. I think this will look as good as "everything in YAML" for CI/CD on an non-trivial codebase.
So who is using this/hotwire/unpoly and something like capacitor or maybe react native wrapper or turbo-iOS to make ānativeā mobile apps that are mostly just web apps? Any good war/success stories?
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ā¦
Awesome news. I have been a user since intercooler.js days and then moved to htmx.
Coming from the Unity world, I find frontend development on the web weird as hell.
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?
Itās amusing to read all the āitās great to just write htmlā comments here, in a thread about some company going through a startup accelerator.
Not that the comments are āwrongā but it feels slightly contradictory, in a way.
Sorry to sound mean but, what is the point of this?
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.
This is a great tool for backend devs.
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.
Also https://hyperscript.org/docs/ - works together with htmx.
I just love that you had the "guts" to start a project that sends HTML via ajax from the server at the height of JSON/JS/Framework Mania (hey it pays my bills).
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
A question, has anyone managed to integrate htmx with select2 or tom-select? I'm trying to create a remote livesearch, but I can't achieve it.
Not willing to be the party pooper, but isn't htmx's appeal the simplicity of it?
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?
I invented this over 10 years ago and called it Pebbles. Got some stars on GitHub. I convinced Memrise to use it in production and it helped them speed up dev a lot.
https://github.com/jperla/pebbles
Later when I worked at Facebook I saw that someone later made a similar library internally.
Very cool, congratulations!
Sidetopic: is there anything similar to GitHub Accelerator but for companies instead of individual developers?
Man. Love this. React for a purpose. Htmx and Hotwire for the rest. The debt years saved are for humanity.
This page made me realise I'm better off with just vanilla JS or jQuery: https://htmx.org/examples/update-other-content/
Solution 3 gave me a good laugh though.
I like the idea of htmx, it's more familiar with me since when I was involve on web developing, it was mostly jQuery, PHP, vanila JS, django. But I don't think I will change my current app from Vue to htmx, too many changes.
In all those SSR tools, my favorite is inertial.js, I think it combines the best of the both worlds. I am not sure why inertial wasn't getting more popularity though, anyone know why?
Curious if anyone familiar with Drupalās AJAX implementation (at least how it was in v5-7, I havenāt used Drupal v8 onwards) back in the day and has used this can offer a comparison?
A sense a lot of familiarity
I've skimmed the documentation and searched for the word server but I haven't been able to discover what is required on the server side. Can anyone point me in the right direction?
htmx just got me to do some front-end programming again after many years of false starts with Angular, React, Flutter, etc!
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!
How does HTMX work with Tailwind? If I return some HTML from my backend, then the Tailwind scanner won't have found the css selectors, so it won't be in the generated CSS.
What am I missing?
Have many open source projects have embraced htmx as their way of doing things? Or are there any non-IT projects that have adopted?
It would be interesting to see how itās been working out for folks.
It's time to bring jquery back in the limelight.
I don't want to bag on Htmx but if you're looking to just use vanilla HTML (seriously, no extra/custom attributes or weird syntax gotchas), please check out Joystick [1]. UI framework that's part of a full-stack framework that uses vanilla HTML, CSS, and JavaScript for building components.
it does not work well with the ever growing restful API backend services to me.
Before I break my neck completely. Htmx is still JS? No?
Isn't this how jQuery worked about 10 years ago?
What is github now?
is it a june news? the url is 2023-06-06
Shouldn't HTMX be a W3C proposal?
After reading the linked website for like 2 hours I still canāt tell if this is a joke or for realā¦
Am I the only one who looks at HTMx and thinks "this is like CICS all over again"?
off tipoc but DocuMenso = Meso means retarded in spanish.
Can somebody explain to me how I am supposed to use this?
It's so odd to live long enough and see the steady pipeline of "look at this much simpler way of doing web apps, just write HTML, not like the previous complex way" projects, which then turn into the previous complex way as the eyes turn towards the next "simple way of doing web apps, just write HTML...".
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.
.
> 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 javascript[dead]
[dead]
[flagged]
[flagged]
React is JS in html.
Htmx is JS in string.
Goodluck stringify :))
In recent years, I have not seen another tool that is so inflated. The attention it can garner for a tool where all it does is do simple things by adding attributes to html elements is really weird. Anyway, we need to act as if adding an attribute to the button and changing the value written in it is a very big need. Great job congratulations.
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