45 ms·

Htmx Is the Future

836 points by quii 3y ago

nologic01 3y ago
Could you use htmx (or an extension?) to dynamically update SVG fragments? I.e., replicate the functionality of d3.js on the server side?
pier25 3y ago
Good luck with latency though for anything slightly interactive.
optymizer 3y ago
I remember fetching HTML from the server with AJAX and updating innerHTML before it was called AJAX. Is HTMX repackaging that or am I missing some exciting breakthrough here?
- mlboss 3y ago
  It is doing the same. Just makes cleaner and easier.
- sourcecodeplz 3y ago
  It is like that yes but more abstract because it uses some special HTML tags to make the JS calls. There is a big downside though: weak error handling. It just assumes that your call will get a response.
  - bccdee 3y ago
    No, there're error events[1] which can be handled with a little bit of client-side scripting. [1]: https://htmx.org/events/#htmx:timeout https://htmx.org/events/#htmx:timeout
hashworks 3y ago
> It is very easy to support users who do not wish to, or cannot use JavaScript I don't get this. To use htmx one has to load 14 KB of gzipped JS. How does this make it easy to support clients that don't support JS?
- akpa1 3y ago
  Because HTMX is built around graceful fallbacks to standard features. For example, you can apply HTMX to a standard anchor tag and be able to tell if a request has come from HTMX on the server to tailor the response. Then, if the client supports HTMX, it'll prevent the default action and swap the content out, otherwise it'd do exactly what an anchor normally does. The same goes for form elements. If you're just a little bit careful about how you use HTMX, it gracefully falls back to standard behaviour very easily.
silver-arrow 3y ago
htmx has provided the greatest satisfaction and production of my 30-year programming career. After a year of constant development experience with it, I am confident that this is the proper method of building web applications. It truly is how HTML should have evolved.
WesSouza 3y ago
I’m currently writing HTMX is not the future and expect to be in the front page as well. Thank you.
_oyks 3y ago
Worth pointing out that Astro is already a good solution for this problem; can use it without touching client side libs
intellix 3y ago
Check out Qwik from builder.io
0xblinq 3y ago
No, it’s not.
isonfire36 3y ago
[dead]
fierce443 3y ago
[dead]
floufrouu121 3y ago
[dead]
styleslover123 3y ago
[dead]
genes123 3y ago
[dead]
genes123 3y ago
[dead]
styleslover123 3y ago
[dead]
guyracer5 3y ago
[dead]
guyracer5 3y ago
[dead]
facerracer45 3y ago
[dead]
facerracer45 3y ago
[dead]
guyracer54 3y ago
[dead]
guyracer54 3y ago
[dead]
bikerdude3 3y ago
[dead]
bikerdude3 3y ago
[dead]
virginvanilla1 3y ago
[dead]
virginvanilla1 3y ago
[dead]
hellobabe 3y ago
[dead]
hellobabe 3y ago
[dead]
babykins3 3y ago
[dead]
babykins3 3y ago
[dead]
buckshot53 3y ago
[dead]
buckshot53 3y ago
[dead]
darkhorse34 3y ago
[dead]
darkhorse34 3y ago
[dead]
gamersimmer1 3y ago
[dead]
gamersimmer1 3y ago
[dead]
happyjock1 3y ago
[dead]
happyjock1 3y ago
[dead]
bachelor6 3y ago
[dead]
bachelor6 3y ago
[dead]
boomn1x1 3y ago
[dead]
boomn1x1 3y ago
[dead]
isonfire36 3y ago
[dead]
missmischief4 3y ago
[dead]
missmischief4 3y ago
[dead]
workofgod43 3y ago
[dead]
workofgod43 3y ago
[dead]
lucky43 3y ago
[dead]
lucky43 3y ago
[dead]
fabulous345 3y ago
[dead]
fabulous345 3y ago
[dead]
fierce443 3y ago
[dead]
fashionista45 3y ago
[dead]
fashionista45 3y ago
[dead]
vogue567 3y ago
[dead]
vogue567 3y ago
[dead]
trueliving1 3y ago
[dead]
betches98 3y ago
[dead]
betches98 3y ago
[dead]
trueliving1 3y ago
[dead]
chillhouse54 3y ago
[dead]
chillhouse54 3y ago
[dead]
iamwell45 3y ago
[dead]
iamwell45 3y ago
[dead]
nitch7554 3y ago
[dead]
nitch7554 3y ago
[dead]
babynative54 3y ago
[dead]
babynative54 3y ago
[dead]
thedad46 3y ago
[dead]
thedad46 3y ago
[dead]
betches4534 3y ago
[dead]
betches4534 3y ago
[dead]
thedad4536 3y ago
[dead]
thedad4536 3y ago
[dead]
lyjules534 3y ago
[dead]
lyjules534 3y ago
[dead]
nitch654 3y ago
[dead]
nitch654 3y ago
[dead]
prada543 3y ago
[dead]
prada543 3y ago
[dead]
promax64 3y ago
[dead]
promax64 3y ago
[dead]
drunkbetch54 3y ago
[dead]
drunkbetch54 3y ago
[dead]
poemsporn1 3y ago
[dead]
poemsporn1 3y ago
[dead]
travelmore54 3y ago
[dead]
travelmore54 3y ago
[dead]
haveless54 3y ago
[dead]
haveless54 3y ago
[dead]
lusttforlife1 3y ago
[dead]
chillhouse7 3y ago
[dead]
chillhouse7 3y ago
[dead]
betches98 3y ago
[dead]
betches98 3y ago
[dead]
isonfire54 3y ago
[dead]
isonfire54 3y ago
[dead]
missmischief21 3y ago
[dead]
missmischief21 3y ago
[dead]
lusttforlife1 3y ago
[dead]
kong4523 3y ago
[dead]
kong4523 3y ago
[dead]
petter13123 3y ago
[dead]
petter13123 3y ago
[dead]
petter13 3y ago
[dead]
petter13 3y ago
[dead]
xoxogossip1 3y ago
[dead]
xoxogossip1 3y ago
[dead]
gypsyperson 3y ago
[dead]
gypsyperson 3y ago
[dead]
fabulous657 3y ago
[dead]
fabulous657 3y ago
[dead]
canyon12342 3y ago
[dead]
canyon12342 3y ago
[dead]
velvet564 3y ago
[dead]
velvet564 3y ago
[dead]
collective13 3y ago
[dead]
collective13 3y ago
[dead]
drunk2412 3y ago
[dead]
drunk2412 3y ago
[dead]
babycat 3y ago
[dead]
babycat 3y ago
[dead]
lyjules89 3y ago
[dead]
lyjules89 3y ago
[dead]
vogue134 3y ago
[dead]
vogue134 3y ago
[dead]
inkandfable1 3y ago
[dead]
inkandfable1 3y ago
[dead]
weworewhat1 3y ago
[dead]
weworewhat1 3y ago
[dead]
mystique54 3y ago
[dead]
mystique54 3y ago
[dead]
justonemore1 3y ago
[dead]
justonemore1 3y ago
[dead]
spicysugar1 3y ago
[dead]
spicysugar1 3y ago
[dead]
galaxy12 3y ago
[dead]
galaxy12 3y ago
[dead]
gypsysoul1 3y ago
[dead]
gypsysoul1 3y ago
[dead]
julesontour45 3y ago
[dead]
julesontour45 3y ago
[dead]
pinchofsalt2 3y ago
[dead]
pinchofsalt2 3y ago
[dead]
lustforlife1 3y ago
[dead]
lustforlife1 3y ago
[dead]
weworewhat9 3y ago
[dead]
weworewhat9 3y ago
[dead]
angelhearts1 3y ago
[dead]
angelhearts1 3y ago
[dead]
selfcare4yu1 3y ago
[dead]
selfcare4yu1 3y ago
[dead]
floufrouu121 3y ago
[dead]
morelight11 3y ago
[dead]
morelight11 3y ago
[dead]
reading1234 3y ago
[dead]
reading1234 3y ago
[dead]
livincool134 3y ago
[dead]
livincool134 3y ago
[dead]
smashfizzle12 3y ago
[dead]
smashfizzle12 3y ago
[dead]
terthanthesun1 3y ago
[dead]
terthanthesun1 3y ago
[dead]
thatnerdy12 3y ago
[dead]
thatnerdy12 3y ago
[dead]
angelhearts9 3y ago
[dead]
angelhearts9 3y ago
[dead]
smashfizzle7 3y ago
[dead]
smashfizzle7 3y ago
[dead]
monsoon11 3y ago
[dead]
monsoon11 3y ago
[dead]
blooms112 3y ago
[dead]
blooms112 3y ago
[dead]
floufrouu11 3y ago
[dead]
floufrouu11 3y ago
[dead]
morelight19 3y ago
[dead]
morelight19 3y ago
[dead]
sharinggenes1 3y ago
[dead]
indigosparkle1 3y ago
[dead]
indigosparkle1 3y ago
[dead]
morelight18 3y ago
[dead]
morelight18 3y ago
[dead]
advocates19 3y ago
[dead]
advocates19 3y ago
[dead]
selfcare111 3y ago
[dead]
selfcare111 3y ago
[dead]
yourblanks17 3y ago
[dead]
yourblanks17 3y ago
[dead]
butterflyeffec 3y ago
[dead]
butterflyeffec 3y ago
[dead]
lifebutterfly 3y ago
[dead]
lifebutterfly 3y ago
[dead]
gobblers1 3y ago
[dead]
gobblers1 3y ago
[dead]
livincool87 3y ago
[dead]
livincool87 3y ago
[dead]
selfcare11 3y ago
[dead]
selfcare11 3y ago
[dead]
reading87 3y ago
[dead]
reading87 3y ago
[dead]
flightsnot81 3y ago
[dead]
flightsnot81 3y ago
[dead]
doodles675 3y ago
[dead]
doodles675 3y ago
[dead]
indigosparkle7 3y ago
[dead]
indigosparkle7 3y ago
[dead]
morelight876 3y ago
[dead]
morelight876 3y ago
[dead]
monsoon654 3y ago
[dead]
monsoon654 3y ago
[dead]
indigosparkle6 3y ago
[dead]
indigosparkle6 3y ago
[dead]
fabulous13 3y ago
[dead]
fabulous13 3y ago
[dead]
champagne7 3y ago
[dead]
champagne7 3y ago
[dead]
flightsnot45 3y ago
[dead]
flightsnot45 3y ago
[dead]
isonfire11 3y ago
[dead]
isonfire11 3y ago
[dead]
aabbcc1241 3y ago
If you like the concept of putting some work back to the server instead of throwing to the client, you may also checkout the liveview approach. It drives the entire website using the server with realtime updates (similar interactivity as SPA) This approach has been implemented in most popular programming languages used for backend development: https://github.com/liveviews/liveviews https://github.com/liveviews/liveviews
dfabulich 3y ago
People were making this prediction ten years ago. It was wrong then, and it's wrong now. This article makes its case about Htmx, but points out that its argument applies equally to Hotwired (formerly Turbolinks). Both Htmx and Hotwired/Turbolinks use custom HTML attributes with just a little bit of client-side JS to allow client-side requests to replace fragments of a page with HTML generated on the server side. But Turbolinks is more than ten years old. React was born and rose to popularity during the age of Turbolinks. Turbolinks has already lost the war against React. The biggest problem with Turbolinks/Htmx is that there's no good story for what happens when one component in a tree needs to update another component in the tree. (Especially if it's a "second cousin" component, where your parent component's parent component has subcomponents you want to update.) EDIT: I know about multi-swap. https://htmx.org/extensions/multi-swap/ https://htmx.org/extensions/multi-swap/ It's not good, because the onus is on the developer to compute which components to swap, on the server side, but the state you need is usually on the client. If you need multi-swap, you'll find it orders of magnitude easier to switch to a framework where the UI is a pure function of client-side state, like React or Svelte. Furthermore, in Turbolinks/Htmx, it's impossible to implement "optimistic UI," where the user creates a TODO item on the client side and posts the data back to the server in the background. This means that the user always has to wait for a server round trip to create a TODO item, hurting the user experience. It's unacceptable on mobile web in particular. When predicting the future, I always look to the State of JS survey https://2022.stateofjs.com/en-US/libraries/front-end-frameworks/ https://2022.stateofjs.com/en-US/libraries/front-end-framewo... which asks participants which frameworks they've heard of, which ones they want to learn, which ones they're using, and, of the framework(s) they're using, whether they would use it again. This breaks down into Awareness, Usage, Interest, and Retention. React is looking great on Usage, and still pretty good on Retention. Solid and Svelte are the upstarts, with low usage but very high interest and retention. Htmx doesn't even hit the charts. The near future is React. The further future might be Svelte or Solid. The future is not Htmx.
- recursivedoubts 3y ago
  never tell me the odds, kid https://htmx.org/img/memes/whowillwin.png https://htmx.org/img/memes/whowillwin.png
- 3y ago
rektide 3y ago
Personally I believe strongly in thick clients but this is a pretty neat demo anyways. I see a lot of resemblance to http://catalyst.rocks http://catalyst.rocks with WebComponents that target other components. I think there's something unspoken here that's really powerful & interesting, which is the declarativization of the UI. We have stuff on the page, but making the actions & linkages of what does what to what has so far been trapped in code-land, away from the DOM. The exciting possibility is that we can nicely encode more of the behavior into the DOM, which creates a consistent learnable/visible/malleable pattern for wiring (and rewiring) stuff up. It pushes what hypermedia can capture into a much deeper zone of behaviors than just anchor-tag links (and listeners, which are jump points away from the medium into codespace).
- CRConrad 3y ago
  > ...declarativization of the UI. We have stuff on the page, but making the actions & linkages of what does what to what has so far been trapped in code-land, away from the DOM. The exciting possibility is that we can nicely encode more of the behavior into the DOM, which creates a consistent learnable/visible/malleable pattern for wiring (and rewiring) stuff up. Web “app” development finally catching up to where Visual Basic and Delphi were ~30 years ago, hurrah!
- haolez 3y ago
  Catalyst looks nice! What's the downside? Is it dead?
  - rektide 3y ago
    Catalyst is great. Definitely active, actively used, last updates in main were late February. They have a big 2.0 branch that has a ton of internal changes. TypeScript 5.0 finally updated to support modern @decorator syntax & they're rewriting a bunch to support that, which is excellent.
- wwweston 3y ago
  > the declarativization of the UI Yes! There's always going to be some range of client behavior that's difficult to reduce to declarations, but so much of what we do is common that if it isn't declarative we're repeating a lot of effort. And in general I think you're describing a big part of what made the web successful in the first place; the UI-as-document paradigm was declarative, accessible, readable, repeatable.
obpe 3y ago
It's kinda funny to me that many of the "pros" of this approach are the exact reasons so many abandoned MPAs in the first place. For instance, a major selling point of Node was running JS on both the client and server so you can write the code once. It's a pretty shitty client experience if you have to do a network request for each and every validation of user input. Also, there was a push to move the shitty code from the server to the client to free up server resources and prevent your servers from ruining the experience for everyone. We moved away for MPAs because they were bloated, slow and difficult to work with. SPAs have definitely become what they sought to replace. But that isn't because of the technology, it's because all the devs writing shitty MPAs are now writing shitty SPAs. If this becomes popular, they will start writing shitty MPAs again. Nothing about this technology will stop that.
- sublinear 3y ago
  > all the devs writing shitty MPAs are now writing shitty SPAs drain the swamp man
- hombre_fatal 3y ago
  > For instance, a major selling point of Node was running JS on both the client and server so you can write the code once. (I'm not actually arguing with you, just thinking out loud) This is often repeated but I don't think it even close to a primary reason. The primary reason you build JS web clients is for the same reason you build any client: the client owns the whole client app state and experience. It's only a fluke of the web that "MPA" even means anything. While it obviously has its benefits, we take for granted how weird it is for a server to send UI over the wire. I don't see why it would be the default to build things that way except for habit. It makes more sense to look at MPA as a certain flavor of optimization and trade-offs imo which is why defaulting to MPA vs SPA never made sense now that SPA client tooling has come such a long way. For example, SPA gives you the ability to write your JS web client the same way you build any other client instead of this weird thing where a server sends an initial UI state over the wire and then you add JS to "hydrate" it, and then ensuring the server and client UIs are synchronized. Htmx has similar downsides of MPAs since you need to be sure that every server endpoint sends an html fragment that syncs up to the rest of the client UI assumptions. Something as simple as changing a div's class name might incur html changes across many html-sending api endpoints. Anyways, client development is hard. Turns out nothing was a panacea and it's all just trade-offs.
Pet_Ant 3y ago
The problem is that these kind of approaches require more upfront thought, which produces less now, and pays off later... and only if maintained by people in tune with the original design. I've seen this architectures quickly ruined by 'can-do' people who butcher everything to get a feature done _and_ get a bonus from the management for quick delivery.
- 727564797069706 3y ago
  In my experience, these 'can-do' people can (and usually will) butcher anything, be it MPA, SPA or TUI. This seems like the real problem we need to solve, but not sure how?
  - aidenn0 3y ago
    I suppose we could stop rewarding people for delivering features that customers want...
    - Pet_Ant 3y ago
      Or make them accountable for long term consequences. It’s no different than CEOs cutting R&D and calling a profit. Deferred bonuses till a 3 year post mortem would help.
poidos 3y ago
I’ve been using HTMX (from Clojure) for projects recently and I have to say I like it a lot. Full-stack web stuff is a hobby for me and I always had trouble really grokking all the parts of SPAs. HTMX fits neatly into my brain’s model of how websites should work.
phpnode 3y ago
Title needs (2011). Not because that's when it was written but because that's when this technique was the future.
- recursivedoubts 3y ago
  we are going to go back back to the future
mikece 3y ago
"You can use whatever programming language you like to deliver HTML, just like we used to." Is this suggesting writing any language we want in the browser? I have wondered for a couple decades why Python or some other open source scripting language wasn't added to browsers. I know Microsoft supported VBScript as an alternative to JavaScript in Internet Explorer and had it not been a security nightmare (remember the web page that would format your hard drive, anyone?) and not a proprietary language it might have a rival to JavaScript in the browser. In those days it wouldn't have taken much to relegate JavaScript to non-use. Today we just get around it by compiling to WASM.
- loloquwowndueo 3y ago
  It is not suggesting that. On the server, you can use your language of choice to generate complete or partial HTML responses to be sent and then put in the right places on the page by JavaScript (htmx) running on the browser.
- biorach 3y ago
  > Is this suggesting writing any language we want in the browser? Nope, server
- traverseda 3y ago
  It is not suggesting running arbitrary languages in the browser. It's basically Ajax.
  - avisser 3y ago
    Commenting on "It's basically Ajax": Yes, and it's also a return to the basics of a browser. Making HTTP calls (Hypertext Transfer Protocol) to get HTML (the aforementioned Hypertext) and rendering it is the core thing that browsers do. It's both necessary and sufficient to being a browser.
  - mikece 3y ago
    I hope the execution is better than Ajax! They way that was implemented in WebForms was horrible and a complete PITA to debug.
aidenn0 3y ago
> Managing state on both the client and server This is a necessity as long as latencies between the client and server are large enough to be perceptible to a human (i.e. almost always in a non-LAN environment). [edit] I also just noticed: > ...these applications will be unusable & slow for those on older hardware or in locations with slow and unreliable internet connections. The part about "slow and unreliable internet connections" is not specific to SPAs If anything a thick client provides opportunities to improve the experience for locations with slow and unreliable internet connections. [edit2] > If you wish to use something other than JavaScript or TypeScript, you must traverse the treacherous road of transpilation. This is silly; I almost exclusively use compiled languages, so compilation is happening no matter what; targeting JS (or WASM) isn't that different from targeting a byte-code interpreter or hardware... -- I like the idea of HTMX, but the first half of the article is a silly argument against SPAs. Was the author "cheating" in the second half by transpiling clojure to the JVM? Have they tested their TODO example on old hardware with an unreliable internet connection?
- 8organicbits 3y ago
  > a thick client provides opportunities to improve the experience for locations with slow and unreliable internet connections. The word "slow" here is unclear. Thick clients work poorly on low bandwidth connections, as the first load takes too long to download the JS bundle. JS bundles can be crazy big and may get updated regularly. A user may give up waiting. Thin clients may load faster on low bandwidth connections as they can use less javascript (including zero javascript for sites that support progressive enhancement, my favorite as a NoScript user). Both thin and thick clients can use fairly minimal data transfer for follow-up actions. An HTMX patch can be pretty small, although I agree the equivalent JSON would be smaller. If "slow" means high latency, then you're right, a thick client can let the user interact with local state and the latency is only a concern when state is being synchronized (possibly with a spinner, or in the background while the user does other things). Unreliable internet is unclear to me. If the download of the JS bundle fails, then the thick client never loads. A long download time may increase the likelihood of that happening. Once both are loaded, the thick client wins as the user can work with local state. Both need to sync state sometimes. The thin client probably needs the user to initiate retry (a poor experience) and the thick client could support retry in the background (although many don't support this).
brushfoot 3y ago
I use tech like HTMX because, as a team of one, I have no other choice. I tried using Angular in 2019, and it nearly sank me. The dependency graph was so convoluted that updates were basically impossible. Having a separate API meant that I had to write everything twice. My productivity plummeted. After that experience, I realized that what works for a front-end team may not work for me, and I went back to MPAs with JavaScript sprinkled in. This year, I've looked at Node again now that frameworks like Next offer a middle ground with server-side rendering, but I'm still put off by the dependency graphs and tooling, which seems to be in a constant state of flux. It seems to offer great benefits for front-end teams that have the time to deal with it, but that's not me. All this to say pick the right tool for the job. For me, and for teams going fuller stack as shops tighten their belts, that's tech like HTMX, sprinkled JavaScript, and sometimes lightweight frameworks like Alpine.
- ademup 3y ago
  Your story sounds similar to mine, and your choice to use HTMX has me motivated to check it out. The sum total of my software supports 5 families' lifestyles entirely on LAMP MPAs with no frameworks at all. Thanks for posting.
- scoofy 3y ago
  I use htmx on my current project, and it's like a dream. I'm happy to sacrifice a bit of bandwidth to be able to do all the heavy lifting in python. On top of that, it makes testing much much easier since it turns everything is GET and POST requests. I'd add a couple features if I were working there (making css changes and multiple requests to multiple targets standard), but as it stands, it's a pleasure to work in.
  - niux 3y ago
    What framework do you use for Python?
    - scoofy 3y ago
      Flask
