Htmx Is the Future

It&#x27;s kinda funny to me that many of the &quot;pros&quot; of this approach are the exact reasons so many abandoned MPAs in the first place.<p>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&#x27;s a pretty shitty client experience if you have to do a network request for each and every validation of user input.<p>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.<p>We moved away for MPAs because they were bloated, slow and difficult to work with. SPAs have definitely become what they sought to replace.<p>But that isn&#x27;t because of the technology, it&#x27;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.

I use tech like HTMX because, as a team of one, I have no other choice.<p>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.<p>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.<p>This year, I&#x27;ve looked at Node again now that frameworks like Next offer a middle ground with server-side rendering, but I&#x27;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&#x27;s not me.<p>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&#x27;s tech like HTMX, sprinkled JavaScript, and sometimes lightweight frameworks like Alpine.

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 &amp; it eliminates the two-codebase problem, which puts pressure on teams to adopt js on the backend even if it isn&#x27;t the best server side option)<p>hypermedia isn&#x27;t ideal for everything[1], but it is an interesting &amp; useful technology and libraries like htmx make it much more relevant for modern development<p>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:<p><a href="https:&#x2F;&#x2F;hypermedia.systems" rel="nofollow">https:&#x2F;&#x2F;hypermedia.systems</a><p>[1] - <a href="https:&#x2F;&#x2F;htmx.org&#x2F;essays&#x2F;when-to-use-hypermedia&#x2F;" rel="nofollow">https:&#x2F;&#x2F;htmx.org&#x2F;essays&#x2F;when-to-use-hypermedia&#x2F;</a><p>[2] - <a href="https:&#x2F;&#x2F;hyperview.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;hyperview.org&#x2F;</a>

We&#x27;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&#x2F;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&#x27;t wait for Server Components &#x2F; 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)<p>We&#x27;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 &quot;wafer,&quot; 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.<p>For a more complex, data-driven site, I still think the SPA architecture or &quot;islands&quot; 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.

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

Everybody&#x27;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&#x27;t disappear.<p>A highly complex stock-trading application should absolutely not be using Htmx.<p>But a configuration page? A blog? Any basic app that doesn&#x27;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.<p>If I could make one argument against SPA&#x27;s it&#x27;s not that they don&#x27;t have their use, they obviously do, it&#x27;s that we&#x27;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.

I really want to switch over to htmx, as I&#x27;ve moved away from SPAs frameworks, and I&#x27;ve been much happier. SPAs have so much abstraction, and modern, vanilla JavaScript is pretty decent to work with.<p>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]<p>Alpine.js, a similar project to htmx, claims to have a CSP-compatible version,[2] but it&#x27;s not actually available in any official builds.<p>[0] <a href="https:&#x2F;&#x2F;htmx.org&#x2F;docs&#x2F;#security" rel="nofollow">https:&#x2F;&#x2F;htmx.org&#x2F;docs&#x2F;#security</a><p>[1] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=32158352" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=32158352</a><p>[2] <a href="https:&#x2F;&#x2F;alpinejs.dev&#x2F;advanced&#x2F;csp" rel="nofollow">https:&#x2F;&#x2F;alpinejs.dev&#x2F;advanced&#x2F;csp</a><p>[3] <a href="https:&#x2F;&#x2F;github.com&#x2F;alpinejs&#x2F;alpine&#x2F;issues&#x2F;237">https:&#x2F;&#x2F;github.com&#x2F;alpinejs&#x2F;alpine&#x2F;issues&#x2F;237</a>

