by jjdeveloper on 8/16/23, 10:19 AM with 487 comments
by recursivedoubts on 8/16/23, 1:29 PM
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
by silver-arrow on 8/16/23, 12:58 PM
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.
by PedroBatista on 8/16/23, 11:46 AM
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.
by wildermuthn on 8/16/23, 3:19 PM
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.
by chainwax on 8/16/23, 10:51 AM
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.
by DrDroop on 8/16/23, 12:37 PM
* 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
by mikece on 8/16/23, 11:24 AM
by nologic01 on 8/16/23, 11:32 AM
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
by 12907835202 on 8/17/23, 5:08 AM
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.
by dhucerbin on 8/16/23, 9:35 PM
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?
by montenegrohugo on 8/16/23, 10:43 AM
Does anyone know what they have on the roadmap for 2.0? I'm curious what they are working towards.
by samsquire on 8/16/23, 12:40 PM
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
by kayo_20211030 on 8/16/23, 2:14 PM
by fleetfox on 8/16/23, 12:45 PM
by jjkeddo199 on 8/16/23, 3:48 PM
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.
by qbasic_forever on 8/16/23, 12:53 PM
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!".
by jonny_eh on 8/16/23, 11:10 AM
by michaelchisari on 8/16/23, 9:52 PM
by djangpy on 8/17/23, 1:37 AM
by dontupvoteme on 8/16/23, 1:16 PM
(I don't like javascript and i think making websites sentient was a mistake)
by martijn_himself on 8/16/23, 3:28 PM
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?
by strangescript on 8/16/23, 7:56 PM
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.
by can3p on 8/16/23, 1:42 PM
by ilaksh on 8/16/23, 1:04 PM
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.
by jdthedisciple on 8/16/23, 12:55 PM
Nah sorry, not convinced.
by imbnwa on 8/16/23, 2:05 PM
by papruapap on 8/16/23, 11:46 AM
by dchuk on 8/16/23, 2:45 PM
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…
by zenith035 on 8/16/23, 2:53 PM
by norwalkbear on 8/16/23, 1:08 PM
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?
by duxup on 8/16/23, 12:10 PM
Not that the comments are “wrong” but it feels slightly contradictory, in a way.
by varispeed on 8/16/23, 11:36 AM
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.
by 0xblinq on 8/17/23, 12:51 AM
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.
by sriku on 8/16/23, 1:53 PM
by rawoke083600 on 8/17/23, 1:36 AM
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
by jray on 8/16/23, 12:31 PM
by jgimenez on 8/19/23, 2:06 PM
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?
by ljlolel on 8/17/23, 4:56 AM
https://github.com/jperla/pebbles
Later when I worked at Facebook I saw that someone later made a similar library internally.
by basiskarten on 8/16/23, 11:16 AM
by wslh on 8/16/23, 11:45 AM
by RileyJames on 8/16/23, 3:39 PM
by nprateem on 8/16/23, 11:13 AM
Solution 3 gave me a good laugh though.
by vietvu on 8/17/23, 6:28 AM
by mnming on 8/17/23, 11:00 AM
by nraf on 8/16/23, 10:53 PM
A sense a lot of familiarity
by kwhitefoot on 8/16/23, 11:48 AM
by loafoe on 8/17/23, 9:06 PM
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!
by aembleton on 8/16/23, 2:57 PM
What am I missing?
by WhitneyLand on 8/16/23, 2:47 PM
It would be interesting to see how it’s been working out for folks.
by rs_rs_rs_rs_rs on 8/16/23, 12:32 PM
by rglover on 8/16/23, 3:17 PM
by synergy20 on 8/16/23, 11:53 AM
by AtNightWeCode on 8/16/23, 8:58 PM
by tempaway47811 on 8/16/23, 7:49 PM
by dontupvoteme on 8/16/23, 1:05 PM
by esseti on 8/16/23, 12:22 PM
by als0 on 8/16/23, 9:43 PM
by justmedep on 8/16/23, 1:43 PM
by mikece on 8/16/23, 11:23 AM
by guluarte on 8/17/23, 12:02 AM
by jokoon on 8/16/23, 9:41 PM
by 3cats-in-a-coat on 8/16/23, 11:21 AM
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.
by pjs_ on 8/16/23, 10:15 PM
> 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 javascriptby revskill on 8/16/23, 11:47 AM
Htmx is JS in string.
Goodluck stringify :))
by pictur on 8/16/23, 2:06 PM