nawgz 3y ago
I'm sorry, but these arguments are so tired. > SPAs have allowed engineers to create some great web applications, but they come with a cost: > Hugely increased complexity both in terms of architecture and developer experience. You have to spend considerable time learning about frameworks. Yes, better quality software usually packages a bit more complexity. SPAs are popular, just like native apps, because people don't like jarring reloads. Webviews in native apps are panned for a reason; turning your whole app into a series of webviews would be stupid, right? > Tooling is an ever-shifting landscape in terms of building and packaging code. I've used these 4 libraries to build apps since 2015: * React * MobX * D3 * Webpack The only one I have had pain with is react-router-dom, which has had 2 or 3 "fuck our last approach" refactors in this time. And I added TypeScript in 2018. PEBCAK > Managing state on both the client and server It's a lie that a thin client isn't managing state; it's just doing a static, dumb job of it. Imagine some cool feature like... collaborative editing. How would you pull that off in HTMX? > Frameworks, on top of libraries, on top of other libraries, on top of polyfills. React even recommend using a framework on top of their tech: Yes, React is famously not a batteries-included library, while Angular is. But, as addressed, you need about 3 other libraries. Besides, did you know: HTMX is also a framework. Did you know: HTMX also has a learning curve. Did you know: HTMX forces you to be able to manipulate and assemble HTMLstrings in a language that might not have any typing or tooling for that? Anyways, I've said enough. I should've just said what I really think: someone who can't even get their nested HTML lists to actually indent the nesting shouldn't give advice on building UIs.
- traverseda 3y ago
  >Imagine some cool feature like... collaborative editing. What are you gaining by writing something like that in java/type-script rather than like rust and webassembly? To me javascript is in a sort of uncanny valley where you probably want to be either making a real app and compiling it to wasm or using something like htmx.
  - nawgz 3y ago
    > rather than like rust and webassembly WASM can't even interact with the DOM, how exactly are these languages positioned better to give me access to a ton of UI primitives? The backend can be a fast language, certainly, but the browser is a premier UI platform... and it's powered by JS... To me, Rust developers thinking they know how to build UIs is the real uncanny valley. What they produce looks like it should work, but the more you look at it, the more you realize they don't know what UX stands for
jimmaswell 3y ago
I've made my personal website something of a hybrid SPA. WithJS enabled it only loads and replaces the relevant portions of the page, but a page renders fully from PHP going to it directly. Relevant code: https://github.com/ldyeax/jimm.horse/blob/master/j/j.php https://github.com/ldyeax/jimm.horse/blob/master/j/j.php https://github.com/ldyeax/jimm.horse/blob/master/j/component/header.js#L68 https://github.com/ldyeax/jimm.horse/blob/master/j/component... The JS would be a bit more elegant if script tags didn't need special handling to execute on insertion. The experience is very seamless this way - I'm very pleased with it. It's live at https://jimm.horse https://jimm.horse - the dynamic behavior can be found clicking on the cooking icon or N64 logo. On reading the article, I'll definitely make use of this if it becomes well-supported. It does exactly what I wanted here.
EGreg 3y ago
We spent 12 years on https://qbix.com/platform https://qbix.com/platform and along the way saw a lot of fads come and go. At one point we experimented with the server returning the stuff to replace the HTML with. We support that in our framework natively (through a mechanism called “slots”). That said, I have come to believe that people this decade will (and should) invert the idea of progressive enhancement to be client-first. Imagine your site being composed of static files (eg served on Hypercore or IPFS via beaker browser). As more people use it, the swarm grows. No worries about being DDOSed. No having to trust a server to not send you the wrong interface one day. The software is yours. It just got delivered via a hypercore swarm or whatever, and your client checked the Merkle trees to prove it hasn’t been tampered with. The you just interact eith a lot of headless web services. Rather than bearer tokens and cookies, you can use webauthn and web crypto to sign requests with private keys. You can do a lot more. And you store your data WHERE YOU WANT. Sure, htmx can be used there. But there, too, it’s better to fetch JSON and interpret it on the client. Returning markup language like HTML actually mixes data with presentation. Consider what happens when you want to return a lot of rows. With JSON, you return just the structured content. With HTML, there is a lot of boilerplate <li class=“foo” onclick=“…”> mixed in there which is a lot of extra weight on the wire. If you are interested in learning more, I gave a whole talk about it: https://qbix.com/blog/2020/01/02/the-case-for-building-client-first-web-apps/ https://qbix.com/blog/2020/01/02/the-case-for-building-clien...
sublinear 3y ago
> SPAs have allowed engineers to create some great web applications, but they come with a cost: ... Managing state on both the client and server Having a separation of concerns between server and client is the whole point, and replacing JSON APIs with data trapped in HTML fragments is a massive step backwards.
- recursivedoubts 3y ago
  https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/
  - dalmo3 3y ago
    So, by your own words, in htmx: > the new API is simply reflected in the new HTML returned by the server Whereas with SPAs (my words) > the new API is simply reflected in the new json returned by the server I think I prefer the mental model of the api serving data and client rendering it.
    - CRConrad 3y ago
      HTML is the data format of Web pages. That's what the client, the browser, is built to render.
  - sublinear 3y ago
    What if we need the same backend to be usable by more than one client? What if those clients aren't even a SPA, but a wrapper library, or a native app? What if we need internal scripts that manage the content in the backend using the same API? What if we need to redesign the client without touching the backend? HTMX doesn't address any of that. YAGNI is often only true for the original developers, not everyone else who has to maintain it long term.
    - recursivedoubts 3y ago
      In the article I recommend splitting your hypermedia and data APIs up into two separate concerns. The data API can address all of the concerns you have. The hypermedia API, being consumed by an htmx front end, can then take advantage of the strengths of hypermedia (e.g. the uniform interface giving you a lot of flexibility in aggressively refactoring your API.) Please, read the article.
pictur 3y ago
If your project consists of a todo list, these tools will do the trick. but they are useless for projects with larger and more complex needs. and yes, there may be cases where it doesn't work in frameworks like nextjs and you need to apply hacky solutions. but I don't see even libraries like nextjs being so self-praising. Come on, folks, there's no point in praising a small package that can do some operations through the attribute. It is inevitable that the projects developed with this package will become garbage when the codebase grows. because that doesn't exist in the development logic. It's nothing more than a smug one-man's entertainment project. sorry but this is the truth.
- jcpst 3y ago
  I don’t understand how it’s inevitable that projects using this package will become garbage when the codebase grows. It looks like reasonable patterns could be built around it. Am I missing something?
- infamia 3y ago
  You can always incrementally add dynamic features using web components when HTMX and similar things aren't a good fit. It doesn't have to be either HTMX or JS-first frameworks. Our industry's fixed mindset of JS/React vs. Hypermedia (e.g., HTMX/Hotwire/Unpoly) needs to change.
  - pictur 3y ago
    I am not for or against anything. I don't live in a fantasy world like in the article. I want to talk about real world problems, not dreams.
    - infamia 3y ago
      A Real World React -> htmx Port https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/
vp8989 3y ago
1) "Web application development" doesn't happen in a vacuum. Often it happens in contexts where the "backend" is also consumed by various non-web applications. In those contexts, collapsing the frontend and backend back into 1 component is less of the slam dunk than it's made out to be in this post. 2) The missing piece is how you can achieve this "collapsing" back of functionality into single SSR deployable(s) while still preserving the ability to scale out a large web application across many teams. Microfrontends + microservices could be collapsed into SSR "microapplications" that are embedded into their hosting app using iframes?
chrislan815 3y ago
Yeah HTMX is nice; I'm still learning about it. I'm building a django app for https://host.upcyclebikes.co/listings/allll https://host.upcyclebikes.co/listings/allll and i'm slowly introducing htmx into it.
recursivedoubts 3y ago
i am the creator of htmx, this is a great article that touches on a lot of the advantages of the hypermedia approach (two big ones: simplicity & it eliminates the two-codebase problem, which puts pressure on teams to adopt js on the backend even if it isn't the best server side option) hypermedia isn't ideal for everything[1], but it is an interesting & useful technology and libraries like htmx make it much more relevant for modern development we have a free book on practical hypermedia (a review of concepts, old web 1.0 style apps, modernized htmx-based apps, and mobile hypermedia based on hyperview[2]) available here: https://hypermedia.systems https://hypermedia.systems [1] - https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ [2] - https://hyperview.org/ https://hyperview.org/
- tkgally 3y ago
  I didn’t know what HTMX was and couldn’t figure it out from the comments here, so I went to htmx.org. This is what I saw at the top of the landing page: > introduction > htmx gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hypertext > htmx is small (~14k min.gz’d), dependency-free, extendable, IE11 compatible & has reduced code base sizes by 67% when compared with react This tells me what htmx does and what some of its properties are, but it doesn’t tell me what htmx is! You might want to borrow some text from your Documentation page and put something like the following at the top of your homepage: “htmx is a dependency-free, browser-oriented javascript library that allows you to access modern browser features directly from HTML.”
- 149203 3y ago
  Every company I've been a part of has redesigned their front end at least once. These redesigns would be a lot more difficult if we had to edit HTML on the client and the HTML that a server returns. Also, HTMX is best styled with semantic classes. Which is a problem for companies using Tailwind and utility classes in their HTML. With class-heavy HTML it's nearly impossible to redesign in two different places. And performance suffers and returning larger chunks of HTML. Despite all that, I want HTMX to be the standard way companies develop for the web. But these 2 problems need to be addressed first, I feel, before companies (like mine) take the leap.
deleted 3y ago
[deleted]
eimrine 3y ago
> Some SPA implementations of SPA throw away progressive enhancement (a notable and noble exception is Remix). Therefore, you must have JavaScript turned on for most SPAs. Is this really the future?
Veuxdo 3y ago
I like how the cons of SPA are "you have to manage state" and "clients have to execute code". I mean, aren't these baseline "get computers to do stuff" things?
- chasd00 3y ago
  back in the olden days a web browser was largely considered just a program to read documents stored on other systems that can be linked to each other sent over a simple stateless protocol. Then we started to be able to collect user input, then a hack was invented to maintain state between requst/response pairs (cookies), then a scripting language etc There are many use cases out there where not treating a browser as a container to run an actual application is the right way to go. On the other hand, there's many use cases where you want the browser to be, basically, a desktop app container. The big bold letters at the top of the article declaring htmlx is the future is a bit much. It has its place and maybe people are re-discovering it but it's certainly not the future of web development IMO. The article gives me kind of web dev career whiplash.
  - 0x445442 3y ago
    When do you want the browser to be anything more than a hypertext document viewer and why?
    - dalmo3 3y ago
      Roughly every time I can use something by just typing some words instead of downloading a .exe.
      - mdaniel 3y ago
        Or its close friend: when I want to use the data or customize the UI via `document.querySelectorAll`
- zerkten 3y ago
  Why do things in two places when you can do it all in one place? This isn't limited to computers, but unless you are getting specific benefits, it isn't wise to continue with a SPA approach. We had the same and worse problems with "thick clients" that came before the web grew. With the right requirements, team, tools etc., you could sometimes build great apps. This was incredibly difficult and the number of great apps was relatively small. Building with earlier server-side web tech, like PHP, isolated everything on the server and it was easier to iterate well than with the "thick clients" model. SPA reinvents "thick clients" to some degree and brings back many of the complications. No one should claim you can't build a great SPA, or that they have few advantages, but the probability of achieving success is frequently lower. Frameworks try to mitigate these concerns, but you are still only moving a closing some of the gaps and the probability of failure remains higher. Depending on the app you can move the success metrics, but we often end up fudging on items like performance. We get to a point where there is current model is fraying and energy builds to replace it with something else. We end up going back to old techniques, but occasionally we learn from what was done before. I find that it's surprisingly rare for people with 1-2 years of experience to be able to give an accurate overview of the last 10 years of web development. A better understanding of this history can help with avoiding (or targeting) problems old timers have encountered and complain about in comments.
peter_retief 3y ago
I like htmx but have decided to use unpoly, for my current project, which is similar. The concept is great but why has it taken so long? https://unpoly.com/ https://unpoly.com/
mtlynch 3y ago
I really want to switch over to htmx, as I've moved away from SPAs frameworks, and I've been much happier. SPAs have so much abstraction, and modern, vanilla JavaScript is pretty decent to work with. The thing that keeps holding me back from htmx is that it breaks Content Security Policy (CSP), which means you lose an effective protection against XSS.[0] When I last asked the maintainer about this, the response was that this was unlikely to ever change.[1] Alpine.js, a similar project to htmx, claims to have a CSP-compatible version,[2] but it's not actually available in any official builds. [0] https://htmx.org/docs/#security https://htmx.org/docs/#security [1] https://news.ycombinator.com/item?id=32158352 https://news.ycombinator.com/item?id=32158352 [2] https://alpinejs.dev/advanced/csp https://alpinejs.dev/advanced/csp [3] https://github.com/alpinejs/alpine/issues/237 https://github.com/alpinejs/alpine/issues/237
- jeremyjh 3y ago
  Alpine is a lightweight client side framework, not really at all equivalent to htmx.
  - mtlynch 3y ago
    I'm not sure what you mean. htmx and alpine.js are both client-side frameworks. To me, they seem to have similar goals and similar functionality. What do you see as the difference?
    - jeremyjh 3y ago
      The purpose of htmx is to enable the server to send fragments of markup to update the dom in response to UI events. Alpine.is is purely client side, you may not even have an application server.
      - mtlynch 3y ago
        Oh, I didn't realize that. Thanks!
    - summarity 3y ago
joseph_grobbles 3y ago
[dead]
lofaszvanitt 3y ago
.. in an alternate universe.
iamsaitam 3y ago
"If you wish to use something other than JavaScript or TypeScript, you must traverse the treacherous road of transpilation." -- this is the crux of the article. These kind of takes fall in the bullseye of "I don't want to program with Javascript". The subtext is all about this. Perhaps.. maybe.. Htmx won't be the future because there are a lot of people that like programming in Javascript?
deleted 3y ago
[deleted]
tedunangst 3y ago
How does this differ from what we called rehydration a decade ago?
- CRConrad 3y ago
  If nothing else, it's less of a silly moniker: Why would I want to get my Web page wet in the first place?!? Remember, DRY!
lucidguppy 3y ago
HTMX brings new life to tech like django which can catapult MVPs into production asap. Backend engineers are now able to write management tools and experimental products faster - and then pass the winning products off to a fluttr team to code for all environments. The backend could be converted into a django rest api if the code is properly refactored.
themodelplumber 3y ago
Thanks for the reminder, I've been meaning to try it out. Just to get started, I asked ChatGPT to write an htmx app to show a 10-day weather forecast. It described the general steps and seemed to be able to describe how htmx works pretty well, including hx-get and hx-target, etc., but then said "As an AI language model, I am not able to write full applications with code". I replied "do the same thing in bash" (which I knew would be different in significant ways, but just to check) and it provided the code. I wonder, is this a function of recency of htmx or something else? Do other htmx developers encounter this? I imagine it's at least a little bit of a pain for these boilerplate cases, if it's consistent vs. access to the same GPT tooling for other languages.
- yawaramin 3y ago
  You can write an htmx app in bash: https://www.youtube.com/watch?v=Jzcu4JheCtY https://www.youtube.com/watch?v=Jzcu4JheCtY
  - themodelplumber 3y ago
    So are you saying that ChatGPT will probably offer to write an htmx app in bash? > I'm sorry, but it's not possible to write a weather forecast app using bash and htmx as htmx is a client-side technology and bash is a command-line shell. htmx is typically used in conjunction with HTML and JavaScript to create dynamic web applications. Cuz that didn't work. It straight up forged ahead and wrote a bash script to show the weather though. I really wonder today if ChatGPT is going to cause a bash renaissance (If you are telling me I can do this myself plz reread posts thx)
- listenallyall 3y ago
  HTMX is quite easy to code. Your prompt sounds rather generic, I mean, you can just serve 10 days of weather forecasts without any interaction whatsoever. https://www.wunderground.com/forecast/us/ak/north-pole https://www.wunderground.com/forecast/us/ak/north-pole It isn't clear what you were asking ChatGPT to provide, therefore not surprised it didn't come up with the exact answer you expected. I'd suggest learning HTMX by reading the docs, the majority is just a single page.
Alifatisk 3y ago
Can we count in Hotwire, inertiajs, Alpinejs, unpolyjs aswell?
honkycat 3y ago
Lol, we're still having the SPA discussion 7 years later in the year of our lord 2023? Talk about the positives of YOUR approach, don't tear down a different approach that half the industry is using. You're not going to say anything new or interesting to the person you are trying to convince this way. Experienced engineers already know the trade-offs between an SPA and a server rendered experience.
- CRConrad 3y ago
  > Talk about the positives of YOUR approach, don't tear down a different approach that half the industry is using. AIUI TFA wasn't by the creators of HTMX, so it isn't the author's approach.
toastercat 3y ago
Does anyone have an example Hacker News client written in HTMX?
majormajor 3y ago
> HTMX allows you to design pages that fetch fragments of HTML from your server to update the user's page as needed without the annoying full-page load refresh. I've been on the sidelines for the better part of a decade for frontend stuff, but I was full-stack at a tiny startup in 2012ish that used Rails with partial fragments templates for this. It needed some more custom JS than having a "replacement target" annotation everywhere, but it was pretty straightforward, and provided shared rendering for the initial page load and these updates. So, question to those who have been active in the frontend world since then: that obviously failed to win the market compared to JS-first/client-first approaches (Backbone was the alternative we were playing with back then). Has something shifted now that this is a significantly more appealing mode? IIRC, one of the big downsides of that "partial" approach in comparison with SPA-approaches was that we had to still write those JSON-or-XML-returning versions of the endpoints as mobile clients became more prevalent. That seems like it would still be an issue here too.
- dpistole 3y ago
  From a front end perspective I think the selling points I see pitched for these new server side frameworks are "SEO" and "speed". SEO I personally think is a questionable motivation except in very specific use cases. Speed is almost compelling but the complexity cost and all the considerations around how a page is structured (which components are server, which are client, etc) does not seem worth the complexity cost IMO. Just pop a loading animation up in most cases IMO. I think I'm stuck somewhere in the middle between old-hacker-news-person yelling "lol were just back at index.html" and freshly-minted-youtube-devs going "this is definitely the new standard".
- efields 3y ago
  FE dev/manager here. I'll tackle this one out of order. > one of the big downsides of that "partial" approach in comparison with SPA-approaches was that we had to still write those JSON-or-XML-returning versions of the endpoints as mobile clients became more prevalent. That seems like it would still be an issue here too. Yup. Still, if you're at the scale where you need to support multiple clients, things should be going well enough where you can afford the extra work. As soon as multiple clients are involved, you're writing SOMETHING to support specifically that client. 10+ years ago, you'd be writing those extra conditionals to return JSON/XML _and_ someone is building out this non-browser client (mobile app, third party API, whatever). But you're not rearchitecting your browser experience so that's the tradeoff. > Has something shifted now that this is a significantly more appealing mode? React especially led from one promise to another about _how much less code_ you'd have to write to support a wide range of clients, when in reality there was always another configuration, another _something_ to maintain when new clients were introduced. On top of that, the mobile device libraries (React Native, etc), were always steps behind what a true native app UX felt like. I think a lot of us seasoned developers just feel burned by the SPA era. Because of how fast it is to iterate in js, places like npm would seemingly have just the right component needed to avoid having to build custom in-house, and its simply an `npm add` and an import away. Meanwhile, as the author states, React and company changed a lot under the hood rapidly, so dependencies would quickly become out of date, now trying to maintain a project full of decaying 3rd party libs because its own tech debt nightmare. Just for, say, popper.js or something like that. I'm just glad the community seems to actively be reconsidering "the old ways" as something valuable worth revisiting after learning what we learned in the last decade.
tgbugs 3y ago
I first encountered the principles behind htmx in its precursor intercooler.js. Those principles really resonated with my distaste for complexity. Amusingly I found out about htmx itself when rereading https://grugbrain.dev https://grugbrain.dev and it all clicked! htmx is crystal that trap internet complexity demon!
- fredrikholm 3y ago
  Irony that they're all made by the same person!
nologic01 3y ago
htmx got a lot of good press (deservedly) but I think somehow it needs to get to the next step beyond the basic hypermedia evangelism. I don't know exactly what that step needs to be, because I don't know what a fully "htmx-ed" web would look like. It is promising, but that promise must be made more concrete. A conceptual roadmap of where this journey could take us and, ideally, some production quality examples of solving important problems in a productive and fun way would increase the fan base and mindshare. Even better if it show how to solve problems we didn't know we had :-). I mean the last decade has been pretty boring in terms of opening new dimensions. Just my two cents.
- minusf 3y ago
  htmx never claimed it's the solution for everything. there is no next conceptual step. it's sending snippets of html to the client. i read most htmx threads on hn and it's clear that people are looking for alternatives from react et al. they have a quick look, maybe implement an example and they are angry that it can't do everything they want cause the js ecosystem fatigue is real. the centerpiece of the htmx site is an actual in-production app that was converted from react and it's better because of that. again, it will not be everybody's case. htmx will let a lot of developers go all the way without bringing node into their ruby/python/php world for certain workloads. for them it is the future. the rest should stop reading.
  - lakomen 3y ago
    the title is literally "htmx is the future"... If htmx wants to be the future it needs to be wrapped in a SSR framework. One that performs well.
s1k3s 3y ago
Love articles like this because I know there's some manager somewhere who will read this and force it upon their team without having any idea if it's good or not. And in 3 years we'll have people from those teams complaining about HTMX because it's not suited for their projects. The future is whatever works best for your use-case.
0xbadcafebee 3y ago
I just want Visual Basic for the web man. Screw writing lines of code. I want to point and click, drop complex automated objects onto a design, put in the inputs and outputs, and publish it. I don't care how you do it, I don't want to know any of the details. I just want to be able to make things quickly and easily. I don't care about programming, I just want to get work done and move on with my life. At this rate, when I'm 80 years old we will still be fucking around with these stupid lines of code, hunched over, ruining our eyesight, becoming ever more atrophied, all to make a fucking text box in a monitor pop some text into a screen on another monitor somewhere else in the world. It's absolutely absurd that we spend this much of our lives to do such a dumb thing, and we've been iterating on it for five decades, and it's still just popping some text in a screen, but we applaud ourselves that we're so advanced now because something you can't even see is doing something different in the background.
- CRConrad 3y ago
  > I just want Visual Basic for the web man. Screw writing lines of code. I want to point and click, drop complex automated objects onto a design, put in the inputs and outputs, and publish it. I don't care how you do it, I don't want to know any of the details. Do an Internet search for “Quartex Pascal”, and/or its creator, Jon Aasenden. He has a blog on WordPress, and a Facebook group. His crazy Quartex project is apparently nearing completion. It's an Object Pascal compiler and IDE — kind of a Delphi / Lazarus clone, if you will — that compiles to JavaScript, for the end product to be run in the browser. I think that's as close to “Visual Basic for the web” as one can get.
- neurostimulant 3y ago
  So, do you want to run a winform app in a browser? Behold! https://github.com/roozbehid/WasmWinforms https://github.com/roozbehid/WasmWinforms https://news.ycombinator.com/item?id=18981806 https://news.ycombinator.com/item?id=18981806
- revelio 3y ago
  There's a lot of low-code platforms that do that.
- 3y ago
jksmith 3y ago
You know, nobody likes this argument, but desktop is still just better. Yeah, yeah, the updates, security issues, I get it, but the tools are simple better, render faster, better functionality/complexity ratio, less gnashing of teeth.
- lolinder 3y ago
  Desktop on which OS? Using what GUI framework? The web is a single platform, but the desktop developer experience seems to vary wildly depending on the OS. I'm genuinely curious what OS and tooling you use that you find so much better, because every time I've tried desktop development I eventually give up and go back to the web. It might be because Linux support is always a requirement for me.
  - jksmith 3y ago
    Both Delphi and FreePascal (less so) support windows, linux, mac, android with the same codebase (or calls rather). The Delphi model has really set the standard for a robust desktop framework, since before most people started writing code.
  - criddell 3y ago
    > which OS? The one you want to run your software on. > what GUI framework? Assuming you aren't making a game, each OS has a different answer. Making an iPadOS or macOS app? I'd probably go with SwiftUI. Linux? I'm partial to GTK. Windows? Probably WinUI (although I also still like MFC extended with raw Win32 API calls). There are cross platform tools, but none of them are very good. If you want to make something really great, target the most important OS and make the absolute best thing you can with the native features of that OS. Follow the conventions of the platform and you get a lot of stuff (like accessibility features) for little effort. > The web is a single platform I agree. The web as presented by the browser is its own distinct platform. A well written web app will almost always use more battery, memory, CPU, and network bandwidth than a similar well written native app. Sometimes, despite all the problems with web technologies, the web is where something belongs. I'm still a big believer in the personal computer. The web takes power from individuals and is a step back to the days of dumb terminals and centralized computing.
PaulHoule 3y ago
I worked for a startup that built a React + Scala system for building training sets for machine learning models. At the time I was involved this had a strong research component, particularly we frequently had to roll out new tasks, and in fact we were working actively with new customers to adapt to their needs all the time. The build for the system took about 20 minutes, and part of the complexity was that every new task (form where somebody had to make a judgement) had to be built twice since both a front end and back end component had to be built so React was part of the problem and not part of the solution. Even in a production environment this split would have been a problem because a busy system with many users might still need a new task added from time to time (think AMZN's MTurk) and forcing people to reload the front end to work on a new task defies the whole reason for using React. It all was a formula for getting a 20 person team to be spinning its wheels, struggling to meet customer requirements and keeping our recruiters busy replacing developers that were getting burnt out. I've built several generations of my own train-and-filter system since then and the latest one is HTMX powered. Each task is written once on the back end. My "build" process is click the green button on the IDE and the server boots in a second or two. I can add a new task and be collecting data in 5-10 minutes in some cases, contrasted to the "several people struggling for 5 days" that was common with the old system. There certainly are UIs that would be hard to implement with HTMX, but for me HTMX makes it possible to replace the buttons a user can choose from when they click a button (implement decision trees), make a button get "clicked" when a user presses a keyboard button and many other UI refinements. I can take advantage of all the widgets available in HTML 5 and also add data visualizations based on d3.js. As for speed, I'd say contemporary web frameworks are very much "blub" http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html On my tablet via tailscale with my server on the wrong end of an ADSL connection I just made a judgement and timed the page reload in less than a second with my stopwatch. On the LAN the responsiveness is basically immediate, like using a desktop application (if the desktop application wasn't always going out to lunch and showing a spinner all the time.)
fogzen 3y ago
Server-side apps cannot provide optimistic UI. No matter how you feel about it, they are limited in this capability compared to client-side apps. The user doesn’t care about the technology. For example, imagine a todo app that shows a new todo immediately. Or form validations that happen as soon as data is entered. That’s a superior experience to waiting on the server to continue interaction. Whether that’s harder to engineer is irrelevant to the user. We should be striving for the best possible user experience, not what we as engineers personally find easy or comfortable. HTMX is cool. HTMX may fit your needs. But it’s not enough for providing the best possible user experience.
- adamckay 3y ago
  You don't have to be restricted to just using htmx, you can use it with client side Javascript to give you that interactivity you need in the places you need it. Indeed, the creator of htmx has created another library called hyperscript which he's described as a companion to htmx. https://hyperscript.org/ https://hyperscript.org/
  - sublinear 3y ago
    Awful. The last thing we need is another layer further away from plain javascript cluttering up web pages.
steve76 3y ago
[dead]
tudorw 3y ago
Xanadu.
yellowapple 3y ago
Using an HTTP header to decide between "just return a snippet for this specific list element" v. "return the whole page with the updated content for this list element" is an interesting choice that I hadn't really considered before; normally I would've opted for two entirely separate routes (one for the full page, one for the specific hypermedia snippet), which HTMX also seems to support. I guess it ain't fundamentally different from using e.g. Accept-* headers for content negotiation.
- quii 3y ago
  I think both are valid, as i mentioned in the article, for this particular case, the psuedo content-negotiation felt right
rglover 3y ago
Or: just use plain HTML [1] and keep separation of concerns intact. In a quote: > "So much complexity in software comes from trying to make one thing do two things." - Ryan Singer (Basecamp/37Signals) [1] https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick
kokizzu5 3y ago
meh, Svelte is the future, just plain Svelte, not SvelteKit
auct 3y ago
I tried htmx, but syntax is horrible, so 3 years ago I've created uajax universal Ajax forms and js-ajax-button. Add class to any form and it is ajaxed. I even released it on github The js-ajax-button has similar approach. Add class to button that have data-url and it will make request to it. This is small func I use, but with uajax is so powerful, I don't need react or htmx. But it is hard to sell something that eliminates using javascript.
iamgopal 3y ago
Basecamp ( or Hey or guys behind ror ) , the original SAAS guys really do understand software development from practical point of view, they did something similar with rails as well as native clients, now a days they are trying people to move away from cloud. Bare metal is the future.
thomasreggi 3y ago
I agree with this article, however I think that HTMX needs a strong server framework to support HTMX. I've thought about this alot and a couple months back created this deno / typescript framework https://github.com/reggi/htmx-components https://github.com/reggi/htmx-components, would love for people to take a look at it and provide guidance and direction for a releasable version.
- triyambakam 3y ago
  That's really nice!
munbun 3y ago
The HATEOAS approach is viable for some applications but I wouldn't necessarily call it the future. Using custom html attributes as the base for complex client-side interactions is arguably a step backwards when considering the story around maintenance. Right now, if you are building a robust component library - it's much easier to maintain using a template language with strong Typescript / IDE support, like JSX or similar.
can16358p 3y ago
I think "the future" definitely isn't some non-standard custom attributes.
robertoandred 3y ago
This really comes down to backend devs thinking frontend must be simple, and when they realize it's not they blame the tools. So they come up with new tools and pretend they're better because they cater to backend devs and not those silly frontenders who just don't know anything.
quest88 3y ago
This is a weak argument. The article is demoing a TODO app talking to localhost. Almost any library, framework, or language is the future if this is how we're judging the future. > Working with HTMX has allowed me to leverage things I learned 15-20 years ago that still work, like my website. Yes, a website is different than a webapp and has different requirements.
- BeefySwain 3y ago
  > Yes, a website is different than a webapp and has different requirements. The piece missing here is that most people do not stop to think which they are building before they reach for a JS heavy SPA framework and start spinning up microservices in whatever AWS calls their Kube implimentation.
anyonecancode 3y ago
The tricky part of an SPA is that as a developer, you're taking on a lot of the burden of managing location state that in an MPA is handled by the browser. And location state often is a significant component of application state. Certainly it's possible to take on that burden and execute it well, but I think a lot of teams and businesses don't fully account for the fact that they are doing so and properly deciding if that extra burden is really necessary. The baseline for nailing performance and correctness is higher with an SPA.
divan 3y ago
Why people concentrating on creating more hacks on top of fundamentally ill-suited stack for app development, rather then rethink the whole stack from the first principles? Luckily, after 3 decades, there is some sobering realization that typesetting engine is not a good foundation for modern apps. https://news.ycombinator.com/item?id=34612696 https://news.ycombinator.com/item?id=34612696 Web development without HTML/CSS/JS is the future.
mal-2 3y ago
I like some concepts from HTMX but I don't understand how it tracks the relationship between these addresses and the identifiers in the markup. It seems to be just that the identifier strings match - the markup identifies the targets/swaps and it just refers to itself. When I compare this to Phoenix LiveView I much prefer LiveView, because it both provides the markup templating engine and tracks the meaning of the relationship, with server-side tokens and methods.
qgin 3y ago
As long as native apps live alongside web, then the architecture of web is going to trend towards that of native apps, managing display state on the client while managing business state on server.
BeefySwain 3y ago
I recently put together https://github.com/PyHAT-stack/awesome-python-htmx https://github.com/PyHAT-stack/awesome-python-htmx at PyCon. If anyone is looking to discuss making Hypermedia Driven Applications with HTMX in Python, head over to the discussions there!
- nologic01 3y ago
  Good initiative. HTMX + python hits a sweet spot for various interesting things.
hu3 3y ago
meta: I love when htmx is highlighted in HN because the discussions branch into alternatives and different ways of doing web dev. It's very enriching to think outside the box!
- mikeg8 3y ago
  Agree. I always find some interesting and new FE approaches/methodologies in these random HTMX threads and it’s awesome.
tacone 3y ago
I used to have my hand-written mini version of htmlx ten years ago. It took a few jquery lines of code to have small parts of the UX to update without refresh. I don't see the point by the way, I think htmlx is here to stay and a good choice for many, but it's clearly not a silver bullet. You make decently fast UIs, not blazing fasts, there are no (proper) offline first apps with htmlx, caching is likely more difficult or impossible sometimes and the load for your server is inevitably greater (of course it could be more than acceptable in some cases, so why not?), that also means more bandwidth for your cloud provider as opposed for you cdn. You will still have to write javascript sooner or later. It depends on what you're doing. Nothing is aprioristic ly "the future", the future is "the future", and it has yet to come.
pwpw 3y ago
What is the simplest way to host a website closer to barebones HTML, CSS, and a bit of JS with reusable components like nav bars? My experiences handling those manually leads to too much overhead as I add more pages. SvelteKit makes things fairly easy to organize, but I dislike how the user isn’t served simple HTML, CSS, and JS files. Ideally, I don’t want to use any framework.
- optymizer 3y ago
  It's called PHP and you can host it anywhere, or if there's nothing dynamic going on, run it on the files on your computer and upload the generated HTML/CSS/JS files to an S3 bucket. src/index.php --------- <!DOCTYPE html> <html> <head><title>Hey look ma, we're back to PHP</title></head> <body> <? include "navbar.php" ?> <p>Don't forget about PHP - a hypertext preprocessor!</p> <? include footer.php ?> </body> </html> src/navbar.php ---------- <div> <ul> <li>Home</li> <li>About</li> </ul> </div> Makefile to generate a static site: ----------------------------------- dist/index.html: src/index.php dist/about.html: src/about.php dist/%.html: src/%.php @mkdir -p ${dir $@} php $< > $@
- pier25 3y ago
  Astro
pkelly 3y ago
Thank you for writing this article! I've had similar thoughts for the past 5 years or so. A lot of the comments here seem to have the approach that there is a single best stack for building web applications. I believe this comes from the fact that as web engineers we have to choose which tech to invest our careers in which is inherently risky. Spend a couples years on something that becomes defunct and it feels like a waste. Also, startup recruiters are always looking for the tech experience that matches the choice of their companies. VCs want to strike while the iron is hot. Something that doesn't get talked about enough (which the author does mention near the end of article) is that different web apps have different needs. There is 100% a need for SPAs for certain use cases. Messaging, video players, etc. But there are many cases where it is overkill, like the many many CRUD resource apps I've built over the years. Say you have a couple hundred users that need to manage the state of a dozen interconnected resources. The benefits of an MPA are great here. Routing is free, no duplication of FE / BE code. Small teams of devs can ship code and fix bugs very fast which keeps the user feedback loop tight.
- quii 3y ago
  Thanks for taking the time to read the article :) A lot of the comments here seem to implying that I claim "htmx is the one hammer to solve all website needs", even when I explicitly say SPAs have their place in the article. A hypermedia approach is the nice happy medium between a very static website and an SPA, not sure why so many people are close-minded about this possibility.