People were making this prediction ten years ago. It was wrong then, and it&#x27;s wrong now.<p>This article makes its case about Htmx, but points out that its argument applies equally to Hotwired (formerly Turbolinks). Both Htmx and Hotwired&#x2F;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.<p>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.<p>The biggest problem with Turbolinks&#x2F;Htmx is that there&#x27;s no good story for what happens when one component in a tree needs to update another component in the tree. (Especially if it&#x27;s a &quot;second cousin&quot; component, where your parent component&#x27;s parent component has subcomponents you want to update.)<p>EDIT: I know about multi-swap. <a href="https:&#x2F;&#x2F;htmx.org&#x2F;extensions&#x2F;multi-swap&#x2F;" rel="nofollow">https:&#x2F;&#x2F;htmx.org&#x2F;extensions&#x2F;multi-swap&#x2F;</a> It&#x27;s not good, because the onus is on the developer to compute which components to swap, <i>on the server side,</i> but the state you need is usually on the client. If you need multi-swap, you&#x27;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.<p>Furthermore, in Turbolinks&#x2F;Htmx, it&#x27;s impossible to implement &quot;optimistic UI,&quot; 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&#x27;s unacceptable on mobile web in particular.<p>When predicting the future, I always look to the State of JS survey <a href="https:&#x2F;&#x2F;2022.stateofjs.com&#x2F;en-US&#x2F;libraries&#x2F;front-end-frameworks&#x2F;" rel="nofollow">https:&#x2F;&#x2F;2022.stateofjs.com&#x2F;en-US&#x2F;libraries&#x2F;front-end-framewo...</a> which asks participants which frameworks they&#x27;ve heard of, which ones they want to learn, which ones they&#x27;re using, and, of the framework(s) they&#x27;re using, whether they would use it again. This breaks down into Awareness, Usage, Interest, and Retention.<p>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&#x27;t even hit the charts.<p>The near future is React. The further future might be Svelte or Solid. The future is not Htmx.

1) &quot;Web application development&quot; doesn&#x27;t happen in a vacuum. Often it happens in contexts where the &quot;backend&quot; 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&#x27;s made out to be in this post.<p>2) The missing piece is how you can achieve this &quot;collapsing&quot; 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 &quot;microapplications&quot; that are embedded into their hosting app using iframes?

Personally I believe strongly in thick clients but this is a pretty neat demo anyways.<p>I see a lot of resemblance to <a href="http:&#x2F;&#x2F;catalyst.rocks" rel="nofollow">http:&#x2F;&#x2F;catalyst.rocks</a> with WebComponents that <i>target</i> other components. I think there&#x27;s something unspoken here that&#x27;s really powerful &amp; interesting, which is the declarativization of the UI. We have stuff on the page, but making the actions &amp; 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&#x2F;visible&#x2F;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).

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.<p>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.<p>HTMLX adds attributes to HTML using JS, and the argument about &quot;no-JavaScript&quot; 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&#x27;t means that the fallback is usable.<p>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.

&gt; HTMX allows you to design pages that fetch fragments of HTML from your server to update the user&#x27;s page as needed without the annoying full-page load refresh.<p>I&#x27;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 &quot;replacement target&quot; annotation everywhere, but it was pretty straightforward, and provided shared rendering for the initial page load and these updates.<p>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&#x2F;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?<p>IIRC, one of the big downsides of that &quot;partial&quot; 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.

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&#x27;t care how you do it, I don&#x27;t want to know any of the details. I just want to be able to make things quickly and easily. I don&#x27;t care about programming, I just want to get work done and move on with my life.<p>At this rate, when I&#x27;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&#x27;s absolutely absurd that we spend this much of our lives to do such a dumb thing, and we&#x27;ve been iterating on it for five decades, and it&#x27;s still just popping some text in a screen, but we applaud ourselves that we&#x27;re so advanced now because something you can&#x27;t even see is doing something different in the background.

Thank you for writing this article! I&#x27;ve had similar thoughts for the past 5 years or so.<p>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.<p>Something that doesn&#x27;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&#x27;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 &#x2F; BE code. Small teams of devs can ship code and fix bugs very fast which keeps the user feedback loop tight.

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.

&gt; ... requires a full page refresh to use ... isn&#x27;t good enough for many types of web-app we need to make.<p>&gt; without the annoying full-page load refresh.<p>This fixation on the page refresh needs to stop. Nearly every single website which has purportedly &quot;saved&quot; page refreshes has brutalized every other aspect of the UX.<p>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 &#x2F; REST APIs. Unless you&#x27;re specifically making a complex application that happens to be served through the web, like Kibana or Metabase, then stop harping on page refreshes.<p>Even this article calls it the <i>annoying</i> refresh. Not the <i>impediment</i> refresh, or the <i>derisive</i> refresh, or the <i>begrieved</i> refresh. Moreover, what exactly is annoying about page refreshes? That there&#x27;s a brief flash? That it takes ~0.3 seconds to completely resolve?<p>Users don&#x27;t care about page refreshes, and in fact they are an indication of <i>normalcy</i>. Upending the entire stack and simultaneously breaking expected functionally to prevent them is madness.<p>The killer feature of Htmx is that it <i>doesn&#x27;t</i> upend the entire stack, and you can optimize page refreshes relatively easily. That&#x27;s great! But even then I&#x27;m still not convinced the tradeoff is worth it.

