by quii on 5/5/23, 2:32 PM with 651 comments
by obpe on 5/5/23, 3:49 PM
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.
by brushfoot on 5/5/23, 3:59 PM
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.
by recursivedoubts on 5/5/23, 4:16 PM
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:
[1] - https://htmx.org/essays/when-to-use-hypermedia/
[2] - https://hyperview.org/
by redonkulus on 5/5/23, 6:51 PM
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.
by aidenn0 on 5/5/23, 4:00 PM
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?
by michaelchisari on 5/5/23, 9:20 PM
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.
by mtlynch on 5/5/23, 4:24 PM
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
[1] https://news.ycombinator.com/item?id=32158352
by dfabulich on 5/5/23, 4:24 PM
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/ 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-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.
by vp8989 on 5/5/23, 4:12 PM
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?
by rektide on 5/5/23, 3:04 PM
I see a lot of resemblance to 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).
by diegof79 on 5/5/23, 7:41 PM
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.
by majormajor on 5/5/23, 4:43 PM
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.
by 0xbadcafebee on 5/5/23, 4:51 PM
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.
by pkelly on 5/5/23, 5:56 PM
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.
by poidos on 5/5/23, 3:55 PM
by MattyRad on 5/6/23, 5:20 AM
> 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.
by jmull on 5/5/23, 8:41 PM
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.
by Veuxdo on 5/5/23, 4:19 PM
I mean, aren't these baseline "get computers to do stuff" things?
by optymizer on 5/5/23, 4:21 PM
by fogzen on 5/5/23, 4:59 PM
HTMX is cool. HTMX may fit your needs. But it’s not enough for providing the best possible user experience.
by chrsjxn on 5/5/23, 7:56 PM
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.
by iamsaitam on 5/5/23, 4:27 PM
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?
by Pet_Ant on 5/5/23, 3:54 PM
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.
by tacone on 5/5/23, 5:52 PM
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.
by BeefySwain on 5/5/23, 5:31 PM
If anyone is looking to discuss making Hypermedia Driven Applications with HTMX in Python, head over to the discussions there!
by tgbugs on 5/5/23, 4:43 PM
by xutopia on 5/5/23, 7:22 PM
by s1k3s on 5/5/23, 4:50 PM
The future is whatever works best for your use-case.
by lvh on 5/6/23, 12:57 AM
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).
by jdthedisciple on 5/5/23, 9:30 PM
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.
by tabtab on 5/5/23, 11:28 PM
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_...
Let's byte the bullet and create a GUI markup standard. Perhaps base it off Tk or Qt kits to avoid starting from scratch.
by peter_retief on 5/5/23, 4:23 PM
The concept is great but why has it taken so long?
by lucidguppy on 5/5/23, 4:30 PM
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.
by incrudible on 5/5/23, 7:45 PM
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.
by janosd on 5/5/23, 10:37 PM
by Alifatisk on 5/5/23, 4:38 PM
by kurtextrem on 5/6/23, 6:06 AM
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?
by aigoochamna on 5/5/23, 8:18 PM
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.
by anyonecancode on 5/5/23, 5:18 PM
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.
by yellowapple on 5/5/23, 5:01 PM
by hu3 on 5/5/23, 5:40 PM
by AtlasBarfed on 5/6/23, 3:11 AM
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.
by divan on 5/5/23, 5:22 PM
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
Web development without HTML/CSS/JS is the future.
by mal-2 on 5/5/23, 5:24 PM
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.
by nine_k on 5/5/23, 9:42 PM
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.
by branko_d on 5/5/23, 6:04 PM
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?
by thomasreggi on 5/5/23, 5:08 PM
by auct on 5/5/23, 5:07 PM
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.
by honkycat on 5/5/23, 4:42 PM
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.
by w10-1 on 5/5/23, 6:03 PM
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.
by jimmaswell on 5/5/23, 4:04 PM
Relevant code:
https://github.com/ldyeax/jimm.horse/blob/master/j/j.php
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 - 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.
by themaximalist on 5/5/23, 11:11 PM
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.
by PaulHoule on 5/5/23, 5:00 PM
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
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.)
by themodelplumber on 5/5/23, 4:32 PM
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.
by tkiolp4 on 5/5/23, 8:28 PM
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.
by silver-arrow on 5/6/23, 12:02 PM
by denton-scratch on 5/5/23, 8:17 PM
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.
by kubota on 5/5/23, 8:29 PM
by mikece on 5/5/23, 3:57 PM
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.
by nologic01 on 5/5/23, 4:45 PM
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.
by jksmith on 5/5/23, 4:57 PM
by bottlepalm on 5/5/23, 6:25 PM
by eimrine on 5/5/23, 4:17 PM
Is this really the future?
by wibblewobble124 on 5/5/23, 8:09 PM
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.
by aabbcc1241 on 5/8/23, 3:43 AM
This approach has been implemented in most popular programming languages used for backend development: https://github.com/liveviews/liveviews
by loxs on 5/5/23, 7:37 PM
by klysm on 5/5/23, 8:12 PM
by munbun on 5/5/23, 5:09 PM
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.
by nawgz on 5/5/23, 4:00 PM
> 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.
by bfung on 5/5/23, 10:27 PM
The more realistic and practical read is https://htmx.org/essays/when-to-use-hypermedia/#hypermedia-n...
by quickthrower2 on 5/5/23, 10:20 PM
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.
by pwpw on 5/5/23, 5:56 PM
by quest88 on 5/5/23, 5:17 PM
> 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.
by manx on 5/5/23, 11:44 PM
by rglover on 5/5/23, 5:05 PM
In a quote:
> "So much complexity in software comes from trying to make one thing do two things." - Ryan Singer (Basecamp/37Signals)
by chrislan815 on 5/5/23, 4:15 PM
by knallfrosch on 5/5/23, 11:17 PM
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!
by exabrial on 5/6/23, 3:57 AM
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.
by EGreg on 5/5/23, 4:07 PM
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-clien...
by can16358p on 5/5/23, 5:17 PM
by hashworks on 5/6/23, 8:51 AM
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?
by lofaszvanitt on 5/5/23, 4:25 PM
by doodlesdev on 5/5/23, 7:34 PM
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.
by qgin on 5/5/23, 5:26 PM
by jcmontx on 5/5/23, 7:02 PM
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.
by tommica on 5/6/23, 5:53 AM
by tedunangst on 5/5/23, 4:29 PM
by chenster on 5/6/23, 5:31 AM
by teaearlgraycold on 5/5/23, 7:55 PM
* 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.
by keb_ on 5/5/23, 4:42 PM
by sublinear on 5/5/23, 4:08 PM
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.
by robertoandred on 5/5/23, 5:17 PM
by hankchinaski on 5/5/23, 6:40 PM
>Here we are getting a bit fancy and only allowing one row at a time to be edited, using hyperscript. https://hyperscript.org
by CodeCompost on 5/5/23, 6:35 PM
by nologic01 on 5/6/23, 5:50 AM
by xkcd1963 on 5/5/23, 10:22 PM
by tbjgolden on 5/6/23, 12:50 PM
by unixhero on 5/5/23, 9:02 PM
by WesSouza on 5/6/23, 12:23 PM
by shams93 on 5/6/23, 12:42 AM
by synergy20 on 5/5/23, 10:48 PM
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.
by iamgopal on 5/5/23, 5:07 PM
by Animats on 5/5/23, 6:20 PM
by pier25 on 5/5/23, 4:52 PM
by kokizzu5 on 5/5/23, 5:05 PM
by mike503 on 5/5/23, 7:17 PM
by st3fan on 5/6/23, 12:11 AM
by intellix on 5/6/23, 6:52 PM
by elwell on 5/6/23, 12:31 AM
by klabb3 on 5/5/23, 7:54 PM
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.
by tudorw on 5/5/23, 5:00 PM
by 0xblinq on 5/6/23, 8:17 PM
by bioinformatics on 5/6/23, 12:22 AM
by phpnode on 5/5/23, 3:58 PM
by hamilyon2 on 5/5/23, 6:16 PM
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.
by pictur on 5/5/23, 4:07 PM