branko_d 3y ago
I’m afraid htmlx might be repeating the same mistake that CORBA and DCOM made decades ago: pretending that latency doesn’t matter. Yes you could make a CORBA or DCOM object almost indistinguishable from a local object, except for the latency when it was actually remote. And since it looked like a normal object it encountered “chatty” interface which exacerbated the latency cost. Htmlx seems pretty chatty to me, which I’m sure works OK over the LAN, but what about the “real” internet?
w10-1 3y ago
What's the business case, for them or for developers? Ideas aside, the web app future belongs to those with the resources to sustain a response, or those who can restore the ability to capture/monetize developers and users in a closed system. The scope of web apps is broad enough that many technologies arguably have their place. The open javascript ecosystem reduced the cost of creating candidates, but has no real mechanism to declare winners for the purpose of consolidating users, i.e., access to resources. Careers and companies are built on navigating this complexity, but no one really has the incentive to reduce it unless they can capture that value. I really appreciate Cloudflare because they are open about both their technology and their business model. They thus offer a reasonable guarantee that they can sustain their service and their technology, without basing that guarantee on the fact that they are a biggie like AWS, Microsoft, or Google (i.e., eating their own dog food, so we can join them at the trough). The biggest cost in IT is not development or operating fees but reliance and opportunity.
hamilyon2 3y ago
I am not going to be serious here, because, honestly, this is kind of ridiculous. Two years ago I distinctly remember server side rendering piped thru websocket was future. I also like how demo is visibly ugly, jQuery-style ugly. It's nostalgic in a way. And I swear to gods this approach will break back button. And resending form after network error. And expired cookie will of course result in your input being lost.
Animats 3y ago
It's sort of like client side PHP. Is that a good thing or a bad thing?
bottlepalm 3y ago
I tried HTMX. The static typing just isn't there between the components you send down and the rest of the page. This makes maintenance of a large HTMX app pretty costly. For simple stuff, it's probably fine, but large complicated web apps, I'm not seeing it. Mixing HTML fragments from the server into the client is pretty messy. Keeping all the rendering in one place à la React seems much simpler to maintain. With Next for example you can pre-render on the server, and re-render on the client - the same code is doing the rendering in both places so a bit more easier to understand.
deleted 3y ago
[deleted]
CodeCompost 3y ago
I'm beginning to realise that AI assistance is now resulting in long and verbose articles like this one. The bullet points are especially off-putting.
- rmorey 3y ago
  then the problem begets its own solution - just use an assistant to summarize for you! \s (i don't actually think this article is largely AI-generated)
hankchinaski 3y ago
everytime i see a custom new DSL i just bin the thing altogether, I dont want to learn a new DSL that will disappear in a year, it will be impossible to find documentation and community support for. just a big no for me. Apart from that seems like a good idea >Here we are getting a bit fancy and only allowing one row at a time to be edited, using hyperscript. https://hyperscript.org https://hyperscript.org
redonkulus 3y ago
We've been using similar architecture at Yahoo for many years now. We tried to go all in on a React framework that worked on the server and client, but the client was extremely slow to bootstrap due to downloading/parsing lots of React components, then React needing to rehydrate all the data and re-render the client. Not to mention rendering an entire React app on the server is a huge bottleneck for performance (can't wait for Server Components / Suspense which are supposed to make this better ... aside: we had to make this architecture ourselves to split up one giant React render tree into multiple separate ones that we can then rehydrate and attach to on the client) We've moved back to an MPA structure with decorated markup to add interactivity like scroll views, fetching data, tabs and other common UX use cases. If you view the source on yahoo.com and look for "wafer," you can see some examples of how this works. It helps to avoid bundle size bloat from having to download and compile tons of JS for functionality to work. For a more complex, data-driven site, I still think the SPA architecture or "islands" approach is ideal instead of MPA. For our largely static site, going full MPA with a simple client-side library based on HTML decorations has worked really well for us.
- thomond 3y ago
  I had no idea Yahoo
- vosper 3y ago
  > We've been using similar architecture at Yahoo for many years now. At all of Yahoo? I imagined such a big company would have a variety of front-end frameworks and patterns.
  - redonkulus 3y ago
    Nope, not all. Yahoo homepage, News, Entertainment, Weather all use this architecture. Yahoo Mail uses a React/Reduct architecture on the client. Other Yahoo properties with more complex client-side UX requirements are using things like Svelte or React. It's not a one size fits all architecture at Yahoo, we let teams determine the right tools for the job.
- pier25 3y ago
jcmontx 3y ago
I am very fond of MPAs. Glad to see them make a comeback. The one single strong point of the front/back split is the famous Strangler Fig Pattern which takes away a lot of stress when making decisions.
mike503 3y ago
Reminds me of Drupal's AHAH implementation.
xutopia 3y ago
Wether it is Htmx or Phoenix/Liveview or Hotwire/Stimulus we're seeing a shift in the industry towards augmented HTML rather than throwing away all RESTFUL routes. REST is elegant and this approach is very powerful as well.
doodlesdev 3y ago
No it's not. Honestly, the fact that this website displays like shit without JavaScript enabled is ironic considering it uses HTMX. Please just use the damn full-stack JS frameworks, they make life simpler, just wait for WebAssembly to allow us to have full-stack Rust/Go/whatever frameworks, and then you can abandon JavaScript, otherwise you get the mess of websites like this one where the developer has not written JavaScript, but the website still needs it for me to be able to read a _damn blog post_. Otherwise, stick with RoR, Django, Laravel, or whatever ticks your fancies, but HTMX just ain't for everyone and everything, it's supposed to be used for hypermedia, not for web apps or anything else, just that: hypermedia. And no, JavaScript libraries aren't all "complicated" and "full of churn", React is. Stop using React, or otherwise accept the nature of its development, and stop complaining. There are hundreds of different JavaScript libraries and yet every single time I see people bashing on full stack JavaScript they just keep repeating "React" like it's the only library in the world and the only way developers have written code for the last decade. Also, tangentially related, can we as an industry stop acting like kids and stop following these "trends"? The author talks about a "SPA-craze" but what I've been seeing more and more now is the contrary movement, however it's based on the same idea of a hype cycle, with developers adopting technology because it's cool or whatever and not really considering what are their actual needs and which tools will provide them with that. Rant over.
- lakomen 3y ago
  [flagged]
  - doodlesdev 3y ago
    I'm sorry for saying something you disagree with. Next time I'll ask for permission to comment my opinion. Really, what's the point of your comment? At least state why you think I have no idea what I'm talking about, the way you wrote it adds literally nothing to the conversation.
    - dang 3y ago
      Please don't respond to a bad comment by breaking the site guidelines yourself. That only makes things worse. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