&gt; HTMX is the Future<p>I&#x27;m not seeing it. SPAs can be overly complex and have other issues, but I&#x27;m not seeing HTMX as a particular improvement.<p>Also, a bunch of this article doesn&#x27;t make sense to me.<p>E.g, one of the listed costs of SPAs is managing state on the client and server... but (1) you don&#x27;t have to -- isn&#x27;t it rather common to keep your app server stateless? -- and (2) HTMX certainly allows for client-side and server-side state, so I&#x27;m not sure how it&#x27;s improving things. That is, if you want to carefully manage app state, you&#x27;re going to need a mechanism to do that, and HTMX isn&#x27;t going to help you.<p>It also doesn&#x27;t somehow prevent a rats nest of tooling or dependencies. It isn&#x27;t an application framework, so this all depends on how to solve that.<p>SPA&#x27;s also aren&#x27;t inherently &quot;very easy to make [...] incorrectly&quot;.<p>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&#x2F;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&#x27;t exactly a mainstream requirement in my experience.<p>I could go on and on. &quot;caching&quot; - htmx doesn&#x27;t address the hard part caching. &quot;seo-friendliness&quot; - Like all the benefits here attributed to htmx, htmx doesn&#x27;t particularly help with this and there are many other available way to achieve it.<p>IDK. These kinds of over-promising hyped up articles give me the feeling the thing being hyped up probably doesn&#x27;t have a lot of real merit to be explored or else they&#x27;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&#x27;t really true or aren&#x27;t really especially a benefit of htmx vs many numerous other options.

I like how the cons of SPA are &quot;you have to manage state&quot; and &quot;clients have to execute code&quot;.<p>I mean, aren&#x27;t these baseline &quot;get computers to do stuff&quot; things?

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?

<i>Server-side apps cannot provide optimistic UI.</i> 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.<p>HTMX is cool. HTMX may fit your needs. But it’s not enough for providing the best possible user experience.

I love articles like these, because the narrative of &quot;JS framework peddlers have hoodwinked you!&quot; is fun, in an old-timey snake oil salesman kind of way.<p>But I&#x27;ll be honest. I&#x27;ll believe it when I see it. It&#x27;s not that htmx is bad, but given the complexity of client-side interactions on the modern web, I can&#x27;t see it ever becoming really popular.<p>Some of the specifics in the comparisons are always weird, too.<p>&gt; 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.<p>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.<p>You&#x27;re still coupled to the data, and your htmx endpoint is just as &quot;bespoke&quot; as the client code which uses it. It&#x27;s not wrong to prefer that work be done on the server instead of the client, or vice versa, but we&#x27;re really just shuffling complexity around.

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

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.<p>I&#x27;ve seen this architectures quickly ruined by &#x27;can-do&#x27; people who butcher everything to get a feature done _and_ get a bonus from the management for quick delivery.

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.<p>I don&#x27;t see the point by the way, I think htmlx is here to stay and a good choice for many, but it&#x27;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.<p>It depends on what you&#x27;re doing. Nothing is aprioristic ly &quot;the future&quot;, the future is &quot;the future&quot;, and it has yet to come.

I recently put together <a href="https:&#x2F;&#x2F;github.com&#x2F;PyHAT-stack&#x2F;awesome-python-htmx">https:&#x2F;&#x2F;github.com&#x2F;PyHAT-stack&#x2F;awesome-python-htmx</a> at PyCon.<p>If anyone is looking to discuss making Hypermedia Driven Applications with HTMX in Python, head over to the discussions there!

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 <a href="https:&#x2F;&#x2F;grugbrain.dev" rel="nofollow">https:&#x2F;&#x2F;grugbrain.dev</a> and it all clicked! htmx is crystal that trap internet complexity demon!

Wether it is Htmx or Phoenix&#x2F;Liveview or Hotwire&#x2F;Stimulus we&#x27;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.

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