loxs 3y ago
Am I the only one who actually thinks that a SPA is simpler than server rendered UI? I always go for a SPA when I can sacrifice indexability and never seem to regret it.
diegof79 3y ago
While HTMLX makes some interactions easier for developers without JS experience, the primary issue in web development is that the browser was not designed for apps. It evolved unevenly from a document navigation platform, and many things we do in web development today are hacks due to the lack of a better solution. In my opinion, the future of the web as a platform is about viewing the web browser as an operating system with basic composable primitives. HTMLX adds attributes to HTML using JS, and the argument about "no-JavaScript" is misleading: with HTMLX you can write interactions without JS, but HTMX uses JS. But, as it forces you to use HTML constructs that will work without scripts (such as forms), the page will fall back. It doesn't means that the fallback is usable. The custom HTMLX attributes work because the browser supports extensions of its behavior using JS. If we add those attributes to the standard HTML, the result is more fragmentation and an endless race. The best standard is one that eliminates the need for creating more high-level standards. In my view, a possible evolution of WASM could achieve that goal. It means going in the opposite direction of the article, as clients will do more computing work. In a future like that, you can use HTMLX, SwiftUI, Flutter, or React to develop web apps. The biggest challenge is to balance a powerful OS-like browser like that with attributes like searchability, accessibility, and learnability (the devtools inspect and console is the closest thing to Smalltalk we have today)...even desktop OSs struggle today to provide that.
incrudible 3y ago
I take the opposite side of that bet. Always bet on (more) Javascript. Dealing with HTML sucks, and we want as little of it as possible, otherwise we would not have invented generations of frameworks to make it manageable. The lasting success of React shows that we have converged on how to do that. Moving back to MPAs is always something that bored engineers want to do. Users generally do not care. Moreover, REST APIs - and I mean the simple ones people actually want to use, none of that HATEOAS BS - are ubiquitous for all sorts of interactions between web and nonweb clients. Are you going to ship an MPA as your mobile apps, or are you going to just use REST plus whatever clients make sense? It also makes a lot of sense in terms of organization. Your backend developers probably suck at design, your frontend developers suck at databases.
klabb3 3y ago
> Hugely increased complexity both in terms of architecture and developer experience. You have to spend considerable time learning about frameworks. You have to learn something. You can claim bloat in JS frameworks, but that isn’t solved by simply moving it to the server. Is htmx lean and nice today? Probably! But does it handle the same use cases that the React users have? What happens to it under pressure of feature bloat? Small-core frameworks like Elm who resisted this pressure were abandoned by big shops. You can’t just take something immature (however good) and simply extrapolate a happy future. > Tooling is an ever-shifting landscape in terms of building and packaging code. Yes. JS is not the only language with churn issues and dependency hell. > Managing state on both the client and server Correct me if I’m wrong, but state can change for something outside of a htmx request, meaning you can end up with stale state in element Y in the client after refreshing element X. The difference is that your local cache is in the DOM tree instead of a JS object. > By their nature, a fat client requires the client to execute a lot of JavaScript. If you have modern hardware, this is fine, but these applications will be unusable & slow for those on older hardware or in locations with slow and unreliable internet connections. On unreliable connections you want as thick of a client as possible. If you have server-in-the-loop for UI updates, you quite obviously have latency/retry issues. It’s much preferable to show stale state immediately and update in the background. > It is very easy to make an SPA incorrectly, where you need to use the right approach with hooks to avoid ending up with abysmal client-side performance. Bloat comes from reckless software development practices, and are possible in any technology. Angular and React have a shitton of features and ecosystem around it, whereas say Svelte is more lean. Enterprisey shops tend to prioritize features and not give a flying fuck about performance. This is a business choice, not a statement about technology. > Some SPA implementations of SPA throw away progressive enhancement (a notable and noble exception is Remix). Therefore, you must have JavaScript turned on for most SPAs. Finally, we cut to the chase. This is 100% true, and we should be talking about this, because it’s still not settled: do we want web pages or web apps? If both, where is the line? Can you expect something like Slack to work without JavaScript? What about a blog with interactive graphs? Should everything degrade or should some things require JS/WASM? I love that htmx exists. I have absolutely nothing against it. It honors some of the early web philosophy in an elegant and simple manner. It may be a better model for server-centric apps and pages, which don’t need offline or snappy UIs. But it cannot magically solve the inherent complexities of many modern web apps.
teaearlgraycold 3y ago
I'd rather see either: * NextJS provide a holistic solution to backend code. Right now it's missing an ORM that works with serverless postgres. Given their recent additions of serverless postgres to Vercel I expect this will happen in 6-12 months. * RedwoodJS become more mature. The issues with SPAs IMO come from having to cobble together your full stack app, which requires making a ton of hard decisions in predicting the future of each major library you use. And then there's limited coherence between your ORM, API, and client without extra work. A mature, well designed, and financially supported full stack JS solution that truly rivals Rails would be perfect.
chrsjxn 3y ago
I love articles like these, because the narrative of "JS framework peddlers have hoodwinked you!" is fun, in an old-timey snake oil salesman kind of way. But I'll be honest. I'll believe it when I see it. It's not that htmx is bad, but given the complexity of client-side interactions on the modern web, I can't see it ever becoming really popular. Some of the specifics in the comparisons are always weird, too. > Instead of one universal client, scores of developers create bespoke clients, which have to understand the raw data they fetch from web servers and then render controls according to the data. This is about client side apps fetching arbitrary JSON payloads, but your htmx backend needs to do the same work, right? You have to work with the raw data you get from your DB (or another service) and then render based on that data. You're still coupled to the data, and your htmx endpoint is just as "bespoke" as the client code which uses it. It's not wrong to prefer that work be done on the server instead of the client, or vice versa, but we're really just shuffling complexity around.
- fogzen 3y ago
  You touch on something that bugs me about these discussions: Lack of proof. Show me the web app with killer UX developed with htmx. Show me the product of the tools and processes being advocated.
  - renerick 3y ago
    I'm not a developer of either of these, but here are two examples: - https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ by https://github.com/David-Guillot https://github.com/David-Guillot - a SaaS product migrated to htmx from React. - https://zorro.management/ https://zorro.management/ by https://twitter.com/Telroshan https://twitter.com/Telroshan - a kanban project management tool. This one is particularly interesting IMO, it implements quite advanced UI with htmx and some custom JS.
    - fogzen 3y ago
      Thanks! I feel like these discussions would be so much more fruitful if they were centered around dissecting real products.
wibblewobble124 3y ago
we’re using htmx at work, migrating away from react. the technique we’re using is just rendering the whole page, e.g. we have a page where one side of the screen is a big form and the other side is a view on the same data but with a different UI, updating one updates the other. we’re using the morphdom swapping mode so only the things that changed are updated in-place. as a colleague commented after implementing this page, it was pretty much like react as far as “pure function of state.” our policy is that for widgets that are like browser components e.g. search as you type with keyboard shortcuts, we just use the off the shelf react component for that purpose and use it from htmx like it’a browser input element. for all other business logic (almost all of which has no low latency requirements and almost always involves a server requets), we use htmx in our server side language of choice. our designer who knows a bit of react is not happy, but the 12 engineers on our team who are experts in $backend_lang and who are tired of debugging react race conditions, cache errors, TypeScript front end exceptions, js library churn, serialisation bugs, etc. are very happy indeed. it doesn’t fit every app, but it fits our app like a glove and many others that I’ve considered writing that I didn’t feel like bothering to do so before discovering htmx.
- robertoandred 3y ago
  Sounds like your backend devs are just bad at frontend.
  - ihateolives 3y ago
    And? Your average React dev is bad at proper backend too.
    - robertoandred 3y ago
      So then doesn't it make sense that frontend devs focus on frontend and backend devs focus on backend?
      - CRConrad 3y ago
        It makes sense that application developers focus on getting an application to work. In the case of these newfangled “Web applications”, that would be focussing on getting HTML to render in the user's browser. That focus doesn't have to have anything to do with an arbitrary split into “frontend and backend”.
klysm 3y ago
I'll stick to making SPAs for the apps I work on. This is just the pendulum of tradeoffs swinging back till people experience the pains of MPAs again
denton-scratch 3y ago
How's it not a SPA, if you're updating the DOM in JS without a full page reload? Sorry, I read a load of stuff about React, before I came to any explanation of HTMX. Turns out, it's loading fragments of HTML into the DOM (without reload), instead of loading fragments of JSON, converting them to HTML fragments client-side, and injecting the resulting HTML into the DOM (without reload). So I stopped reading there; perhaps the author explained why HTMX solves this at the end (consistent with the general upside-down-ness), but the "is the future" title was also offputting, so excuse me if I should have read the whole article before commenting. I never bought into the SPA thing. SPAs destroy the relationship between URLs and the World Wide Web.
- robertoandred 3y ago
  SPAs work with complex, relevant, and unique URLs perfectly fine.
aigoochamna 3y ago
I somewhat get where htmx is coming from. It's not bad per-say.. I actually like the general idea behind it (it's sorta like Turbolinks, but a bit more optimal using fragments instead of the entire page, though Turbolinks requires zero additional work on the markup side and works with JavaScript disabled out of the box). With that being said, I imagine it would become unmaintainable very quickly. The problems htmx is solving are better solved with other solutions in my opinion, but I do think there's something that can be learned or leveraged with the way htmx goes about the solution.
- CRConrad 3y ago
  > It's not bad per-say.. Per se. It's Latin for “in itself”; has nothing to do with saying anything. Think about it: What would “per-say” even mean?
- werdnapk 3y ago
  Turbo (the updated Turbolinks) uses fragments quite heavily... Turbo calls them frames. Turbolinks was more of a full page only approach though.
deleted 3y ago
[deleted]
tkiolp4 3y ago
Frontend developers don’t want to write HTML nor augmented HTML. They want to write code, and these days that means JS. Frontend developers want to make good money (like those backend developers or even infrastructure developers who are working with data, servers, and cool programming languages), hence they need to work with complex libraries/frameworks (if you just write HTM?, you don’t get to earn much money because anyone can write HTM?). Hell, the term “frontend developer” exists only because they are writing JS! Tell them it’s better to write HTM?, and you are removing the “developer” from their titles! Same reason why backend developers use K8s. There’s little money on wiring together bash scripts. Now, if you’re working on your side project alone, then sure HTMX is nice.
- robertoandred 3y ago
  Incorrect. You can't create a website without HTML. The term "frontend developer" exists because frontend is a complex mix of HTML, CSS, JS, browser functionality, screen sizes, accessibility requirements, privacy requirements, server interactions. Backend devs just lampoon it because they assume it must be simple.
kubota 3y ago
I don't know. The tabs example on the htmx page is perceptibly slow to me. Making a rest call every time I switch a tab, each time sending 90% of the same html skeleton data over the wire feels like a sin to me. Returning html from my api also feels like a sin.
- CRConrad 3y ago
  > Returning html from my api also feels like a sin. Sorry, but that's just... Silly. HTML is what the Web is all about.
  - kubota 3y ago
    Most of my apis are consumed my multiple clients, many without user interfaces (other backend systems), some with mobile user interfaces, some with web interfaces. I should make my backend clients parse HTML? Or my mobile clients parse HTML? I don't see any benefit to coupling data to a visual markup language, unless you are only serving web ui clients, and have no plans for that to ever change. Or I should stand up additional services (and pay for their operation and maintenance) just to server side render my data wrapped in html? That seems sillier to me, but to each their own.
jmull 3y ago
> HTMX is the Future I'm not seeing it. SPAs can be overly complex and have other issues, but I'm not seeing HTMX as a particular improvement. Also, a bunch of this article doesn't make sense to me. E.g, one of the listed costs of SPAs is managing state on the client and server... but (1) you don't have to -- isn't it rather common to keep your app server stateless? -- and (2) HTMX certainly allows for client-side and server-side state, so I'm not sure how it's improving things. That is, if you want to carefully manage app state, you're going to need a mechanism to do that, and HTMX isn't going to help you. It also doesn't somehow prevent a rats nest of tooling or dependencies. It isn't an application framework, so this all depends on how to solve that. SPA's also aren't inherently "very easy to make [...] incorrectly". Also, the suggested HTMX approach to no browser-side javascript is very crappy. Your app would have to be very specifically designed to not be utterly horrible w/o JS with such an approach and instead be just pretty horrible. There are just so much more straightforward ways to make apps that work well without JS. Also, this isn't exactly a mainstream requirement in my experience. I could go on and on. "caching" - htmx doesn't address the hard part caching. "seo-friendliness" - Like all the benefits here attributed to htmx, htmx doesn't particularly help with this and there are many other available way to achieve it. IDK. These kinds of over-promising hyped up articles give me the feeling the thing being hyped up probably doesn't have a lot of real merit to be explored or else they'd talk about that instead. It also feels dishonest to me, or at least incompetent, so make all of these claims and assertions that aren't really true or aren't really especially a benefit of htmx vs many numerous other options.
- CRConrad 3y ago
  > SPA's also aren't inherently "very easy to make [...] incorrectly". Judging from the ones one encounters in the wild, yes they are.
unixhero 3y ago
As long as I don't have to learn it.
michaelchisari 3y ago
Everybody's arguing about whether Htmx can do this or that, or how it handles complex use case x, but Htmx can do 90% of what people need in an extremely simple and straight-forward way. That means it (or at least its approach) won't disappear. A highly complex stock-trading application should absolutely not be using Htmx. But a configuration page? A blog? Any basic app that doesn't require real-time updates? Htmx makes much more sense for those than React. And those simple needs are a much bigger part of the internet than the Hacker News crowd realizes or wants to admit. If I could make one argument against SPA's it's not that they don't have their use, they obviously do, it's that we're using them for too much and too often. At some point we decided everything had to be an SPA and it was only a matter of time before people sobered up and realized things went too far.
- silver-arrow 3y ago
  Exactly! Well said
- ktosobcy 3y ago
  This! It's like with static websites - we went from static to blogs rendered in php and then back to jekyll...
jdthedisciple 3y ago
This puts all the computational load on the server. Imagine 10s of thousands of clients requesting millions of HTML fragments be put together by a single server maintaining all the states while all the powerful high end computing power at the end user's fingertips goes completely to waste. Not convinced.
- IshKebab 3y ago
  Most users these days are probably using phones, not high end computers.
  - dhosek 3y ago
    Most phones have an awful lot od computational power.
  - jdthedisciple 3y ago
    Most phones have more computing power than all of NASA did in the 80s. I was specifically thinking of modern smartphones in fact, which are pretty damn fast at executing a little bit of JS. (Though I agree that some of the bloated bundles resulting from modern frameworks or their poor usage definitely go to far)
  - rwalle 3y ago
    The processor on my phone is better than the one on a 2015 Macbook Pro 13" (i5)
    - IshKebab 3y ago
      The processor on an average phone does not.
- mixmastamyk 3y ago
  This avoids unnecessary computation at the client, it does not substantially add to the burden of the server. Which would need to be reconciled regardless of the markup format used over the pipe. Alpine is available for local flair.
nine_k 3y ago
I think it's the wrong article (pun semi-intended), HTMX is a future. React is a future. Svelte is a future. Even Angular is a future. They all have their specific strengths which define where they are more applicable. There's no "the future" in this area, because demands are very different; a heavily interactive SPA like GMail or Jira has requirements unlike an info page that needs a few bits of interactivity, etc.
quickthrower2 3y ago
No. A hodgepodge of everyone's favourite way, is the future. Always has been! That said for my next hobby project I will probably go even simpler than HTMX, and use classic server side rendering. Then add some Vanilla JS where needed. I keep going around in circles, but I have tried NextJS and while pretty cool there are a class of problems you need to deal with that simply don't exist in simpler apps.
xkcd1963 3y ago
"The hypermedia approach of building websites led to the world-wide-web being an incredible success." This is wrong
bfung 3y ago
The article reminds me of the early 2000s when we were all rolling our own XMLHttpRequest and replacing dom elements with html rendered from a java servlet. The more realistic and practical read is https://htmx.org/essays/when-to-use-hypermedia/#hypermedia-not-a-good-fit-if https://htmx.org/essays/when-to-use-hypermedia/#hypermedia-n...
janosd 3y ago
I can still remember the horrors of page state. The server would keep track of what the client has and only send HTML fragments to the client. Early-days ASP, Prado and the likes did this and it was a terrible idea. HTMX sounds very much like that, but the packaging is nicer. Ultimately, the problem is that sometimes you need to update more than just the tiny, well-defined part that is the todo list and several parts of the UI need to change when a request is made. By which I mean this happens all the time. The road to hell is paved with todo list implementations as a proof that a system works and is good. Please show me a moderately complex login system with interlinking interfaces implemented in this.
- infamia 3y ago
  Unpoly and Hotwire are somewhat similar to HTMX, but they update entire sections of a page (i.e., "page fragments") as you describe. They perform a DOM diff and update everything wrapped inside an HTML tag (e.g., a <div>) with a special attribute. Unpoly does this within the app's normal request/response cycle, while Hotwire uses websockets to stream updates. https://unpoly.com/tutorial https://unpoly.com/tutorial https://hotwired.dev/ https://hotwired.dev/
synergy20 3y ago
htmx is ajax wrapped in html to me. it does not work for resource restricted (i.e. embedded) devices where you just can't do server-side rendering, CSR SPA is the future there as the device side just need return some json data for browser to render.
- renerick 3y ago
  Htmx actually can be used with these restrictions, there is an extension to do client side rendering from a JSON response [1]. And you can make htmx send JSON requests instead of form data [2]. The idea is easily extendable to any template engine, so you can keep your device response minimal while enjoying the simplicity of htmx. I will admit though, this approach gets funky much faster, than returning HTML fragments, so you probably shouldn't exclusively build your app with this client-side-templates [1]: https://htmx.org/extensions/client-side-templates/ https://htmx.org/extensions/client-side-templates/ [2]: https://htmx.org/extensions/json-enc/ https://htmx.org/extensions/json-enc/
themaximalist 3y ago
I just started using HTMX in new projects and really like it. The LivewView/Hotwire/LiveWire way of building applications make a really great tradeoff—the ease of building websites with the speed and power of webapp UX. I wanted something simple to use with Express and it's been very productive. There's a few things to get used to, but overall like it and plan to keep using it in my projects.
knallfrosch 3y ago
HTMX Solution to keeping client and server in sync: Remove the client. Okay, now you have half the code base, but need a round trip to the server for every interaction. You could also remove the server and let people download your blog, where they can only post locally. No server-side input validation needed!
- manx 3y ago
  You can implement interactivity which doesn't need data from the server entirely client side. Libraries like https://alpinejs.dev https://alpinejs.dev help here and pair well with htmx.
tabtab 3y ago
I keep saying this and will say it again: what's really needed is a state-ful GUI markup language. HTML+DOM+JS+CSS is the wrong tool for the CRUD/GUI job, and force-fitting it has inflamed the area so bad many don't want to even try to scratch it. Bloated JS frameworks like Angular, React, Vue, and Electron have big learning curves and a jillion gotcha's because they have to reinvent long-known and loved GUI idioms from scratch, but DOM is inherently defective for that need, meant for static documents. There are just too many GUI needs that HTML/DOM lacks or can't do right: https://www.reddit.com/r/CRUDology/comments/10ze9hu/missing_or_defective_gui_idioms_in_htmldom/ https://www.reddit.com/r/CRUDology/comments/10ze9hu/missing_... Let's byte the bullet and create a GUI markup standard. Perhaps base it off Tk or Qt kits to avoid starting from scratch.
- CRConrad 3y ago
  > Let's byte the bullet and create a GUI markup standard. Heh, fun pun. > Perhaps base it off Tk or Qt kits to avoid starting from scratch. VCL / LCL.
manx 3y ago
It seems that many people are wondering why UI interactions, which don't need new data, should take a network roundtrip. You can avoid those round-trips by using a library like https://alpinejs.dev https://alpinejs.dev . It pairs well with htmx.
st3fan 3y ago
Phoenix Liveview is the future :-)
bioinformatics 3y ago
No, it’s not
elwell 3y ago
I don't like XML syntax.
- CRConrad 3y ago
  Yeah, frightfully verbose. (I suppose that's why JSON seems so much more popular nowadays; at the very least a large contributing cause.) But WTF does that have to do with anything here, which wasn't about XML at all?
  - elwell 3y ago
    HTMX is HTML is XML
shams93 3y ago
What isn't mentioned is how there are intrinsic security issues with server side templating, including htx. Part of the reason react won is it has the best track record for client security with complex client apps when its used and configured and deployed correctly. With server side templating its easy to fall victim to injection attacks.
lvh 3y ago
I don't disagree with the article, but I feel like the author almost landed on an interesting counterpoint. Author points out they didn't do this in ClojureScript, but writing apps in Reagent (the leading ClojureScript React wrapper) has looked almost identical across many years and many versions of React. Many of the state management epochs have also been avoided, because "manage state" is a core idea in Clojure, and so the stuff we had almost a decade ago is still perfectly fine today. So, I posit that the churn, while definitely real, is not actually intrinsic. Right now, at Latacora, we're writing a bunch of Clojure. That includes Clerk notebooks, some of which incorporate React components. That's an advantage I think we shouldn't ignore: not needing to write my own, say, Gantt chart component, is a blessing. So, specifically: not only do I think the churn is incidental to the problem, I don't even believe you need to give up compatibility to get it. Fun fact: despite all of this, a lot of what we're writing is in Clerk, and while that's still fundamentally an SPA-style combination of frontend and backend if you were to look at the implementation, it absolutely _feels_ like an htmx app does, in that it's a visualization of your backend first and foremost (React components notwithstanding).
AtlasBarfed 3y ago
ok look people. I think what is needed is to recognize that the SPA architecture isn't actually just a view processor. IMO it is a very shitty designed: View rendered <--> client process <--> server process So it seems that SPA apps load an absolute mountain of javascript into the view (the tab/page) and then that starts (crudely IMO) running as client-side daemon tracking messy state and interfacing with local storage, with javascript (opinion: yuck) ferreted away in a half dozen divs. IMO, what has been needed since you have local storage and local session state and all that is ... a client daemon that the web page talks to that offers data services, and then that client daemon if it needs server data calls to the internet. That way local state tracking, transformation, and maintenance can be isolated away from the code of the view. Large amounts of javascript (or maybe all with CSS wizardry is dropped). The "client daemon" can be coded in webassembly, so you aren't stuck with javascript (opinion: yuck). You can even have more efficient many views/tabs interfacing with the single client daemon, and the client daemon can track and sync data between different tabs/views/windows. Now, of course that is fucking ripe as hell for abuse, tracking. Not sure how to solve it. But "separation of concerns" in current web frameworks is a pipe dream.
exabrial 3y ago
Schemaless markup has lead us down a path where something is broken nearly all the time. I’d really rather see strongly typed markup that can easily be checked for correctness and who’s behavior is well defined. Something Modular too with profiles and designed for extensibility.
MattyRad 3y ago
> ... requires a full page refresh to use ... isn't good enough for many types of web-app we need to make. > without the annoying full-page load refresh. This fixation on the page refresh needs to stop. Nearly every single website which has purportedly "saved" page refreshes has brutalized every other aspect of the UX. This is a good article, and I agree that Htmx brings sanity back to the frontend, but somewhere along the line frontend folks got it in their head that page refreshes were bad, which is incorrect for essentially all CRUD / REST APIs. Unless you're specifically making a complex application that happens to be served through the web, like Kibana or Metabase, then stop harping on page refreshes. Even this article calls it the annoying refresh. Not the impediment refresh, or the derisive refresh, or the begrieved refresh. Moreover, what exactly is annoying about page refreshes? That there's a brief flash? That it takes ~0.3 seconds to completely resolve? Users don't care about page refreshes, and in fact they are an indication of normalcy. Upending the entire stack and simultaneously breaking expected functionally to prevent them is madness. The killer feature of Htmx is that it doesn't upend the entire stack, and you can optimize page refreshes relatively easily. That's great! But even then I'm still not convinced the tradeoff is worth it.
chenster 3y ago
Please make up our mind. Why can't we just make a decision and stick to it? It's like something comes alone everything 12 month and claims it is 'better'.
- tommica 3y ago
  Well, there is as many opinions as there is people, so consensus is a bit hard to reach...
tommica 3y ago
Htmx seems really nice,but as far as I can see, it is messy to implement some kind of a state, f.x a button that can only be pressed if the other forms on the page have been saved.
kurtextrem 3y ago
Back in the days, when JSON became popular as response type for rendering in the client, I saw arguments such as "the JSON payload is smaller than sending full HTML, so you pay the download only once instead of N times". Only once, because what has to be done with the JSON has been downloaded in the JS bundle. With full HTML, full HTML comes back in every response. However, I'm not sure if this is actually a problem or rather depends on how much interaction the user does (so where is the "turning point" of the overhead of having all in the bundle vs full HTML responses). What does everyone think?

836 points by quii 3y ago

Could you use htmx (or an extension?) to dynamically update SVG fragments? I.e., replicate the functionality of d3.js on the server side?

pier25 3y ago

Good luck with latency though for anything slightly interactive.

optymizer 3y ago

I remember fetching HTML from the server with AJAX and updating innerHTML before it was called AJAX. Is HTMX repackaging that or am I missing some exciting breakthrough here?

mlboss 3y ago
It is doing the same. Just makes cleaner and easier.
sourcecodeplz 3y ago
It is like that yes but more abstract because it uses some special HTML tags to make the JS calls. There is a big downside though: weak error handling. It just assumes that your call will get a response.
- bccdee 3y ago
  No, there're error events[1] which can be handled with a little bit of client-side scripting. [1]: https://htmx.org/events/#htmx:timeout https://htmx.org/events/#htmx:timeout

hashworks 3y ago

> It is very easy to support users who do not wish to, or cannot use JavaScript I don't get this. To use htmx one has to load 14 KB of gzipped JS. How does this make it easy to support clients that don't support JS?

akpa1 3y ago
Because HTMX is built around graceful fallbacks to standard features. For example, you can apply HTMX to a standard anchor tag and be able to tell if a request has come from HTMX on the server to tailor the response. Then, if the client supports HTMX, it'll prevent the default action and swap the content out, otherwise it'd do exactly what an anchor normally does. The same goes for form elements. If you're just a little bit careful about how you use HTMX, it gracefully falls back to standard behaviour very easily.

silver-arrow 3y ago

htmx has provided the greatest satisfaction and production of my 30-year programming career. After a year of constant development experience with it, I am confident that this is the proper method of building web applications. It truly is how HTML should have evolved.

WesSouza 3y ago

I’m currently writing HTMX is not the future and expect to be in the front page as well. Thank you.

_oyks 3y ago

Worth pointing out that Astro is already a good solution for this problem; can use it without touching client side libs

intellix 3y ago

Check out Qwik from builder.io

0xblinq 3y ago

No, it’s not.

isonfire36 3y ago

[dead]

fierce443 3y ago

[dead]

floufrouu121 3y ago

[dead]

styleslover123 3y ago

[dead]

genes123 3y ago

[dead]

genes123 3y ago

[dead]

styleslover123 3y ago

[dead]

guyracer5 3y ago

[dead]

guyracer5 3y ago

[dead]

facerracer45 3y ago

[dead]

facerracer45 3y ago

[dead]

guyracer54 3y ago

[dead]

guyracer54 3y ago

[dead]

bikerdude3 3y ago

[dead]

bikerdude3 3y ago

[dead]

virginvanilla1 3y ago

[dead]

virginvanilla1 3y ago

[dead]

hellobabe 3y ago

[dead]

hellobabe 3y ago

[dead]

babykins3 3y ago

[dead]

babykins3 3y ago

[dead]

buckshot53 3y ago

[dead]

buckshot53 3y ago

[dead]

darkhorse34 3y ago

[dead]

darkhorse34 3y ago

[dead]

gamersimmer1 3y ago

[dead]

gamersimmer1 3y ago

[dead]

happyjock1 3y ago

[dead]

happyjock1 3y ago

[dead]

bachelor6 3y ago

[dead]

bachelor6 3y ago

[dead]

boomn1x1 3y ago

[dead]

boomn1x1 3y ago

[dead]

isonfire36 3y ago

[dead]

missmischief4 3y ago

[dead]

missmischief4 3y ago

[dead]

workofgod43 3y ago

[dead]

workofgod43 3y ago

[dead]

lucky43 3y ago

[dead]

lucky43 3y ago

[dead]

fabulous345 3y ago

[dead]

fabulous345 3y ago

[dead]

fierce443 3y ago

[dead]

fashionista45 3y ago

[dead]

fashionista45 3y ago

[dead]

vogue567 3y ago

[dead]

vogue567 3y ago

[dead]

trueliving1 3y ago

[dead]

betches98 3y ago

[dead]

betches98 3y ago

[dead]

trueliving1 3y ago

[dead]

chillhouse54 3y ago

[dead]

chillhouse54 3y ago

[dead]

iamwell45 3y ago

[dead]

iamwell45 3y ago

[dead]

nitch7554 3y ago

[dead]

nitch7554 3y ago

[dead]

babynative54 3y ago

[dead]

babynative54 3y ago

[dead]

thedad46 3y ago

[dead]

thedad46 3y ago

[dead]

betches4534 3y ago

[dead]

betches4534 3y ago

[dead]

thedad4536 3y ago

[dead]

thedad4536 3y ago

[dead]

lyjules534 3y ago

[dead]

lyjules534 3y ago

[dead]

nitch654 3y ago

[dead]

nitch654 3y ago

[dead]

prada543 3y ago

[dead]

prada543 3y ago

[dead]

promax64 3y ago

[dead]

promax64 3y ago

[dead]

drunkbetch54 3y ago

[dead]

drunkbetch54 3y ago

[dead]

poemsporn1 3y ago

[dead]

poemsporn1 3y ago

[dead]

travelmore54 3y ago

[dead]

travelmore54 3y ago

[dead]

haveless54 3y ago

[dead]

haveless54 3y ago

[dead]

lusttforlife1 3y ago

[dead]

chillhouse7 3y ago

[dead]

chillhouse7 3y ago

[dead]

betches98 3y ago

[dead]

betches98 3y ago

[dead]

isonfire54 3y ago

[dead]

isonfire54 3y ago

[dead]

missmischief21 3y ago

[dead]

missmischief21 3y ago

[dead]

lusttforlife1 3y ago

[dead]

kong4523 3y ago

[dead]

kong4523 3y ago

[dead]

petter13123 3y ago

[dead]

petter13123 3y ago

[dead]

petter13 3y ago

[dead]

petter13 3y ago

[dead]

xoxogossip1 3y ago

[dead]

xoxogossip1 3y ago

[dead]

gypsyperson 3y ago

[dead]

gypsyperson 3y ago

[dead]

fabulous657 3y ago

[dead]

fabulous657 3y ago

[dead]

canyon12342 3y ago

[dead]

canyon12342 3y ago

[dead]

velvet564 3y ago

[dead]

velvet564 3y ago

[dead]

collective13 3y ago

[dead]

collective13 3y ago

[dead]

drunk2412 3y ago

[dead]

drunk2412 3y ago

[dead]

babycat 3y ago

[dead]

babycat 3y ago

[dead]

lyjules89 3y ago

[dead]

lyjules89 3y ago

[dead]

vogue134 3y ago

[dead]

vogue134 3y ago

[dead]

inkandfable1 3y ago

[dead]

inkandfable1 3y ago

[dead]

weworewhat1 3y ago

[dead]

weworewhat1 3y ago

[dead]

mystique54 3y ago

[dead]

mystique54 3y ago

[dead]

justonemore1 3y ago

[dead]

justonemore1 3y ago

[dead]

spicysugar1 3y ago

[dead]

spicysugar1 3y ago

[dead]

galaxy12 3y ago

[dead]

galaxy12 3y ago

[dead]

gypsysoul1 3y ago

[dead]

gypsysoul1 3y ago

[dead]

julesontour45 3y ago

[dead]

julesontour45 3y ago

[dead]

pinchofsalt2 3y ago

[dead]

pinchofsalt2 3y ago

[dead]

lustforlife1 3y ago

[dead]

lustforlife1 3y ago

[dead]

weworewhat9 3y ago

[dead]

weworewhat9 3y ago

[dead]

angelhearts1 3y ago

[dead]

angelhearts1 3y ago

[dead]

selfcare4yu1 3y ago

[dead]

selfcare4yu1 3y ago

[dead]

floufrouu121 3y ago

[dead]

morelight11 3y ago

[dead]

morelight11 3y ago

[dead]

reading1234 3y ago

[dead]

reading1234 3y ago

[dead]

livincool134 3y ago

[dead]

livincool134 3y ago

[dead]

smashfizzle12 3y ago

[dead]

smashfizzle12 3y ago

[dead]

terthanthesun1 3y ago

[dead]

terthanthesun1 3y ago

[dead]

thatnerdy12 3y ago

[dead]

thatnerdy12 3y ago

[dead]

angelhearts9 3y ago

[dead]

angelhearts9 3y ago

[dead]

smashfizzle7 3y ago

[dead]

smashfizzle7 3y ago

[dead]

monsoon11 3y ago

[dead]

monsoon11 3y ago

[dead]

blooms112 3y ago

[dead]

blooms112 3y ago

[dead]

floufrouu11 3y ago

[dead]

floufrouu11 3y ago

[dead]

morelight19 3y ago

[dead]

morelight19 3y ago

[dead]

sharinggenes1 3y ago

[dead]

indigosparkle1 3y ago

[dead]

indigosparkle1 3y ago

[dead]

morelight18 3y ago

[dead]

morelight18 3y ago

[dead]

advocates19 3y ago

[dead]

advocates19 3y ago

[dead]

selfcare111 3y ago

[dead]

selfcare111 3y ago

[dead]

yourblanks17 3y ago

[dead]

yourblanks17 3y ago

[dead]

butterflyeffec 3y ago

[dead]

butterflyeffec 3y ago

[dead]

lifebutterfly 3y ago

[dead]

lifebutterfly 3y ago

[dead]

gobblers1 3y ago

[dead]

gobblers1 3y ago

[dead]

livincool87 3y ago

[dead]

livincool87 3y ago

[dead]

selfcare11 3y ago

[dead]

selfcare11 3y ago

[dead]

reading87 3y ago

[dead]

reading87 3y ago

[dead]

flightsnot81 3y ago

[dead]

flightsnot81 3y ago

[dead]

doodles675 3y ago

[dead]

doodles675 3y ago

[dead]

indigosparkle7 3y ago

[dead]

indigosparkle7 3y ago

[dead]

morelight876 3y ago

[dead]

morelight876 3y ago

[dead]

monsoon654 3y ago

[dead]

monsoon654 3y ago

[dead]

indigosparkle6 3y ago

[dead]

indigosparkle6 3y ago

[dead]

fabulous13 3y ago

[dead]

fabulous13 3y ago

[dead]

champagne7 3y ago

[dead]

champagne7 3y ago

[dead]

flightsnot45 3y ago

[dead]

flightsnot45 3y ago

[dead]

isonfire11 3y ago

[dead]

isonfire11 3y ago

[dead]

aabbcc1241 3y ago

If you like the concept of putting some work back to the server instead of throwing to the client, you may also checkout the liveview approach. It drives the entire website using the server with realtime updates (similar interactivity as SPA) This approach has been implemented in most popular programming languages used for backend development: https://github.com/liveviews/liveviews https://github.com/liveviews/liveviews

dfabulich 3y ago

People were making this prediction ten years ago. It was wrong then, and it's wrong now. This article makes its case about Htmx, but points out that its argument applies equally to Hotwired (formerly Turbolinks). Both Htmx and Hotwired/Turbolinks use custom HTML attributes with just a little bit of client-side JS to allow client-side requests to replace fragments of a page with HTML generated on the server side. But Turbolinks is more than ten years old. React was born and rose to popularity during the age of Turbolinks. Turbolinks has already lost the war against React. The biggest problem with Turbolinks/Htmx is that there's no good story for what happens when one component in a tree needs to update another component in the tree. (Especially if it's a "second cousin" component, where your parent component's parent component has subcomponents you want to update.) EDIT: I know about multi-swap. https://htmx.org/extensions/multi-swap/ https://htmx.org/extensions/multi-swap/ It's not good, because the onus is on the developer to compute which components to swap, on the server side, but the state you need is usually on the client. If you need multi-swap, you'll find it orders of magnitude easier to switch to a framework where the UI is a pure function of client-side state, like React or Svelte. Furthermore, in Turbolinks/Htmx, it's impossible to implement "optimistic UI," where the user creates a TODO item on the client side and posts the data back to the server in the background. This means that the user always has to wait for a server round trip to create a TODO item, hurting the user experience. It's unacceptable on mobile web in particular. When predicting the future, I always look to the State of JS survey https://2022.stateofjs.com/en-US/libraries/front-end-frameworks/ https://2022.stateofjs.com/en-US/libraries/front-end-framewo... which asks participants which frameworks they've heard of, which ones they want to learn, which ones they're using, and, of the framework(s) they're using, whether they would use it again. This breaks down into Awareness, Usage, Interest, and Retention. React is looking great on Usage, and still pretty good on Retention. Solid and Svelte are the upstarts, with low usage but very high interest and retention. Htmx doesn't even hit the charts. The near future is React. The further future might be Svelte or Solid. The future is not Htmx.

recursivedoubts 3y ago
never tell me the odds, kid https://htmx.org/img/memes/whowillwin.png https://htmx.org/img/memes/whowillwin.png
3y ago

rektide 3y ago

Personally I believe strongly in thick clients but this is a pretty neat demo anyways. I see a lot of resemblance to http://catalyst.rocks http://catalyst.rocks with WebComponents that target other components. I think there's something unspoken here that's really powerful & interesting, which is the declarativization of the UI. We have stuff on the page, but making the actions & linkages of what does what to what has so far been trapped in code-land, away from the DOM. The exciting possibility is that we can nicely encode more of the behavior into the DOM, which creates a consistent learnable/visible/malleable pattern for wiring (and rewiring) stuff up. It pushes what hypermedia can capture into a much deeper zone of behaviors than just anchor-tag links (and listeners, which are jump points away from the medium into codespace).

CRConrad 3y ago
> ...declarativization of the UI. We have stuff on the page, but making the actions & linkages of what does what to what has so far been trapped in code-land, away from the DOM. The exciting possibility is that we can nicely encode more of the behavior into the DOM, which creates a consistent learnable/visible/malleable pattern for wiring (and rewiring) stuff up. Web “app” development finally catching up to where Visual Basic and Delphi were ~30 years ago, hurrah!
haolez 3y ago
Catalyst looks nice! What's the downside? Is it dead?
- rektide 3y ago
  Catalyst is great. Definitely active, actively used, last updates in main were late February. They have a big 2.0 branch that has a ton of internal changes. TypeScript 5.0 finally updated to support modern @decorator syntax & they're rewriting a bunch to support that, which is excellent.
wwweston 3y ago
> the declarativization of the UI Yes! There's always going to be some range of client behavior that's difficult to reduce to declarations, but so much of what we do is common that if it isn't declarative we're repeating a lot of effort. And in general I think you're describing a big part of what made the web successful in the first place; the UI-as-document paradigm was declarative, accessible, readable, repeatable.

obpe 3y ago

It's kinda funny to me that many of the "pros" of this approach are the exact reasons so many abandoned MPAs in the first place. For instance, a major selling point of Node was running JS on both the client and server so you can write the code once. It's a pretty shitty client experience if you have to do a network request for each and every validation of user input. Also, there was a push to move the shitty code from the server to the client to free up server resources and prevent your servers from ruining the experience for everyone. We moved away for MPAs because they were bloated, slow and difficult to work with. SPAs have definitely become what they sought to replace. But that isn't because of the technology, it's because all the devs writing shitty MPAs are now writing shitty SPAs. If this becomes popular, they will start writing shitty MPAs again. Nothing about this technology will stop that.

sublinear 3y ago
> all the devs writing shitty MPAs are now writing shitty SPAs drain the swamp man
hombre_fatal 3y ago
> For instance, a major selling point of Node was running JS on both the client and server so you can write the code once. (I'm not actually arguing with you, just thinking out loud) This is often repeated but I don't think it even close to a primary reason. The primary reason you build JS web clients is for the same reason you build any client: the client owns the whole client app state and experience. It's only a fluke of the web that "MPA" even means anything. While it obviously has its benefits, we take for granted how weird it is for a server to send UI over the wire. I don't see why it would be the default to build things that way except for habit. It makes more sense to look at MPA as a certain flavor of optimization and trade-offs imo which is why defaulting to MPA vs SPA never made sense now that SPA client tooling has come such a long way. For example, SPA gives you the ability to write your JS web client the same way you build any other client instead of this weird thing where a server sends an initial UI state over the wire and then you add JS to "hydrate" it, and then ensuring the server and client UIs are synchronized. Htmx has similar downsides of MPAs since you need to be sure that every server endpoint sends an html fragment that syncs up to the rest of the client UI assumptions. Something as simple as changing a div's class name might incur html changes across many html-sending api endpoints. Anyways, client development is hard. Turns out nothing was a panacea and it's all just trade-offs.

Pet_Ant 3y ago

The problem is that these kind of approaches require more upfront thought, which produces less now, and pays off later... and only if maintained by people in tune with the original design. I've seen this architectures quickly ruined by 'can-do' people who butcher everything to get a feature done _and_ get a bonus from the management for quick delivery.

727564797069706 3y ago
In my experience, these 'can-do' people can (and usually will) butcher anything, be it MPA, SPA or TUI. This seems like the real problem we need to solve, but not sure how?
- aidenn0 3y ago
  I suppose we could stop rewarding people for delivering features that customers want...
  - Pet_Ant 3y ago
    Or make them accountable for long term consequences. It’s no different than CEOs cutting R&D and calling a profit. Deferred bonuses till a 3 year post mortem would help.

poidos 3y ago

I’ve been using HTMX (from Clojure) for projects recently and I have to say I like it a lot. Full-stack web stuff is a hobby for me and I always had trouble really grokking all the parts of SPAs. HTMX fits neatly into my brain’s model of how websites should work.

phpnode 3y ago

Title needs (2011). Not because that's when it was written but because that's when this technique was the future.

recursivedoubts 3y ago
we are going to go back back to the future

mikece 3y ago

"You can use whatever programming language you like to deliver HTML, just like we used to." Is this suggesting writing any language we want in the browser? I have wondered for a couple decades why Python or some other open source scripting language wasn't added to browsers. I know Microsoft supported VBScript as an alternative to JavaScript in Internet Explorer and had it not been a security nightmare (remember the web page that would format your hard drive, anyone?) and not a proprietary language it might have a rival to JavaScript in the browser. In those days it wouldn't have taken much to relegate JavaScript to non-use. Today we just get around it by compiling to WASM.

loloquwowndueo 3y ago
It is not suggesting that. On the server, you can use your language of choice to generate complete or partial HTML responses to be sent and then put in the right places on the page by JavaScript (htmx) running on the browser.
biorach 3y ago
> Is this suggesting writing any language we want in the browser? Nope, server
traverseda 3y ago
It is not suggesting running arbitrary languages in the browser. It's basically Ajax.
- avisser 3y ago
  Commenting on "It's basically Ajax": Yes, and it's also a return to the basics of a browser. Making HTTP calls (Hypertext Transfer Protocol) to get HTML (the aforementioned Hypertext) and rendering it is the core thing that browsers do. It's both necessary and sufficient to being a browser.
- mikece 3y ago
  I hope the execution is better than Ajax! They way that was implemented in WebForms was horrible and a complete PITA to debug.

aidenn0 3y ago

> Managing state on both the client and server This is a necessity as long as latencies between the client and server are large enough to be perceptible to a human (i.e. almost always in a non-LAN environment). [edit] I also just noticed: > ...these applications will be unusable & slow for those on older hardware or in locations with slow and unreliable internet connections. The part about "slow and unreliable internet connections" is not specific to SPAs If anything a thick client provides opportunities to improve the experience for locations with slow and unreliable internet connections. [edit2] > If you wish to use something other than JavaScript or TypeScript, you must traverse the treacherous road of transpilation. This is silly; I almost exclusively use compiled languages, so compilation is happening no matter what; targeting JS (or WASM) isn't that different from targeting a byte-code interpreter or hardware... -- I like the idea of HTMX, but the first half of the article is a silly argument against SPAs. Was the author "cheating" in the second half by transpiling clojure to the JVM? Have they tested their TODO example on old hardware with an unreliable internet connection?

8organicbits 3y ago
> a thick client provides opportunities to improve the experience for locations with slow and unreliable internet connections. The word "slow" here is unclear. Thick clients work poorly on low bandwidth connections, as the first load takes too long to download the JS bundle. JS bundles can be crazy big and may get updated regularly. A user may give up waiting. Thin clients may load faster on low bandwidth connections as they can use less javascript (including zero javascript for sites that support progressive enhancement, my favorite as a NoScript user). Both thin and thick clients can use fairly minimal data transfer for follow-up actions. An HTMX patch can be pretty small, although I agree the equivalent JSON would be smaller. If "slow" means high latency, then you're right, a thick client can let the user interact with local state and the latency is only a concern when state is being synchronized (possibly with a spinner, or in the background while the user does other things). Unreliable internet is unclear to me. If the download of the JS bundle fails, then the thick client never loads. A long download time may increase the likelihood of that happening. Once both are loaded, the thick client wins as the user can work with local state. Both need to sync state sometimes. The thin client probably needs the user to initiate retry (a poor experience) and the thick client could support retry in the background (although many don't support this).

brushfoot 3y ago

I use tech like HTMX because, as a team of one, I have no other choice. I tried using Angular in 2019, and it nearly sank me. The dependency graph was so convoluted that updates were basically impossible. Having a separate API meant that I had to write everything twice. My productivity plummeted. After that experience, I realized that what works for a front-end team may not work for me, and I went back to MPAs with JavaScript sprinkled in. This year, I've looked at Node again now that frameworks like Next offer a middle ground with server-side rendering, but I'm still put off by the dependency graphs and tooling, which seems to be in a constant state of flux. It seems to offer great benefits for front-end teams that have the time to deal with it, but that's not me. All this to say pick the right tool for the job. For me, and for teams going fuller stack as shops tighten their belts, that's tech like HTMX, sprinkled JavaScript, and sometimes lightweight frameworks like Alpine.

ademup 3y ago
Your story sounds similar to mine, and your choice to use HTMX has me motivated to check it out. The sum total of my software supports 5 families' lifestyles entirely on LAMP MPAs with no frameworks at all. Thanks for posting.
scoofy 3y ago
I use htmx on my current project, and it's like a dream. I'm happy to sacrifice a bit of bandwidth to be able to do all the heavy lifting in python. On top of that, it makes testing much much easier since it turns everything is GET and POST requests. I'd add a couple features if I were working there (making css changes and multiple requests to multiple targets standard), but as it stands, it's a pleasure to work in.
- niux 3y ago
  What framework do you use for Python?
  - scoofy 3y ago
    Flask

nawgz 3y ago

I'm sorry, but these arguments are so tired. > SPAs have allowed engineers to create some great web applications, but they come with a cost: > Hugely increased complexity both in terms of architecture and developer experience. You have to spend considerable time learning about frameworks. Yes, better quality software usually packages a bit more complexity. SPAs are popular, just like native apps, because people don't like jarring reloads. Webviews in native apps are panned for a reason; turning your whole app into a series of webviews would be stupid, right? > Tooling is an ever-shifting landscape in terms of building and packaging code. I've used these 4 libraries to build apps since 2015: * React * MobX * D3 * Webpack The only one I have had pain with is react-router-dom, which has had 2 or 3 "fuck our last approach" refactors in this time. And I added TypeScript in 2018. PEBCAK > Managing state on both the client and server It's a lie that a thin client isn't managing state; it's just doing a static, dumb job of it. Imagine some cool feature like... collaborative editing. How would you pull that off in HTMX? > Frameworks, on top of libraries, on top of other libraries, on top of polyfills. React even recommend using a framework on top of their tech: Yes, React is famously not a batteries-included library, while Angular is. But, as addressed, you need about 3 other libraries. Besides, did you know: HTMX is also a framework. Did you know: HTMX also has a learning curve. Did you know: HTMX forces you to be able to manipulate and assemble HTMLstrings in a language that might not have any typing or tooling for that? Anyways, I've said enough. I should've just said what I really think: someone who can't even get their nested HTML lists to actually indent the nesting shouldn't give advice on building UIs.

traverseda 3y ago
>Imagine some cool feature like... collaborative editing. What are you gaining by writing something like that in java/type-script rather than like rust and webassembly? To me javascript is in a sort of uncanny valley where you probably want to be either making a real app and compiling it to wasm or using something like htmx.
- nawgz 3y ago
  > rather than like rust and webassembly WASM can't even interact with the DOM, how exactly are these languages positioned better to give me access to a ton of UI primitives? The backend can be a fast language, certainly, but the browser is a premier UI platform... and it's powered by JS... To me, Rust developers thinking they know how to build UIs is the real uncanny valley. What they produce looks like it should work, but the more you look at it, the more you realize they don't know what UX stands for

jimmaswell 3y ago

I've made my personal website something of a hybrid SPA. WithJS enabled it only loads and replaces the relevant portions of the page, but a page renders fully from PHP going to it directly. Relevant code: https://github.com/ldyeax/jimm.horse/blob/master/j/j.php https://github.com/ldyeax/jimm.horse/blob/master/j/j.php https://github.com/ldyeax/jimm.horse/blob/master/j/component/header.js#L68 https://github.com/ldyeax/jimm.horse/blob/master/j/component... The JS would be a bit more elegant if script tags didn't need special handling to execute on insertion. The experience is very seamless this way - I'm very pleased with it. It's live at https://jimm.horse https://jimm.horse - the dynamic behavior can be found clicking on the cooking icon or N64 logo. On reading the article, I'll definitely make use of this if it becomes well-supported. It does exactly what I wanted here.

EGreg 3y ago

We spent 12 years on https://qbix.com/platform https://qbix.com/platform and along the way saw a lot of fads come and go. At one point we experimented with the server returning the stuff to replace the HTML with. We support that in our framework natively (through a mechanism called “slots”). That said, I have come to believe that people this decade will (and should) invert the idea of progressive enhancement to be client-first. Imagine your site being composed of static files (eg served on Hypercore or IPFS via beaker browser). As more people use it, the swarm grows. No worries about being DDOSed. No having to trust a server to not send you the wrong interface one day. The software is yours. It just got delivered via a hypercore swarm or whatever, and your client checked the Merkle trees to prove it hasn’t been tampered with. The you just interact eith a lot of headless web services. Rather than bearer tokens and cookies, you can use webauthn and web crypto to sign requests with private keys. You can do a lot more. And you store your data WHERE YOU WANT. Sure, htmx can be used there. But there, too, it’s better to fetch JSON and interpret it on the client. Returning markup language like HTML actually mixes data with presentation. Consider what happens when you want to return a lot of rows. With JSON, you return just the structured content. With HTML, there is a lot of boilerplate <li class=“foo” onclick=“…”> mixed in there which is a lot of extra weight on the wire. If you are interested in learning more, I gave a whole talk about it: https://qbix.com/blog/2020/01/02/the-case-for-building-client-first-web-apps/ https://qbix.com/blog/2020/01/02/the-case-for-building-clien...

sublinear 3y ago

> SPAs have allowed engineers to create some great web applications, but they come with a cost: ... Managing state on both the client and server Having a separation of concerns between server and client is the whole point, and replacing JSON APIs with data trapped in HTML fragments is a massive step backwards.

recursivedoubts 3y ago
https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/
- dalmo3 3y ago
  So, by your own words, in htmx: > the new API is simply reflected in the new HTML returned by the server Whereas with SPAs (my words) > the new API is simply reflected in the new json returned by the server I think I prefer the mental model of the api serving data and client rendering it.
  - CRConrad 3y ago
    HTML is the data format of Web pages. That's what the client, the browser, is built to render.
- sublinear 3y ago
  What if we need the same backend to be usable by more than one client? What if those clients aren't even a SPA, but a wrapper library, or a native app? What if we need internal scripts that manage the content in the backend using the same API? What if we need to redesign the client without touching the backend? HTMX doesn't address any of that. YAGNI is often only true for the original developers, not everyone else who has to maintain it long term.
  - recursivedoubts 3y ago
    In the article I recommend splitting your hypermedia and data APIs up into two separate concerns. The data API can address all of the concerns you have. The hypermedia API, being consumed by an htmx front end, can then take advantage of the strengths of hypermedia (e.g. the uniform interface giving you a lot of flexibility in aggressively refactoring your API.) Please, read the article.

pictur 3y ago

If your project consists of a todo list, these tools will do the trick. but they are useless for projects with larger and more complex needs. and yes, there may be cases where it doesn't work in frameworks like nextjs and you need to apply hacky solutions. but I don't see even libraries like nextjs being so self-praising. Come on, folks, there's no point in praising a small package that can do some operations through the attribute. It is inevitable that the projects developed with this package will become garbage when the codebase grows. because that doesn't exist in the development logic. It's nothing more than a smug one-man's entertainment project. sorry but this is the truth.

jcpst 3y ago
I don’t understand how it’s inevitable that projects using this package will become garbage when the codebase grows. It looks like reasonable patterns could be built around it. Am I missing something?
infamia 3y ago
You can always incrementally add dynamic features using web components when HTMX and similar things aren't a good fit. It doesn't have to be either HTMX or JS-first frameworks. Our industry's fixed mindset of JS/React vs. Hypermedia (e.g., HTMX/Hotwire/Unpoly) needs to change.
- pictur 3y ago
  I am not for or against anything. I don't live in a fantasy world like in the article. I want to talk about real world problems, not dreams.
  - infamia 3y ago
    A Real World React -> htmx Port https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/

vp8989 3y ago

1) "Web application development" doesn't happen in a vacuum. Often it happens in contexts where the "backend" is also consumed by various non-web applications. In those contexts, collapsing the frontend and backend back into 1 component is less of the slam dunk than it's made out to be in this post. 2) The missing piece is how you can achieve this "collapsing" back of functionality into single SSR deployable(s) while still preserving the ability to scale out a large web application across many teams. Microfrontends + microservices could be collapsed into SSR "microapplications" that are embedded into their hosting app using iframes?