I don&#x27;t disagree with the article, but I feel like the author almost landed on an interesting counterpoint. Author points out they didn&#x27;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 &quot;manage state&quot; is a core idea in Clojure, and so the stuff we had almost a decade ago is still perfectly fine today.<p>So, I posit that the churn, while definitely real, is not actually intrinsic.<p>Right now, at Latacora, we&#x27;re writing a bunch of Clojure. That includes Clerk notebooks, some of which incorporate React components. That&#x27;s an advantage I think we shouldn&#x27;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&#x27;t even believe you need to give up compatibility to get it.<p>Fun fact: despite all of this, a lot of what we&#x27;re writing is in Clerk, and while that&#x27;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&#x27;s a visualization of your backend first and foremost (React components notwithstanding).

This puts all the computational load on the server.<p>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&#x27;s fingertips goes completely to waste.<p>Not convinced.

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

I like htmx but have decided to use unpoly, for my current project, which is similar.<p>The concept is great but why has it taken so long?<p><a href="https:&#x2F;&#x2F;unpoly.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;unpoly.com&#x2F;</a>

HTMX brings new life to tech like django which can catapult MVPs into production asap.<p>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.

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.<p>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?<p>It also makes a lot of sense in terms of organization. Your backend developers probably suck at design, your frontend developers suck at databases.

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.

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

Back in the days, when JSON became popular as response type for rendering in the client, I saw arguments such as &quot;the JSON payload is smaller than sending full HTML, so you pay the download only once instead of N times&quot;. 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.<p>However, I&#x27;m not sure if this is actually a problem or rather depends on how much interaction the user does (so where is the &quot;turning point&quot; of the overhead of having all in the bundle vs full HTML responses). What does everyone think?

I somewhat get where htmx is coming from. It&#x27;s not bad per-say.. I actually like the general idea behind it (it&#x27;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).<p>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&#x27;s something that can be learned or leveraged with the way htmx goes about the solution.

The tricky part of an SPA is that as a developer, you&#x27;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.<p>Certainly it&#x27;s possible to take on that burden and execute it well, but I think a lot of teams and businesses don&#x27;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.

Using an HTTP header to decide between &quot;just return a snippet for this specific list element&quot; v. &quot;return the whole page with the updated content for this list element&quot; is an interesting choice that I hadn&#x27;t really considered before; normally I would&#x27;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&#x27;t fundamentally different from using e.g. Accept-* headers for content negotiation.

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

ok look people.<p>I think what is needed is to recognize that the SPA architecture isn&#x27;t actually just a view processor. IMO it is a very shitty designed:<p>View rendered &lt;--&gt; client process &lt;--&gt; server process<p>So it seems that SPA apps load an absolute mountain of javascript into the view (the tab&#x2F;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.<p>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.<p>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 &quot;client daemon&quot; can be coded in webassembly, so you aren&#x27;t stuck with javascript (opinion: yuck).<p>You can even have more efficient many views&#x2F;tabs interfacing with the single client daemon, and the client daemon can track and sync data between different tabs&#x2F;views&#x2F;windows.<p>Now, of course that is fucking ripe as hell for abuse, tracking. Not sure how to solve it.<p>But &quot;separation of concerns&quot; in current web frameworks is a pipe dream.

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?<p>Luckily, after 3 decades, there is some sobering realization that typesetting engine is not a good foundation for modern apps. <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=34612696" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=34612696</a><p>Web development without HTML&#x2F;CSS&#x2F;JS is the future.

I like some concepts from HTMX but I don&#x27;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&#x2F;swaps and it just refers to itself.<p>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.

I think it&#x27;s the wrong article (pun semi-intended), HTMX is <i>a</i> future. React is <i>a</i> future. Svelte is <i>a</i> future. Even Angular is <i>a</i> future. They all have their specific strengths which define where they are more applicable.<p>There&#x27;s no &quot;<i>the</i> future&quot; 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.

I’m afraid htmlx might be repeating the same mistake that CORBA and DCOM made decades ago: pretending that latency doesn’t matter.<p>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.<p>Htmlx seems pretty chatty to me, which I’m sure works OK over the LAN, but what about the “real” internet?

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

I tried htmx, but syntax is horrible, so 3 years ago I&#x27;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<p>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&#x27;t need react or htmx.<p>But it is hard to sell something that eliminates using javascript.