chrislan815 3y ago

Yeah HTMX is nice; I'm still learning about it. I'm building a django app for https://host.upcyclebikes.co/listings/allll https://host.upcyclebikes.co/listings/allll and i'm slowly introducing htmx into it.

recursivedoubts 3y ago

i am the creator of htmx, this is a great article that touches on a lot of the advantages of the hypermedia approach (two big ones: simplicity & it eliminates the two-codebase problem, which puts pressure on teams to adopt js on the backend even if it isn't the best server side option) hypermedia isn't ideal for everything[1], but it is an interesting & useful technology and libraries like htmx make it much more relevant for modern development we have a free book on practical hypermedia (a review of concepts, old web 1.0 style apps, modernized htmx-based apps, and mobile hypermedia based on hyperview[2]) available here: https://hypermedia.systems https://hypermedia.systems [1] - https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ [2] - https://hyperview.org/ https://hyperview.org/

tkgally 3y ago
I didn’t know what HTMX was and couldn’t figure it out from the comments here, so I went to htmx.org. This is what I saw at the top of the landing page: > introduction > htmx gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hypertext > htmx is small (~14k min.gz’d), dependency-free, extendable, IE11 compatible & has reduced code base sizes by 67% when compared with react This tells me what htmx does and what some of its properties are, but it doesn’t tell me what htmx is! You might want to borrow some text from your Documentation page and put something like the following at the top of your homepage: “htmx is a dependency-free, browser-oriented javascript library that allows you to access modern browser features directly from HTML.”
149203 3y ago
Every company I've been a part of has redesigned their front end at least once. These redesigns would be a lot more difficult if we had to edit HTML on the client and the HTML that a server returns. Also, HTMX is best styled with semantic classes. Which is a problem for companies using Tailwind and utility classes in their HTML. With class-heavy HTML it's nearly impossible to redesign in two different places. And performance suffers and returning larger chunks of HTML. Despite all that, I want HTMX to be the standard way companies develop for the web. But these 2 problems need to be addressed first, I feel, before companies (like mine) take the leap.

deleted 3y ago

[deleted]

eimrine 3y ago

> Some SPA implementations of SPA throw away progressive enhancement (a notable and noble exception is Remix). Therefore, you must have JavaScript turned on for most SPAs. Is this really the future?

Veuxdo 3y ago

I like how the cons of SPA are "you have to manage state" and "clients have to execute code". I mean, aren't these baseline "get computers to do stuff" things?

chasd00 3y ago
back in the olden days a web browser was largely considered just a program to read documents stored on other systems that can be linked to each other sent over a simple stateless protocol. Then we started to be able to collect user input, then a hack was invented to maintain state between requst/response pairs (cookies), then a scripting language etc There are many use cases out there where not treating a browser as a container to run an actual application is the right way to go. On the other hand, there's many use cases where you want the browser to be, basically, a desktop app container. The big bold letters at the top of the article declaring htmlx is the future is a bit much. It has its place and maybe people are re-discovering it but it's certainly not the future of web development IMO. The article gives me kind of web dev career whiplash.
- 0x445442 3y ago
  When do you want the browser to be anything more than a hypertext document viewer and why?
  - dalmo3 3y ago
    Roughly every time I can use something by just typing some words instead of downloading a .exe.
    - mdaniel 3y ago
      Or its close friend: when I want to use the data or customize the UI via `document.querySelectorAll`
zerkten 3y ago
Why do things in two places when you can do it all in one place? This isn't limited to computers, but unless you are getting specific benefits, it isn't wise to continue with a SPA approach. We had the same and worse problems with "thick clients" that came before the web grew. With the right requirements, team, tools etc., you could sometimes build great apps. This was incredibly difficult and the number of great apps was relatively small. Building with earlier server-side web tech, like PHP, isolated everything on the server and it was easier to iterate well than with the "thick clients" model. SPA reinvents "thick clients" to some degree and brings back many of the complications. No one should claim you can't build a great SPA, or that they have few advantages, but the probability of achieving success is frequently lower. Frameworks try to mitigate these concerns, but you are still only moving a closing some of the gaps and the probability of failure remains higher. Depending on the app you can move the success metrics, but we often end up fudging on items like performance. We get to a point where there is current model is fraying and energy builds to replace it with something else. We end up going back to old techniques, but occasionally we learn from what was done before. I find that it's surprisingly rare for people with 1-2 years of experience to be able to give an accurate overview of the last 10 years of web development. A better understanding of this history can help with avoiding (or targeting) problems old timers have encountered and complain about in comments.

peter_retief 3y ago

I like htmx but have decided to use unpoly, for my current project, which is similar. The concept is great but why has it taken so long? https://unpoly.com/ https://unpoly.com/

mtlynch 3y ago

I really want to switch over to htmx, as I've moved away from SPAs frameworks, and I've been much happier. SPAs have so much abstraction, and modern, vanilla JavaScript is pretty decent to work with. The thing that keeps holding me back from htmx is that it breaks Content Security Policy (CSP), which means you lose an effective protection against XSS.[0] When I last asked the maintainer about this, the response was that this was unlikely to ever change.[1] Alpine.js, a similar project to htmx, claims to have a CSP-compatible version,[2] but it's not actually available in any official builds. [0] https://htmx.org/docs/#security https://htmx.org/docs/#security [1] https://news.ycombinator.com/item?id=32158352 https://news.ycombinator.com/item?id=32158352 [2] https://alpinejs.dev/advanced/csp https://alpinejs.dev/advanced/csp [3] https://github.com/alpinejs/alpine/issues/237 https://github.com/alpinejs/alpine/issues/237

jeremyjh 3y ago
Alpine is a lightweight client side framework, not really at all equivalent to htmx.
- mtlynch 3y ago
  I'm not sure what you mean. htmx and alpine.js are both client-side frameworks. To me, they seem to have similar goals and similar functionality. What do you see as the difference?
  - jeremyjh 3y ago
    The purpose of htmx is to enable the server to send fragments of markup to update the dom in response to UI events. Alpine.is is purely client side, you may not even have an application server.
    - mtlynch 3y ago
      Oh, I didn't realize that. Thanks!
  - summarity 3y ago

joseph_grobbles 3y ago

[dead]

lofaszvanitt 3y ago

.. in an alternate universe.

iamsaitam 3y ago

"If you wish to use something other than JavaScript or TypeScript, you must traverse the treacherous road of transpilation." -- this is the crux of the article. These kind of takes fall in the bullseye of "I don't want to program with Javascript". The subtext is all about this. Perhaps.. maybe.. Htmx won't be the future because there are a lot of people that like programming in Javascript?

deleted 3y ago

[deleted]

tedunangst 3y ago

How does this differ from what we called rehydration a decade ago?

CRConrad 3y ago
If nothing else, it's less of a silly moniker: Why would I want to get my Web page wet in the first place?!? Remember, DRY!

lucidguppy 3y ago

HTMX brings new life to tech like django which can catapult MVPs into production asap. Backend engineers are now able to write management tools and experimental products faster - and then pass the winning products off to a fluttr team to code for all environments. The backend could be converted into a django rest api if the code is properly refactored.

themodelplumber 3y ago

Thanks for the reminder, I've been meaning to try it out. Just to get started, I asked ChatGPT to write an htmx app to show a 10-day weather forecast. It described the general steps and seemed to be able to describe how htmx works pretty well, including hx-get and hx-target, etc., but then said "As an AI language model, I am not able to write full applications with code". I replied "do the same thing in bash" (which I knew would be different in significant ways, but just to check) and it provided the code. I wonder, is this a function of recency of htmx or something else? Do other htmx developers encounter this? I imagine it's at least a little bit of a pain for these boilerplate cases, if it's consistent vs. access to the same GPT tooling for other languages.

yawaramin 3y ago
You can write an htmx app in bash: https://www.youtube.com/watch?v=Jzcu4JheCtY https://www.youtube.com/watch?v=Jzcu4JheCtY
- themodelplumber 3y ago
  So are you saying that ChatGPT will probably offer to write an htmx app in bash? > I'm sorry, but it's not possible to write a weather forecast app using bash and htmx as htmx is a client-side technology and bash is a command-line shell. htmx is typically used in conjunction with HTML and JavaScript to create dynamic web applications. Cuz that didn't work. It straight up forged ahead and wrote a bash script to show the weather though. I really wonder today if ChatGPT is going to cause a bash renaissance (If you are telling me I can do this myself plz reread posts thx)
listenallyall 3y ago
HTMX is quite easy to code. Your prompt sounds rather generic, I mean, you can just serve 10 days of weather forecasts without any interaction whatsoever. https://www.wunderground.com/forecast/us/ak/north-pole https://www.wunderground.com/forecast/us/ak/north-pole It isn't clear what you were asking ChatGPT to provide, therefore not surprised it didn't come up with the exact answer you expected. I'd suggest learning HTMX by reading the docs, the majority is just a single page.

Alifatisk 3y ago

Can we count in Hotwire, inertiajs, Alpinejs, unpolyjs aswell?

honkycat 3y ago

Lol, we're still having the SPA discussion 7 years later in the year of our lord 2023? Talk about the positives of YOUR approach, don't tear down a different approach that half the industry is using. You're not going to say anything new or interesting to the person you are trying to convince this way. Experienced engineers already know the trade-offs between an SPA and a server rendered experience.

CRConrad 3y ago
> Talk about the positives of YOUR approach, don't tear down a different approach that half the industry is using. AIUI TFA wasn't by the creators of HTMX, so it isn't the author's approach.

toastercat 3y ago

Does anyone have an example Hacker News client written in HTMX?

majormajor 3y ago

> HTMX allows you to design pages that fetch fragments of HTML from your server to update the user's page as needed without the annoying full-page load refresh. I've been on the sidelines for the better part of a decade for frontend stuff, but I was full-stack at a tiny startup in 2012ish that used Rails with partial fragments templates for this. It needed some more custom JS than having a "replacement target" annotation everywhere, but it was pretty straightforward, and provided shared rendering for the initial page load and these updates. So, question to those who have been active in the frontend world since then: that obviously failed to win the market compared to JS-first/client-first approaches (Backbone was the alternative we were playing with back then). Has something shifted now that this is a significantly more appealing mode? IIRC, one of the big downsides of that "partial" approach in comparison with SPA-approaches was that we had to still write those JSON-or-XML-returning versions of the endpoints as mobile clients became more prevalent. That seems like it would still be an issue here too.

dpistole 3y ago
From a front end perspective I think the selling points I see pitched for these new server side frameworks are "SEO" and "speed". SEO I personally think is a questionable motivation except in very specific use cases. Speed is almost compelling but the complexity cost and all the considerations around how a page is structured (which components are server, which are client, etc) does not seem worth the complexity cost IMO. Just pop a loading animation up in most cases IMO. I think I'm stuck somewhere in the middle between old-hacker-news-person yelling "lol were just back at index.html" and freshly-minted-youtube-devs going "this is definitely the new standard".
efields 3y ago
FE dev/manager here. I'll tackle this one out of order. > one of the big downsides of that "partial" approach in comparison with SPA-approaches was that we had to still write those JSON-or-XML-returning versions of the endpoints as mobile clients became more prevalent. That seems like it would still be an issue here too. Yup. Still, if you're at the scale where you need to support multiple clients, things should be going well enough where you can afford the extra work. As soon as multiple clients are involved, you're writing SOMETHING to support specifically that client. 10+ years ago, you'd be writing those extra conditionals to return JSON/XML _and_ someone is building out this non-browser client (mobile app, third party API, whatever). But you're not rearchitecting your browser experience so that's the tradeoff. > Has something shifted now that this is a significantly more appealing mode? React especially led from one promise to another about _how much less code_ you'd have to write to support a wide range of clients, when in reality there was always another configuration, another _something_ to maintain when new clients were introduced. On top of that, the mobile device libraries (React Native, etc), were always steps behind what a true native app UX felt like. I think a lot of us seasoned developers just feel burned by the SPA era. Because of how fast it is to iterate in js, places like npm would seemingly have just the right component needed to avoid having to build custom in-house, and its simply an `npm add` and an import away. Meanwhile, as the author states, React and company changed a lot under the hood rapidly, so dependencies would quickly become out of date, now trying to maintain a project full of decaying 3rd party libs because its own tech debt nightmare. Just for, say, popper.js or something like that. I'm just glad the community seems to actively be reconsidering "the old ways" as something valuable worth revisiting after learning what we learned in the last decade.

tgbugs 3y ago

I first encountered the principles behind htmx in its precursor intercooler.js. Those principles really resonated with my distaste for complexity. Amusingly I found out about htmx itself when rereading https://grugbrain.dev https://grugbrain.dev and it all clicked! htmx is crystal that trap internet complexity demon!

fredrikholm 3y ago
Irony that they're all made by the same person!

nologic01 3y ago

htmx got a lot of good press (deservedly) but I think somehow it needs to get to the next step beyond the basic hypermedia evangelism. I don't know exactly what that step needs to be, because I don't know what a fully "htmx-ed" web would look like. It is promising, but that promise must be made more concrete. A conceptual roadmap of where this journey could take us and, ideally, some production quality examples of solving important problems in a productive and fun way would increase the fan base and mindshare. Even better if it show how to solve problems we didn't know we had :-). I mean the last decade has been pretty boring in terms of opening new dimensions. Just my two cents.

minusf 3y ago
htmx never claimed it's the solution for everything. there is no next conceptual step. it's sending snippets of html to the client. i read most htmx threads on hn and it's clear that people are looking for alternatives from react et al. they have a quick look, maybe implement an example and they are angry that it can't do everything they want cause the js ecosystem fatigue is real. the centerpiece of the htmx site is an actual in-production app that was converted from react and it's better because of that. again, it will not be everybody's case. htmx will let a lot of developers go all the way without bringing node into their ruby/python/php world for certain workloads. for them it is the future. the rest should stop reading.
- lakomen 3y ago
  the title is literally "htmx is the future"... If htmx wants to be the future it needs to be wrapped in a SSR framework. One that performs well.

s1k3s 3y ago

Love articles like this because I know there's some manager somewhere who will read this and force it upon their team without having any idea if it's good or not. And in 3 years we'll have people from those teams complaining about HTMX because it's not suited for their projects. The future is whatever works best for your use-case.

0xbadcafebee 3y ago

I just want Visual Basic for the web man. Screw writing lines of code. I want to point and click, drop complex automated objects onto a design, put in the inputs and outputs, and publish it. I don't care how you do it, I don't want to know any of the details. I just want to be able to make things quickly and easily. I don't care about programming, I just want to get work done and move on with my life. At this rate, when I'm 80 years old we will still be fucking around with these stupid lines of code, hunched over, ruining our eyesight, becoming ever more atrophied, all to make a fucking text box in a monitor pop some text into a screen on another monitor somewhere else in the world. It's absolutely absurd that we spend this much of our lives to do such a dumb thing, and we've been iterating on it for five decades, and it's still just popping some text in a screen, but we applaud ourselves that we're so advanced now because something you can't even see is doing something different in the background.

CRConrad 3y ago
> I just want Visual Basic for the web man. Screw writing lines of code. I want to point and click, drop complex automated objects onto a design, put in the inputs and outputs, and publish it. I don't care how you do it, I don't want to know any of the details. Do an Internet search for “Quartex Pascal”, and/or its creator, Jon Aasenden. He has a blog on WordPress, and a Facebook group. His crazy Quartex project is apparently nearing completion. It's an Object Pascal compiler and IDE — kind of a Delphi / Lazarus clone, if you will — that compiles to JavaScript, for the end product to be run in the browser. I think that's as close to “Visual Basic for the web” as one can get.
neurostimulant 3y ago
So, do you want to run a winform app in a browser? Behold! https://github.com/roozbehid/WasmWinforms https://github.com/roozbehid/WasmWinforms https://news.ycombinator.com/item?id=18981806 https://news.ycombinator.com/item?id=18981806
revelio 3y ago
There's a lot of low-code platforms that do that.
3y ago

jksmith 3y ago

You know, nobody likes this argument, but desktop is still just better. Yeah, yeah, the updates, security issues, I get it, but the tools are simple better, render faster, better functionality/complexity ratio, less gnashing of teeth.

lolinder 3y ago
Desktop on which OS? Using what GUI framework? The web is a single platform, but the desktop developer experience seems to vary wildly depending on the OS. I'm genuinely curious what OS and tooling you use that you find so much better, because every time I've tried desktop development I eventually give up and go back to the web. It might be because Linux support is always a requirement for me.
- jksmith 3y ago
  Both Delphi and FreePascal (less so) support windows, linux, mac, android with the same codebase (or calls rather). The Delphi model has really set the standard for a robust desktop framework, since before most people started writing code.
- criddell 3y ago
  > which OS? The one you want to run your software on. > what GUI framework? Assuming you aren't making a game, each OS has a different answer. Making an iPadOS or macOS app? I'd probably go with SwiftUI. Linux? I'm partial to GTK. Windows? Probably WinUI (although I also still like MFC extended with raw Win32 API calls). There are cross platform tools, but none of them are very good. If you want to make something really great, target the most important OS and make the absolute best thing you can with the native features of that OS. Follow the conventions of the platform and you get a lot of stuff (like accessibility features) for little effort. > The web is a single platform I agree. The web as presented by the browser is its own distinct platform. A well written web app will almost always use more battery, memory, CPU, and network bandwidth than a similar well written native app. Sometimes, despite all the problems with web technologies, the web is where something belongs. I'm still a big believer in the personal computer. The web takes power from individuals and is a step back to the days of dumb terminals and centralized computing.

PaulHoule 3y ago

I worked for a startup that built a React + Scala system for building training sets for machine learning models. At the time I was involved this had a strong research component, particularly we frequently had to roll out new tasks, and in fact we were working actively with new customers to adapt to their needs all the time. The build for the system took about 20 minutes, and part of the complexity was that every new task (form where somebody had to make a judgement) had to be built twice since both a front end and back end component had to be built so React was part of the problem and not part of the solution. Even in a production environment this split would have been a problem because a busy system with many users might still need a new task added from time to time (think AMZN's MTurk) and forcing people to reload the front end to work on a new task defies the whole reason for using React. It all was a formula for getting a 20 person team to be spinning its wheels, struggling to meet customer requirements and keeping our recruiters busy replacing developers that were getting burnt out. I've built several generations of my own train-and-filter system since then and the latest one is HTMX powered. Each task is written once on the back end. My "build" process is click the green button on the IDE and the server boots in a second or two. I can add a new task and be collecting data in 5-10 minutes in some cases, contrasted to the "several people struggling for 5 days" that was common with the old system. There certainly are UIs that would be hard to implement with HTMX, but for me HTMX makes it possible to replace the buttons a user can choose from when they click a button (implement decision trees), make a button get "clicked" when a user presses a keyboard button and many other UI refinements. I can take advantage of all the widgets available in HTML 5 and also add data visualizations based on d3.js. As for speed, I'd say contemporary web frameworks are very much "blub" http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html On my tablet via tailscale with my server on the wrong end of an ADSL connection I just made a judgement and timed the page reload in less than a second with my stopwatch. On the LAN the responsiveness is basically immediate, like using a desktop application (if the desktop application wasn't always going out to lunch and showing a spinner all the time.)

fogzen 3y ago

Server-side apps cannot provide optimistic UI. No matter how you feel about it, they are limited in this capability compared to client-side apps. The user doesn’t care about the technology. For example, imagine a todo app that shows a new todo immediately. Or form validations that happen as soon as data is entered. That’s a superior experience to waiting on the server to continue interaction. Whether that’s harder to engineer is irrelevant to the user. We should be striving for the best possible user experience, not what we as engineers personally find easy or comfortable. HTMX is cool. HTMX may fit your needs. But it’s not enough for providing the best possible user experience.

adamckay 3y ago
You don't have to be restricted to just using htmx, you can use it with client side Javascript to give you that interactivity you need in the places you need it. Indeed, the creator of htmx has created another library called hyperscript which he's described as a companion to htmx. https://hyperscript.org/ https://hyperscript.org/
- sublinear 3y ago
  Awful. The last thing we need is another layer further away from plain javascript cluttering up web pages.

steve76 3y ago

[dead]

tudorw 3y ago

Xanadu.

yellowapple 3y ago

Using an HTTP header to decide between "just return a snippet for this specific list element" v. "return the whole page with the updated content for this list element" is an interesting choice that I hadn't really considered before; normally I would've opted for two entirely separate routes (one for the full page, one for the specific hypermedia snippet), which HTMX also seems to support. I guess it ain't fundamentally different from using e.g. Accept-* headers for content negotiation.

quii 3y ago
I think both are valid, as i mentioned in the article, for this particular case, the psuedo content-negotiation felt right

rglover 3y ago

Or: just use plain HTML [1] and keep separation of concerns intact. In a quote: > "So much complexity in software comes from trying to make one thing do two things." - Ryan Singer (Basecamp/37Signals) [1] https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick

kokizzu5 3y ago

meh, Svelte is the future, just plain Svelte, not SvelteKit

auct 3y ago

I tried htmx, but syntax is horrible, so 3 years ago I've created uajax universal Ajax forms and js-ajax-button. Add class to any form and it is ajaxed. I even released it on github The js-ajax-button has similar approach. Add class to button that have data-url and it will make request to it. This is small func I use, but with uajax is so powerful, I don't need react or htmx. But it is hard to sell something that eliminates using javascript.

iamgopal 3y ago

Basecamp ( or Hey or guys behind ror ) , the original SAAS guys really do understand software development from practical point of view, they did something similar with rails as well as native clients, now a days they are trying people to move away from cloud. Bare metal is the future.

thomasreggi 3y ago

I agree with this article, however I think that HTMX needs a strong server framework to support HTMX. I've thought about this alot and a couple months back created this deno / typescript framework https://github.com/reggi/htmx-components https://github.com/reggi/htmx-components, would love for people to take a look at it and provide guidance and direction for a releasable version.

triyambakam 3y ago
That's really nice!

munbun 3y ago

The HATEOAS approach is viable for some applications but I wouldn't necessarily call it the future. Using custom html attributes as the base for complex client-side interactions is arguably a step backwards when considering the story around maintenance. Right now, if you are building a robust component library - it's much easier to maintain using a template language with strong Typescript / IDE support, like JSX or similar.

can16358p 3y ago

I think "the future" definitely isn't some non-standard custom attributes.

robertoandred 3y ago

This really comes down to backend devs thinking frontend must be simple, and when they realize it's not they blame the tools. So they come up with new tools and pretend they're better because they cater to backend devs and not those silly frontenders who just don't know anything.

quest88 3y ago

This is a weak argument. The article is demoing a TODO app talking to localhost. Almost any library, framework, or language is the future if this is how we're judging the future. > Working with HTMX has allowed me to leverage things I learned 15-20 years ago that still work, like my website. Yes, a website is different than a webapp and has different requirements.

BeefySwain 3y ago
> Yes, a website is different than a webapp and has different requirements. The piece missing here is that most people do not stop to think which they are building before they reach for a JS heavy SPA framework and start spinning up microservices in whatever AWS calls their Kube implimentation.

anyonecancode 3y ago

The tricky part of an SPA is that as a developer, you're taking on a lot of the burden of managing location state that in an MPA is handled by the browser. And location state often is a significant component of application state. Certainly it's possible to take on that burden and execute it well, but I think a lot of teams and businesses don't fully account for the fact that they are doing so and properly deciding if that extra burden is really necessary. The baseline for nailing performance and correctness is higher with an SPA.

divan 3y ago

Why people concentrating on creating more hacks on top of fundamentally ill-suited stack for app development, rather then rethink the whole stack from the first principles? Luckily, after 3 decades, there is some sobering realization that typesetting engine is not a good foundation for modern apps. https://news.ycombinator.com/item?id=34612696 https://news.ycombinator.com/item?id=34612696 Web development without HTML/CSS/JS is the future.

mal-2 3y ago

I like some concepts from HTMX but I don't understand how it tracks the relationship between these addresses and the identifiers in the markup. It seems to be just that the identifier strings match - the markup identifies the targets/swaps and it just refers to itself. When I compare this to Phoenix LiveView I much prefer LiveView, because it both provides the markup templating engine and tracks the meaning of the relationship, with server-side tokens and methods.

qgin 3y ago

As long as native apps live alongside web, then the architecture of web is going to trend towards that of native apps, managing display state on the client while managing business state on server.

BeefySwain 3y ago

I recently put together https://github.com/PyHAT-stack/awesome-python-htmx https://github.com/PyHAT-stack/awesome-python-htmx at PyCon. If anyone is looking to discuss making Hypermedia Driven Applications with HTMX in Python, head over to the discussions there!

nologic01 3y ago
Good initiative. HTMX + python hits a sweet spot for various interesting things.

hu3 3y ago

meta: I love when htmx is highlighted in HN because the discussions branch into alternatives and different ways of doing web dev. It's very enriching to think outside the box!

mikeg8 3y ago
Agree. I always find some interesting and new FE approaches/methodologies in these random HTMX threads and it’s awesome.

tacone 3y ago

I used to have my hand-written mini version of htmlx ten years ago. It took a few jquery lines of code to have small parts of the UX to update without refresh. I don't see the point by the way, I think htmlx is here to stay and a good choice for many, but it's clearly not a silver bullet. You make decently fast UIs, not blazing fasts, there are no (proper) offline first apps with htmlx, caching is likely more difficult or impossible sometimes and the load for your server is inevitably greater (of course it could be more than acceptable in some cases, so why not?), that also means more bandwidth for your cloud provider as opposed for you cdn. You will still have to write javascript sooner or later. It depends on what you're doing. Nothing is aprioristic ly "the future", the future is "the future", and it has yet to come.

pwpw 3y ago

What is the simplest way to host a website closer to barebones HTML, CSS, and a bit of JS with reusable components like nav bars? My experiences handling those manually leads to too much overhead as I add more pages. SvelteKit makes things fairly easy to organize, but I dislike how the user isn’t served simple HTML, CSS, and JS files. Ideally, I don’t want to use any framework.

optymizer 3y ago
It's called PHP and you can host it anywhere, or if there's nothing dynamic going on, run it on the files on your computer and upload the generated HTML/CSS/JS files to an S3 bucket. src/index.php --------- <!DOCTYPE html> <html> <head><title>Hey look ma, we're back to PHP</title></head> <body> <? include "navbar.php" ?> <p>Don't forget about PHP - a hypertext preprocessor!</p> <? include footer.php ?> </body> </html> src/navbar.php ---------- <div> <ul> <li>Home</li> <li>About</li> </ul> </div> Makefile to generate a static site: ----------------------------------- dist/index.html: src/index.php dist/about.html: src/about.php dist/%.html: src/%.php @mkdir -p ${dir $@} php $< > $@
pier25 3y ago
Astro

pkelly 3y ago

Thank you for writing this article! I've had similar thoughts for the past 5 years or so. A lot of the comments here seem to have the approach that there is a single best stack for building web applications. I believe this comes from the fact that as web engineers we have to choose which tech to invest our careers in which is inherently risky. Spend a couples years on something that becomes defunct and it feels like a waste. Also, startup recruiters are always looking for the tech experience that matches the choice of their companies. VCs want to strike while the iron is hot. Something that doesn't get talked about enough (which the author does mention near the end of article) is that different web apps have different needs. There is 100% a need for SPAs for certain use cases. Messaging, video players, etc. But there are many cases where it is overkill, like the many many CRUD resource apps I've built over the years. Say you have a couple hundred users that need to manage the state of a dozen interconnected resources. The benefits of an MPA are great here. Routing is free, no duplication of FE / BE code. Small teams of devs can ship code and fix bugs very fast which keeps the user feedback loop tight.

quii 3y ago
Thanks for taking the time to read the article :) A lot of the comments here seem to implying that I claim "htmx is the one hammer to solve all website needs", even when I explicitly say SPAs have their place in the article. A hypermedia approach is the nice happy medium between a very static website and an SPA, not sure why so many people are close-minded about this possibility.

branko_d 3y ago

I’m afraid htmlx might be repeating the same mistake that CORBA and DCOM made decades ago: pretending that latency doesn’t matter. Yes you could make a CORBA or DCOM object almost indistinguishable from a local object, except for the latency when it was actually remote. And since it looked like a normal object it encountered “chatty” interface which exacerbated the latency cost. Htmlx seems pretty chatty to me, which I’m sure works OK over the LAN, but what about the “real” internet?

w10-1 3y ago

What's the business case, for them or for developers? Ideas aside, the web app future belongs to those with the resources to sustain a response, or those who can restore the ability to capture/monetize developers and users in a closed system. The scope of web apps is broad enough that many technologies arguably have their place. The open javascript ecosystem reduced the cost of creating candidates, but has no real mechanism to declare winners for the purpose of consolidating users, i.e., access to resources. Careers and companies are built on navigating this complexity, but no one really has the incentive to reduce it unless they can capture that value. I really appreciate Cloudflare because they are open about both their technology and their business model. They thus offer a reasonable guarantee that they can sustain their service and their technology, without basing that guarantee on the fact that they are a biggie like AWS, Microsoft, or Google (i.e., eating their own dog food, so we can join them at the trough). The biggest cost in IT is not development or operating fees but reliance and opportunity.

hamilyon2 3y ago

I am not going to be serious here, because, honestly, this is kind of ridiculous. Two years ago I distinctly remember server side rendering piped thru websocket was future. I also like how demo is visibly ugly, jQuery-style ugly. It's nostalgic in a way. And I swear to gods this approach will break back button. And resending form after network error. And expired cookie will of course result in your input being lost.

Animats 3y ago

It's sort of like client side PHP. Is that a good thing or a bad thing?

bottlepalm 3y ago

I tried HTMX. The static typing just isn't there between the components you send down and the rest of the page. This makes maintenance of a large HTMX app pretty costly. For simple stuff, it's probably fine, but large complicated web apps, I'm not seeing it. Mixing HTML fragments from the server into the client is pretty messy. Keeping all the rendering in one place à la React seems much simpler to maintain. With Next for example you can pre-render on the server, and re-render on the client - the same code is doing the rendering in both places so a bit more easier to understand.

deleted 3y ago

[deleted]

CodeCompost 3y ago

I'm beginning to realise that AI assistance is now resulting in long and verbose articles like this one. The bullet points are especially off-putting.

rmorey 3y ago
then the problem begets its own solution - just use an assistant to summarize for you! \s (i don't actually think this article is largely AI-generated)

hankchinaski 3y ago

everytime i see a custom new DSL i just bin the thing altogether, I dont want to learn a new DSL that will disappear in a year, it will be impossible to find documentation and community support for. just a big no for me. Apart from that seems like a good idea >Here we are getting a bit fancy and only allowing one row at a time to be edited, using hyperscript. https://hyperscript.org https://hyperscript.org

redonkulus 3y ago

We've been using similar architecture at Yahoo for many years now. We tried to go all in on a React framework that worked on the server and client, but the client was extremely slow to bootstrap due to downloading/parsing lots of React components, then React needing to rehydrate all the data and re-render the client. Not to mention rendering an entire React app on the server is a huge bottleneck for performance (can't wait for Server Components / Suspense which are supposed to make this better ... aside: we had to make this architecture ourselves to split up one giant React render tree into multiple separate ones that we can then rehydrate and attach to on the client) We've moved back to an MPA structure with decorated markup to add interactivity like scroll views, fetching data, tabs and other common UX use cases. If you view the source on yahoo.com and look for "wafer," you can see some examples of how this works. It helps to avoid bundle size bloat from having to download and compile tons of JS for functionality to work. For a more complex, data-driven site, I still think the SPA architecture or "islands" approach is ideal instead of MPA. For our largely static site, going full MPA with a simple client-side library based on HTML decorations has worked really well for us.

thomond 3y ago
I had no idea Yahoo
vosper 3y ago
> We've been using similar architecture at Yahoo for many years now. At all of Yahoo? I imagined such a big company would have a variety of front-end frameworks and patterns.
- redonkulus 3y ago
  Nope, not all. Yahoo homepage, News, Entertainment, Weather all use this architecture. Yahoo Mail uses a React/Reduct architecture on the client. Other Yahoo properties with more complex client-side UX requirements are using things like Svelte or React. It's not a one size fits all architecture at Yahoo, we let teams determine the right tools for the job.
pier25 3y ago

jcmontx 3y ago

I am very fond of MPAs. Glad to see them make a comeback. The one single strong point of the front/back split is the famous Strangler Fig Pattern which takes away a lot of stress when making decisions.

mike503 3y ago

Reminds me of Drupal's AHAH implementation.

xutopia 3y ago

Wether it is Htmx or Phoenix/Liveview or Hotwire/Stimulus we're seeing a shift in the industry towards augmented HTML rather than throwing away all RESTFUL routes. REST is elegant and this approach is very powerful as well.

doodlesdev 3y ago

No it's not. Honestly, the fact that this website displays like shit without JavaScript enabled is ironic considering it uses HTMX. Please just use the damn full-stack JS frameworks, they make life simpler, just wait for WebAssembly to allow us to have full-stack Rust/Go/whatever frameworks, and then you can abandon JavaScript, otherwise you get the mess of websites like this one where the developer has not written JavaScript, but the website still needs it for me to be able to read a _damn blog post_. Otherwise, stick with RoR, Django, Laravel, or whatever ticks your fancies, but HTMX just ain't for everyone and everything, it's supposed to be used for hypermedia, not for web apps or anything else, just that: hypermedia. And no, JavaScript libraries aren't all "complicated" and "full of churn", React is. Stop using React, or otherwise accept the nature of its development, and stop complaining. There are hundreds of different JavaScript libraries and yet every single time I see people bashing on full stack JavaScript they just keep repeating "React" like it's the only library in the world and the only way developers have written code for the last decade. Also, tangentially related, can we as an industry stop acting like kids and stop following these "trends"? The author talks about a "SPA-craze" but what I've been seeing more and more now is the contrary movement, however it's based on the same idea of a hype cycle, with developers adopting technology because it's cool or whatever and not really considering what are their actual needs and which tools will provide them with that. Rant over.

lakomen 3y ago
[flagged]
- doodlesdev 3y ago
  I'm sorry for saying something you disagree with. Next time I'll ask for permission to comment my opinion. Really, what's the point of your comment? At least state why you think I have no idea what I'm talking about, the way you wrote it adds literally nothing to the conversation.
  - dang 3y ago
    Please don't respond to a bad comment by breaking the site guidelines yourself. That only makes things worse. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

loxs 3y ago

Am I the only one who actually thinks that a SPA is simpler than server rendered UI? I always go for a SPA when I can sacrifice indexability and never seem to regret it.

diegof79 3y ago

While HTMLX makes some interactions easier for developers without JS experience, the primary issue in web development is that the browser was not designed for apps. It evolved unevenly from a document navigation platform, and many things we do in web development today are hacks due to the lack of a better solution. In my opinion, the future of the web as a platform is about viewing the web browser as an operating system with basic composable primitives. HTMLX adds attributes to HTML using JS, and the argument about "no-JavaScript" is misleading: with HTMLX you can write interactions without JS, but HTMX uses JS. But, as it forces you to use HTML constructs that will work without scripts (such as forms), the page will fall back. It doesn't means that the fallback is usable. The custom HTMLX attributes work because the browser supports extensions of its behavior using JS. If we add those attributes to the standard HTML, the result is more fragmentation and an endless race. The best standard is one that eliminates the need for creating more high-level standards. In my view, a possible evolution of WASM could achieve that goal. It means going in the opposite direction of the article, as clients will do more computing work. In a future like that, you can use HTMLX, SwiftUI, Flutter, or React to develop web apps. The biggest challenge is to balance a powerful OS-like browser like that with attributes like searchability, accessibility, and learnability (the devtools inspect and console is the closest thing to Smalltalk we have today)...even desktop OSs struggle today to provide that.

incrudible 3y ago

I take the opposite side of that bet. Always bet on (more) Javascript. Dealing with HTML sucks, and we want as little of it as possible, otherwise we would not have invented generations of frameworks to make it manageable. The lasting success of React shows that we have converged on how to do that. Moving back to MPAs is always something that bored engineers want to do. Users generally do not care. Moreover, REST APIs - and I mean the simple ones people actually want to use, none of that HATEOAS BS - are ubiquitous for all sorts of interactions between web and nonweb clients. Are you going to ship an MPA as your mobile apps, or are you going to just use REST plus whatever clients make sense? It also makes a lot of sense in terms of organization. Your backend developers probably suck at design, your frontend developers suck at databases.

klabb3 3y ago