Lol, we&#x27;re still having the SPA discussion 7 years later in the year of our lord 2023?<p>Talk about the positives of YOUR approach, don&#x27;t tear down a different approach that half the industry is using. You&#x27;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.

What&#x27;s the business case, for them or for developers?<p>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&#x2F;monetize developers and users in a closed system.<p>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.<p>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.<p>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).<p>The biggest cost in IT is not development or operating fees but reliance and opportunity.

I&#x27;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.<p>Relevant code:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;ldyeax&#x2F;jimm.horse&#x2F;blob&#x2F;master&#x2F;j&#x2F;j.php">https:&#x2F;&#x2F;github.com&#x2F;ldyeax&#x2F;jimm.horse&#x2F;blob&#x2F;master&#x2F;j&#x2F;j.php</a><p><a href="https:&#x2F;&#x2F;github.com&#x2F;ldyeax&#x2F;jimm.horse&#x2F;blob&#x2F;master&#x2F;j&#x2F;component&#x2F;header.js#L68">https:&#x2F;&#x2F;github.com&#x2F;ldyeax&#x2F;jimm.horse&#x2F;blob&#x2F;master&#x2F;j&#x2F;component...</a><p>The JS would be a bit more elegant if script tags didn&#x27;t need special handling to execute on insertion.<p>The experience is very seamless this way - I&#x27;m very pleased with it. It&#x27;s live at <a href="https:&#x2F;&#x2F;jimm.horse" rel="nofollow">https:&#x2F;&#x2F;jimm.horse</a> - the dynamic behavior can be found clicking on the cooking icon or N64 logo.<p>On reading the article, I&#x27;ll definitely make use of this if it becomes well-supported. It does exactly what I wanted here.

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

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.<p>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&#x27;s MTurk) and forcing people to reload the front end to work on a new task defies the whole reason for using React.<p>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.<p>I&#x27;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 &quot;build&quot; 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 &quot;several people struggling for 5 days&quot; 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 &quot;clicked&quot; when a user presses a keyboard button and many other UI refinements.<p>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&#x27;d say contemporary web frameworks are very much &quot;blub&quot;<p><a href="http:&#x2F;&#x2F;www.paulgraham.com&#x2F;avg.html" rel="nofollow">http:&#x2F;&#x2F;www.paulgraham.com&#x2F;avg.html</a><p>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 <i>less than a second</i> with my stopwatch. On the LAN the responsiveness is basically immediate, like using a desktop application (if the desktop application wasn&#x27;t always going out to lunch and showing a spinner all the time.)

Thanks for the reminder, I&#x27;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.<p>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 &quot;As an AI language model, I am not able to write full applications with code&quot;.<p>I replied &quot;do the same thing in bash&quot; (which I knew would be different in significant ways, but just to check) and it provided the code.<p>I wonder, is this a function of recency of htmx or something else? Do other htmx developers encounter this? I imagine it&#x27;s at least a little bit of a pain for these boilerplate cases, if it&#x27;s consistent vs. access to the same GPT tooling for other languages.

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&#x2F;frameworks (if you just write HTM?, you don’t get to earn much money because anyone can write HTM?).<p>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!<p>Same reason why backend developers use K8s. There’s little money on wiring together bash scripts.<p>Now, if you’re working on your side project alone, then sure HTMX is nice.

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.

How&#x27;s it not a SPA, if you&#x27;re updating the DOM in JS without a full page reload?<p>Sorry, I read a load of stuff about React, before I came to any explanation of HTMX. Turns out, it&#x27;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).<p>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 &quot;is the future&quot; title was also offputting, so excuse me if I should have read the whole article before commenting.<p>I never bought into the SPA thing. SPAs destroy the relationship between URLs and the World Wide Web.

I don&#x27;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.

&quot;You can use whatever programming language you like to deliver HTML, just like we used to.&quot;<p>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&#x27;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&#x27;t have taken much to relegate JavaScript to non-use. Today we just get around it by compiling to WASM.

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&#x27;t know exactly what that step needs to be, because I don&#x27;t know what a fully &quot;htmx-ed&quot; web would look like. It is promising, but that promise must be made more concrete.<p>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&#x27;t know we had :-). I mean the last decade has been pretty boring in terms of opening new dimensions.<p>Just my two cents.

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&#x2F;complexity ratio, less gnashing of teeth.