> Hugely increased complexity both in terms of architecture and developer experience. You have to spend considerable time learning about frameworks. You have to learn something. You can claim bloat in JS frameworks, but that isn’t solved by simply moving it to the server. Is htmx lean and nice today? Probably! But does it handle the same use cases that the React users have? What happens to it under pressure of feature bloat? Small-core frameworks like Elm who resisted this pressure were abandoned by big shops. You can’t just take something immature (however good) and simply extrapolate a happy future. > Tooling is an ever-shifting landscape in terms of building and packaging code. Yes. JS is not the only language with churn issues and dependency hell. > Managing state on both the client and server Correct me if I’m wrong, but state can change for something outside of a htmx request, meaning you can end up with stale state in element Y in the client after refreshing element X. The difference is that your local cache is in the DOM tree instead of a JS object. > By their nature, a fat client requires the client to execute a lot of JavaScript. If you have modern hardware, this is fine, but these applications will be unusable & slow for those on older hardware or in locations with slow and unreliable internet connections. On unreliable connections you want as thick of a client as possible. If you have server-in-the-loop for UI updates, you quite obviously have latency/retry issues. It’s much preferable to show stale state immediately and update in the background. > It is very easy to make an SPA incorrectly, where you need to use the right approach with hooks to avoid ending up with abysmal client-side performance. Bloat comes from reckless software development practices, and are possible in any technology. Angular and React have a shitton of features and ecosystem around it, whereas say Svelte is more lean. Enterprisey shops tend to prioritize features and not give a flying fuck about performance. This is a business choice, not a statement about technology. > Some SPA implementations of SPA throw away progressive enhancement (a notable and noble exception is Remix). Therefore, you must have JavaScript turned on for most SPAs. Finally, we cut to the chase. This is 100% true, and we should be talking about this, because it’s still not settled: do we want web pages or web apps? If both, where is the line? Can you expect something like Slack to work without JavaScript? What about a blog with interactive graphs? Should everything degrade or should some things require JS/WASM? I love that htmx exists. I have absolutely nothing against it. It honors some of the early web philosophy in an elegant and simple manner. It may be a better model for server-centric apps and pages, which don’t need offline or snappy UIs. But it cannot magically solve the inherent complexities of many modern web apps.

teaearlgraycold 3y ago

I'd rather see either: * NextJS provide a holistic solution to backend code. Right now it's missing an ORM that works with serverless postgres. Given their recent additions of serverless postgres to Vercel I expect this will happen in 6-12 months. * RedwoodJS become more mature. The issues with SPAs IMO come from having to cobble together your full stack app, which requires making a ton of hard decisions in predicting the future of each major library you use. And then there's limited coherence between your ORM, API, and client without extra work. A mature, well designed, and financially supported full stack JS solution that truly rivals Rails would be perfect.

chrsjxn 3y ago

I love articles like these, because the narrative of "JS framework peddlers have hoodwinked you!" is fun, in an old-timey snake oil salesman kind of way. But I'll be honest. I'll believe it when I see it. It's not that htmx is bad, but given the complexity of client-side interactions on the modern web, I can't see it ever becoming really popular. Some of the specifics in the comparisons are always weird, too. > Instead of one universal client, scores of developers create bespoke clients, which have to understand the raw data they fetch from web servers and then render controls according to the data. This is about client side apps fetching arbitrary JSON payloads, but your htmx backend needs to do the same work, right? You have to work with the raw data you get from your DB (or another service) and then render based on that data. You're still coupled to the data, and your htmx endpoint is just as "bespoke" as the client code which uses it. It's not wrong to prefer that work be done on the server instead of the client, or vice versa, but we're really just shuffling complexity around.

fogzen 3y ago
You touch on something that bugs me about these discussions: Lack of proof. Show me the web app with killer UX developed with htmx. Show me the product of the tools and processes being advocated.
- renerick 3y ago
  I'm not a developer of either of these, but here are two examples: - https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ by https://github.com/David-Guillot https://github.com/David-Guillot - a SaaS product migrated to htmx from React. - https://zorro.management/ https://zorro.management/ by https://twitter.com/Telroshan https://twitter.com/Telroshan - a kanban project management tool. This one is particularly interesting IMO, it implements quite advanced UI with htmx and some custom JS.
  - fogzen 3y ago
    Thanks! I feel like these discussions would be so much more fruitful if they were centered around dissecting real products.

wibblewobble124 3y ago

we’re using htmx at work, migrating away from react. the technique we’re using is just rendering the whole page, e.g. we have a page where one side of the screen is a big form and the other side is a view on the same data but with a different UI, updating one updates the other. we’re using the morphdom swapping mode so only the things that changed are updated in-place. as a colleague commented after implementing this page, it was pretty much like react as far as “pure function of state.” our policy is that for widgets that are like browser components e.g. search as you type with keyboard shortcuts, we just use the off the shelf react component for that purpose and use it from htmx like it’a browser input element. for all other business logic (almost all of which has no low latency requirements and almost always involves a server requets), we use htmx in our server side language of choice. our designer who knows a bit of react is not happy, but the 12 engineers on our team who are experts in $backend_lang and who are tired of debugging react race conditions, cache errors, TypeScript front end exceptions, js library churn, serialisation bugs, etc. are very happy indeed. it doesn’t fit every app, but it fits our app like a glove and many others that I’ve considered writing that I didn’t feel like bothering to do so before discovering htmx.

robertoandred 3y ago
Sounds like your backend devs are just bad at frontend.
- ihateolives 3y ago
  And? Your average React dev is bad at proper backend too.
  - robertoandred 3y ago
    So then doesn't it make sense that frontend devs focus on frontend and backend devs focus on backend?
    - CRConrad 3y ago
      It makes sense that application developers focus on getting an application to work. In the case of these newfangled “Web applications”, that would be focussing on getting HTML to render in the user's browser. That focus doesn't have to have anything to do with an arbitrary split into “frontend and backend”.

klysm 3y ago

I'll stick to making SPAs for the apps I work on. This is just the pendulum of tradeoffs swinging back till people experience the pains of MPAs again

denton-scratch 3y ago

How's it not a SPA, if you're updating the DOM in JS without a full page reload? Sorry, I read a load of stuff about React, before I came to any explanation of HTMX. Turns out, it's loading fragments of HTML into the DOM (without reload), instead of loading fragments of JSON, converting them to HTML fragments client-side, and injecting the resulting HTML into the DOM (without reload). So I stopped reading there; perhaps the author explained why HTMX solves this at the end (consistent with the general upside-down-ness), but the "is the future" title was also offputting, so excuse me if I should have read the whole article before commenting. I never bought into the SPA thing. SPAs destroy the relationship between URLs and the World Wide Web.

robertoandred 3y ago
SPAs work with complex, relevant, and unique URLs perfectly fine.

aigoochamna 3y ago

I somewhat get where htmx is coming from. It's not bad per-say.. I actually like the general idea behind it (it's sorta like Turbolinks, but a bit more optimal using fragments instead of the entire page, though Turbolinks requires zero additional work on the markup side and works with JavaScript disabled out of the box). With that being said, I imagine it would become unmaintainable very quickly. The problems htmx is solving are better solved with other solutions in my opinion, but I do think there's something that can be learned or leveraged with the way htmx goes about the solution.

CRConrad 3y ago
> It's not bad per-say.. Per se. It's Latin for “in itself”; has nothing to do with saying anything. Think about it: What would “per-say” even mean?
werdnapk 3y ago
Turbo (the updated Turbolinks) uses fragments quite heavily... Turbo calls them frames. Turbolinks was more of a full page only approach though.

deleted 3y ago

[deleted]

tkiolp4 3y ago

Frontend developers don’t want to write HTML nor augmented HTML. They want to write code, and these days that means JS. Frontend developers want to make good money (like those backend developers or even infrastructure developers who are working with data, servers, and cool programming languages), hence they need to work with complex libraries/frameworks (if you just write HTM?, you don’t get to earn much money because anyone can write HTM?). Hell, the term “frontend developer” exists only because they are writing JS! Tell them it’s better to write HTM?, and you are removing the “developer” from their titles! Same reason why backend developers use K8s. There’s little money on wiring together bash scripts. Now, if you’re working on your side project alone, then sure HTMX is nice.

robertoandred 3y ago
Incorrect. You can't create a website without HTML. The term "frontend developer" exists because frontend is a complex mix of HTML, CSS, JS, browser functionality, screen sizes, accessibility requirements, privacy requirements, server interactions. Backend devs just lampoon it because they assume it must be simple.

kubota 3y ago

I don't know. The tabs example on the htmx page is perceptibly slow to me. Making a rest call every time I switch a tab, each time sending 90% of the same html skeleton data over the wire feels like a sin to me. Returning html from my api also feels like a sin.

CRConrad 3y ago
> Returning html from my api also feels like a sin. Sorry, but that's just... Silly. HTML is what the Web is all about.
- kubota 3y ago
  Most of my apis are consumed my multiple clients, many without user interfaces (other backend systems), some with mobile user interfaces, some with web interfaces. I should make my backend clients parse HTML? Or my mobile clients parse HTML? I don't see any benefit to coupling data to a visual markup language, unless you are only serving web ui clients, and have no plans for that to ever change. Or I should stand up additional services (and pay for their operation and maintenance) just to server side render my data wrapped in html? That seems sillier to me, but to each their own.

jmull 3y ago

> HTMX is the Future I'm not seeing it. SPAs can be overly complex and have other issues, but I'm not seeing HTMX as a particular improvement. Also, a bunch of this article doesn't make sense to me. E.g, one of the listed costs of SPAs is managing state on the client and server... but (1) you don't have to -- isn't it rather common to keep your app server stateless? -- and (2) HTMX certainly allows for client-side and server-side state, so I'm not sure how it's improving things. That is, if you want to carefully manage app state, you're going to need a mechanism to do that, and HTMX isn't going to help you. It also doesn't somehow prevent a rats nest of tooling or dependencies. It isn't an application framework, so this all depends on how to solve that. SPA's also aren't inherently "very easy to make [...] incorrectly". Also, the suggested HTMX approach to no browser-side javascript is very crappy. Your app would have to be very specifically designed to not be utterly horrible w/o JS with such an approach and instead be just pretty horrible. There are just so much more straightforward ways to make apps that work well without JS. Also, this isn't exactly a mainstream requirement in my experience. I could go on and on. "caching" - htmx doesn't address the hard part caching. "seo-friendliness" - Like all the benefits here attributed to htmx, htmx doesn't particularly help with this and there are many other available way to achieve it. IDK. These kinds of over-promising hyped up articles give me the feeling the thing being hyped up probably doesn't have a lot of real merit to be explored or else they'd talk about that instead. It also feels dishonest to me, or at least incompetent, so make all of these claims and assertions that aren't really true or aren't really especially a benefit of htmx vs many numerous other options.

CRConrad 3y ago
> SPA's also aren't inherently "very easy to make [...] incorrectly". Judging from the ones one encounters in the wild, yes they are.

unixhero 3y ago

As long as I don't have to learn it.

michaelchisari 3y ago

Everybody's arguing about whether Htmx can do this or that, or how it handles complex use case x, but Htmx can do 90% of what people need in an extremely simple and straight-forward way. That means it (or at least its approach) won't disappear. A highly complex stock-trading application should absolutely not be using Htmx. But a configuration page? A blog? Any basic app that doesn't require real-time updates? Htmx makes much more sense for those than React. And those simple needs are a much bigger part of the internet than the Hacker News crowd realizes or wants to admit. If I could make one argument against SPA's it's not that they don't have their use, they obviously do, it's that we're using them for too much and too often. At some point we decided everything had to be an SPA and it was only a matter of time before people sobered up and realized things went too far.

silver-arrow 3y ago
Exactly! Well said
ktosobcy 3y ago
This! It's like with static websites - we went from static to blogs rendered in php and then back to jekyll...

jdthedisciple 3y ago

This puts all the computational load on the server. Imagine 10s of thousands of clients requesting millions of HTML fragments be put together by a single server maintaining all the states while all the powerful high end computing power at the end user's fingertips goes completely to waste. Not convinced.

IshKebab 3y ago
Most users these days are probably using phones, not high end computers.
- dhosek 3y ago
  Most phones have an awful lot od computational power.
- jdthedisciple 3y ago
  Most phones have more computing power than all of NASA did in the 80s. I was specifically thinking of modern smartphones in fact, which are pretty damn fast at executing a little bit of JS. (Though I agree that some of the bloated bundles resulting from modern frameworks or their poor usage definitely go to far)
- rwalle 3y ago
  The processor on my phone is better than the one on a 2015 Macbook Pro 13" (i5)
  - IshKebab 3y ago
    The processor on an average phone does not.
mixmastamyk 3y ago
This avoids unnecessary computation at the client, it does not substantially add to the burden of the server. Which would need to be reconciled regardless of the markup format used over the pipe. Alpine is available for local flair.

nine_k 3y ago

I think it's the wrong article (pun semi-intended), HTMX is a future. React is a future. Svelte is a future. Even Angular is a future. They all have their specific strengths which define where they are more applicable. There's no "the future" in this area, because demands are very different; a heavily interactive SPA like GMail or Jira has requirements unlike an info page that needs a few bits of interactivity, etc.

quickthrower2 3y ago

No. A hodgepodge of everyone's favourite way, is the future. Always has been! That said for my next hobby project I will probably go even simpler than HTMX, and use classic server side rendering. Then add some Vanilla JS where needed. I keep going around in circles, but I have tried NextJS and while pretty cool there are a class of problems you need to deal with that simply don't exist in simpler apps.

xkcd1963 3y ago

"The hypermedia approach of building websites led to the world-wide-web being an incredible success." This is wrong

bfung 3y ago

The article reminds me of the early 2000s when we were all rolling our own XMLHttpRequest and replacing dom elements with html rendered from a java servlet. The more realistic and practical read is https://htmx.org/essays/when-to-use-hypermedia/#hypermedia-not-a-good-fit-if https://htmx.org/essays/when-to-use-hypermedia/#hypermedia-n...

janosd 3y ago

I can still remember the horrors of page state. The server would keep track of what the client has and only send HTML fragments to the client. Early-days ASP, Prado and the likes did this and it was a terrible idea. HTMX sounds very much like that, but the packaging is nicer. Ultimately, the problem is that sometimes you need to update more than just the tiny, well-defined part that is the todo list and several parts of the UI need to change when a request is made. By which I mean this happens all the time. The road to hell is paved with todo list implementations as a proof that a system works and is good. Please show me a moderately complex login system with interlinking interfaces implemented in this.

infamia 3y ago
Unpoly and Hotwire are somewhat similar to HTMX, but they update entire sections of a page (i.e., "page fragments") as you describe. They perform a DOM diff and update everything wrapped inside an HTML tag (e.g., a <div>) with a special attribute. Unpoly does this within the app's normal request/response cycle, while Hotwire uses websockets to stream updates. https://unpoly.com/tutorial https://unpoly.com/tutorial https://hotwired.dev/ https://hotwired.dev/

synergy20 3y ago

htmx is ajax wrapped in html to me. it does not work for resource restricted (i.e. embedded) devices where you just can't do server-side rendering, CSR SPA is the future there as the device side just need return some json data for browser to render.

renerick 3y ago
Htmx actually can be used with these restrictions, there is an extension to do client side rendering from a JSON response [1]. And you can make htmx send JSON requests instead of form data [2]. The idea is easily extendable to any template engine, so you can keep your device response minimal while enjoying the simplicity of htmx. I will admit though, this approach gets funky much faster, than returning HTML fragments, so you probably shouldn't exclusively build your app with this client-side-templates [1]: https://htmx.org/extensions/client-side-templates/ https://htmx.org/extensions/client-side-templates/ [2]: https://htmx.org/extensions/json-enc/ https://htmx.org/extensions/json-enc/

themaximalist 3y ago

I just started using HTMX in new projects and really like it. The LivewView/Hotwire/LiveWire way of building applications make a really great tradeoff—the ease of building websites with the speed and power of webapp UX. I wanted something simple to use with Express and it's been very productive. There's a few things to get used to, but overall like it and plan to keep using it in my projects.

knallfrosch 3y ago

HTMX Solution to keeping client and server in sync: Remove the client. Okay, now you have half the code base, but need a round trip to the server for every interaction. You could also remove the server and let people download your blog, where they can only post locally. No server-side input validation needed!

manx 3y ago
You can implement interactivity which doesn't need data from the server entirely client side. Libraries like https://alpinejs.dev https://alpinejs.dev help here and pair well with htmx.

tabtab 3y ago

I keep saying this and will say it again: what's really needed is a state-ful GUI markup language. HTML+DOM+JS+CSS is the wrong tool for the CRUD/GUI job, and force-fitting it has inflamed the area so bad many don't want to even try to scratch it. Bloated JS frameworks like Angular, React, Vue, and Electron have big learning curves and a jillion gotcha's because they have to reinvent long-known and loved GUI idioms from scratch, but DOM is inherently defective for that need, meant for static documents. There are just too many GUI needs that HTML/DOM lacks or can't do right: https://www.reddit.com/r/CRUDology/comments/10ze9hu/missing_or_defective_gui_idioms_in_htmldom/ https://www.reddit.com/r/CRUDology/comments/10ze9hu/missing_... Let's byte the bullet and create a GUI markup standard. Perhaps base it off Tk or Qt kits to avoid starting from scratch.

CRConrad 3y ago
> Let's byte the bullet and create a GUI markup standard. Heh, fun pun. > Perhaps base it off Tk or Qt kits to avoid starting from scratch. VCL / LCL.

manx 3y ago

It seems that many people are wondering why UI interactions, which don't need new data, should take a network roundtrip. You can avoid those round-trips by using a library like https://alpinejs.dev https://alpinejs.dev . It pairs well with htmx.

st3fan 3y ago

Phoenix Liveview is the future :-)

bioinformatics 3y ago

No, it’s not

elwell 3y ago

I don't like XML syntax.

CRConrad 3y ago
Yeah, frightfully verbose. (I suppose that's why JSON seems so much more popular nowadays; at the very least a large contributing cause.) But WTF does that have to do with anything here, which wasn't about XML at all?
- elwell 3y ago
  HTMX is HTML is XML

shams93 3y ago

What isn't mentioned is how there are intrinsic security issues with server side templating, including htx. Part of the reason react won is it has the best track record for client security with complex client apps when its used and configured and deployed correctly. With server side templating its easy to fall victim to injection attacks.

lvh 3y ago

I don't disagree with the article, but I feel like the author almost landed on an interesting counterpoint. Author points out they didn't do this in ClojureScript, but writing apps in Reagent (the leading ClojureScript React wrapper) has looked almost identical across many years and many versions of React. Many of the state management epochs have also been avoided, because "manage state" is a core idea in Clojure, and so the stuff we had almost a decade ago is still perfectly fine today. So, I posit that the churn, while definitely real, is not actually intrinsic. Right now, at Latacora, we're writing a bunch of Clojure. That includes Clerk notebooks, some of which incorporate React components. That's an advantage I think we shouldn't ignore: not needing to write my own, say, Gantt chart component, is a blessing. So, specifically: not only do I think the churn is incidental to the problem, I don't even believe you need to give up compatibility to get it. Fun fact: despite all of this, a lot of what we're writing is in Clerk, and while that's still fundamentally an SPA-style combination of frontend and backend if you were to look at the implementation, it absolutely _feels_ like an htmx app does, in that it's a visualization of your backend first and foremost (React components notwithstanding).

AtlasBarfed 3y ago

ok look people. I think what is needed is to recognize that the SPA architecture isn't actually just a view processor. IMO it is a very shitty designed: View rendered <--> client process <--> server process So it seems that SPA apps load an absolute mountain of javascript into the view (the tab/page) and then that starts (crudely IMO) running as client-side daemon tracking messy state and interfacing with local storage, with javascript (opinion: yuck) ferreted away in a half dozen divs. IMO, what has been needed since you have local storage and local session state and all that is ... a client daemon that the web page talks to that offers data services, and then that client daemon if it needs server data calls to the internet. That way local state tracking, transformation, and maintenance can be isolated away from the code of the view. Large amounts of javascript (or maybe all with CSS wizardry is dropped). The "client daemon" can be coded in webassembly, so you aren't stuck with javascript (opinion: yuck). You can even have more efficient many views/tabs interfacing with the single client daemon, and the client daemon can track and sync data between different tabs/views/windows. Now, of course that is fucking ripe as hell for abuse, tracking. Not sure how to solve it. But "separation of concerns" in current web frameworks is a pipe dream.

exabrial 3y ago

Schemaless markup has lead us down a path where something is broken nearly all the time. I’d really rather see strongly typed markup that can easily be checked for correctness and who’s behavior is well defined. Something Modular too with profiles and designed for extensibility.

MattyRad 3y ago

> ... requires a full page refresh to use ... isn't good enough for many types of web-app we need to make. > without the annoying full-page load refresh. This fixation on the page refresh needs to stop. Nearly every single website which has purportedly "saved" page refreshes has brutalized every other aspect of the UX. This is a good article, and I agree that Htmx brings sanity back to the frontend, but somewhere along the line frontend folks got it in their head that page refreshes were bad, which is incorrect for essentially all CRUD / REST APIs. Unless you're specifically making a complex application that happens to be served through the web, like Kibana or Metabase, then stop harping on page refreshes. Even this article calls it the annoying refresh. Not the impediment refresh, or the derisive refresh, or the begrieved refresh. Moreover, what exactly is annoying about page refreshes? That there's a brief flash? That it takes ~0.3 seconds to completely resolve? Users don't care about page refreshes, and in fact they are an indication of normalcy. Upending the entire stack and simultaneously breaking expected functionally to prevent them is madness. The killer feature of Htmx is that it doesn't upend the entire stack, and you can optimize page refreshes relatively easily. That's great! But even then I'm still not convinced the tradeoff is worth it.

chenster 3y ago

Please make up our mind. Why can't we just make a decision and stick to it? It's like something comes alone everything 12 month and claims it is 'better'.

tommica 3y ago
Well, there is as many opinions as there is people, so consensus is a bit hard to reach...

tommica 3y ago

Htmx seems really nice,but as far as I can see, it is messy to implement some kind of a state, f.x a button that can only be pressed if the other forms on the page have been saved.

kurtextrem 3y ago

Back in the days, when JSON became popular as response type for rendering in the client, I saw arguments such as "the JSON payload is smaller than sending full HTML, so you pay the download only once instead of N times". Only once, because what has to be done with the JSON has been downloaded in the JS bundle. With full HTML, full HTML comes back in every response. However, I'm not sure if this is actually a problem or rather depends on how much interaction the user does (so where is the "turning point" of the overhead of having all in the bundle vs full HTML responses). What does everyone think?