I tried HTMX. The static typing just isn&#x27;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&#x27;s probably fine, but large complicated web apps, I&#x27;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.

&gt; 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.<p>Is this really the future?

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

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)<p>This approach has been implemented in most popular programming languages used for backend development: <a href="https:&#x2F;&#x2F;github.com&#x2F;liveviews&#x2F;liveviews">https:&#x2F;&#x2F;github.com&#x2F;liveviews&#x2F;liveviews</a>

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.

I&#x27;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

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

I&#x27;m sorry, but these arguments are so tired.<p>&gt; SPAs have allowed engineers to create some great web applications, but they come with a cost:<p>&gt; Hugely increased complexity both in terms of architecture and developer experience. You have to spend considerable time learning about frameworks.<p>Yes, better quality software usually packages a bit more complexity.<p>SPAs are popular, just like native apps, because people don&#x27;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?<p>&gt; Tooling is an ever-shifting landscape in terms of building and packaging code.<p>I&#x27;ve used these 4 libraries to build apps since 2015:<p>* React * MobX * D3 * Webpack<p>The only one I have had pain with is react-router-dom, which has had 2 or 3 &quot;fuck our last approach&quot; refactors in this time. And I added TypeScript in 2018.<p>PEBCAK<p>&gt; Managing state on both the client and server<p>It&#x27;s a lie that a thin client isn&#x27;t managing state; it&#x27;s just doing a static, dumb job of it.<p>Imagine some cool feature like... collaborative editing.<p>How would you pull that off in HTMX?<p>&gt; 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:<p>Yes, React is famously not a batteries-included library, while Angular is. But, as addressed, you need about 3 other libraries.<p>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?<p>Anyways, I&#x27;ve said enough. I should&#x27;ve just said what I really think: someone who can&#x27;t even get their nested HTML lists to actually indent the nesting shouldn&#x27;t give advice on building UIs.

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.<p>The more realistic and practical read is <a href="https:&#x2F;&#x2F;htmx.org&#x2F;essays&#x2F;when-to-use-hypermedia&#x2F;#hypermedia-not-a-good-fit-if" rel="nofollow">https:&#x2F;&#x2F;htmx.org&#x2F;essays&#x2F;when-to-use-hypermedia&#x2F;#hypermedia-n...</a>

No. A hodgepodge of everyone&#x27;s favourite way, is the future. Always has been!<p>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.<p>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&#x27;t exist in simpler apps.

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.

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&#x27;re judging the future.<p>&gt; Working with HTMX has allowed me to leverage things I learned 15-20 years ago that still work, like my website.<p>Yes, a website is different than a webapp and has different requirements.

It seems that many people are wondering why UI interactions, which don&#x27;t need new data, should take a network roundtrip. You can avoid those round-trips by using a library like <a href="https:&#x2F;&#x2F;alpinejs.dev" rel="nofollow">https:&#x2F;&#x2F;alpinejs.dev</a> . It pairs well with htmx.

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

Yeah HTMX is nice; I&#x27;m still learning about it. I&#x27;m building a django app for <a href="https:&#x2F;&#x2F;host.upcyclebikes.co&#x2F;listings&#x2F;allll" rel="nofollow">https:&#x2F;&#x2F;host.upcyclebikes.co&#x2F;listings&#x2F;allll</a> and i&#x27;m slowly introducing htmx into it.

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

Schemaless markup has lead us down a path where something is broken nearly all the time.<p>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.

We spent 12 years on <a href="https:&#x2F;&#x2F;qbix.com&#x2F;platform" rel="nofollow">https:&#x2F;&#x2F;qbix.com&#x2F;platform</a> and along the way saw a lot of fads come and go.<p>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”).<p>That said, I have come to believe that people this decade will (and should) invert the idea of progressive enhancement to be client-first.<p>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.<p>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.<p>Sure, htmx can be used there. But there, too, it’s better to fetch JSON and interpret it on the client.<p>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 &lt;li class=“foo” onclick=“…”&gt; mixed in there which is a lot of extra weight on the wire.<p>If you are interested in learning more, I gave a whole talk about it:<p><a href="https:&#x2F;&#x2F;qbix.com&#x2F;blog&#x2F;2020&#x2F;01&#x2F;02&#x2F;the-case-for-building-client-first-web-apps&#x2F;" rel="nofollow">https:&#x2F;&#x2F;qbix.com&#x2F;blog&#x2F;2020&#x2F;01&#x2F;02&#x2F;the-case-for-building-clien...</a>

I think &quot;the future&quot; definitely isn&#x27;t some non-standard custom attributes.

&gt; It is very easy to support users who do not wish to, or cannot use JavaScript<p>I don&#x27;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&#x27;t support JS?

.. in an alternate universe.

No it&#x27;s not. Honestly, the fact that this website displays like shit without JavaScript enabled is ironic considering it uses HTMX.<p>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&#x2F;Go&#x2F;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_.<p>Otherwise, stick with RoR, Django, Laravel, or whatever ticks your fancies, but HTMX just ain&#x27;t for everyone and everything, it&#x27;s supposed to be used for hypermedia, not for web apps or anything else, just that: hypermedia.<p>And no, JavaScript libraries aren&#x27;t all &quot;complicated&quot; and &quot;full of churn&quot;, 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 &quot;React&quot; like it&#x27;s the only library in the world and the only way developers have written code for the last decade.<p>Also, tangentially related, can we as an industry stop acting like kids and stop following these &quot;trends&quot;? The author talks about a &quot;SPA-craze&quot; but what I&#x27;ve been seeing more and more now is the contrary movement, however it&#x27;s based on the same idea of a hype cycle, with developers adopting technology because it&#x27;s cool or whatever and not really considering what are their actual needs and which tools will provide them with that.<p>Rant over.

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.

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

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.

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

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

I&#x27;d rather see either:<p>* NextJS provide a holistic solution to backend code. Right now it&#x27;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.<p>* RedwoodJS become more mature.<p>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&#x27;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.

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

&gt; SPAs have allowed engineers to create some great web applications, but they come with a cost: ... Managing state on both the client and server<p>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.

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

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<p>&gt;Here we are getting a bit fancy and only allowing one row at a time to be edited, using hyperscript. <a href="https:&#x2F;&#x2F;hyperscript.org" rel="nofollow">https:&#x2F;&#x2F;hyperscript.org</a>

I&#x27;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.

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

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

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

As long as I don&#x27;t have to learn it.

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

What isn&#x27;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.

htmx is ajax wrapped in html to me.<p>it does not work for resource restricted (i.e. embedded) devices where you just can&#x27;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.

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.

It&#x27;s sort of like client side PHP. Is that a good thing or a bad thing?

Good luck with latency though for anything slightly interactive.

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

Reminds me of Drupal&#x27;s AHAH implementation.

Phoenix Liveview is the future :-)

Check out Qwik from builder.io

I don&#x27;t like XML syntax.

&gt; Hugely increased complexity both in terms of architecture and developer experience. You have to spend considerable time learning about frameworks.<p>You have to learn something. You can claim bloat in JS frameworks, but that isn’t solved by simply moving it to the server.<p>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.<p>&gt; Tooling is an ever-shifting landscape in terms of building and packaging code.<p>Yes. JS is not the only language with churn issues and dependency hell.<p>&gt; Managing state on both the client and server<p>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.<p>&gt; 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 &amp; slow for those on older hardware or in locations with slow and unreliable internet connections.<p>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&#x2F;retry issues. It’s much preferable to show stale state immediately and update in the background.<p>&gt; 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.<p>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.<p>&gt; 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.<p>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&#x2F;WASM?<p>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.

Xanadu.

No, it’s not.

No, it’s not

Title needs (2011). Not because that&#x27;s when it was written but because that&#x27;s when this technique was the future.

I am not going to be serious here, because, honestly, this is kind of ridiculous.<p>Two years ago I distinctly remember server side rendering piped thru websocket was future.<p>I also like how demo is visibly ugly, jQuery-style ugly. It&#x27;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.

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&#x27;t work in frameworks like nextjs and you need to apply hacky solutions. but I don&#x27;t see even libraries like nextjs being so self-praising. Come on, folks, there&#x27;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&#x27;t exist in the development logic. It&#x27;s nothing more than a smug one-man&#x27;s entertainment project. sorry but this is the truth.