i am the creator of htmx, this is a great article that touches on a lot of the advantages of the hypermedia approach (two big ones: simplicity & it eliminates the two-codebase problem, which puts pressure on teams to adopt js on the backend even if it isn't the best server side option) hypermedia isn't ideal for everything[1], but it is an interesting & useful technology and libraries like htmx make it much more rele…
The article under discussion here appears to be saying that HTMX can work without Javascript enabled. But HTMX itself is a Javascript library, correct? So how can it work without Javascript enabled?
I've spent almost my entire career working on react based SPAs and react native mobile apps. I've just started playing around with HTMX. > no good story for what happens when one component in a tree needs to update another component in the tree HTMX has a decent answer to this. Any component can target replacement for any other component. So if the state of everything on the page changes then re-render the whole page…
> Do we actually need optimistic UI? Some apps need to work in offline mode sure, like offline maps or audiobooks or something. The HTMX author agrees, this is not the solution for that. Most of the stuff I have worked on though ... is useless without an internet connection. > It's basically the speed of the network. Does your stuff work on mobile web? Mobile web requests can easily take seconds, and on a dodgy conne…
I want my stuff to work on mobile web. What I don't want is for stuff to look like it worked on mobile web, because the front end is "optimistic", but it actually didn't work. I find this to be a much worse user experience than having to wait for a round trip most of the time.
This is not correct. SPAs and web components were pioneered by Google with the introduction of Angular. Later, Vue was invented by a previous Google employee who had worked on Angular. Finally, Facebook came up with React (it's a "reaction" to Angular) because they could not be seen using a Google product. If anything, SPAs make metrics harder because they hide the real behavior of the page in local JS/TS code and do…
React was significantly better than Angular (version 1). Please don't pretend it was merely NIH syndrome that led to its creation.
I mean, they also came out with 'flow' after MS came out with TypeScript... I def don't want to think it was NIH syndrome, but it smells fishy.
People were making this prediction ten years ago. It was wrong then, and it's wrong now. This article makes its case about Htmx, but points out that its argument applies equally to Hotwired (formerly Turbolinks). Both Htmx and Hotwired/Turbolinks use custom HTML attributes with just a little bit of client-side JS to allow client-side requests to replace fragments of a page with HTML generated on the server side. But…
I've not used Htmx, but a cursory browse of their docs gives https://htmx.org/extensions/multi-swap/ which seems to solve exactly this problem. And thinking about it, what makes it as difficult as you say? If you've a js-library on the client you control you can definitely send payloads that library could interpret to replace multiple locations as needed. And if the client doesn't have js turned on the fallback to fu…
I've edited my post to clarify.
Multi-swap is possible, but 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.
It's kinda funny to me that many of the "pros" of this approach are the exact reasons so many abandoned MPAs in the first place. For instance, a major selling point of Node was running JS on both the client and server so you can write the code once. It's a pretty shitty client experience if you have to do a network request for each and every validation of user input. Also, there was a push to move the shitty code fro…
> We moved away for MPAs because they were bloated, slow and difficult to work with. SPAs have definitely become what they sought to replace. Plus we now get the benefit of people trying to "replace" built in browser functionality with custom code, either The SPA broke it... Back button broken and a buggy custom implementation is there instead? Check. or They're changing things because they're already so far from def…
Mail is not a good example. Why would you like to read a collection of documents through A Single Page interface? Gmail was a fantastic improvement over Hotmail and Yahoo, and it provided UX innovations we still haven't caught up with, yes, but MPAs are naturally more suited for reading and composing them. Overriding perfectly clear HTML structure with javascript should be reserved for web experiences that are not documents: that is, videogames, editors, etc (Google *Maps* is a good example). The quality of the product usually depends on how it was implemented more than the underlying technology, but as I see it is: if it's a Document, if the solution has a clear paper-like analogue, HTML is usually the best way to code it, structure it, express it. Let a web page be a web page and let the user browse through it with a web browser. If it's not, well, alright, let's import OpenGL.
The first SPA I wrote, I wrote in React for my use and for the use of friends. I spent about 3 days getting it working and then 3 months getting it to usable performance on my phone. There were no analytics, no binary data (100% text), just a bunch of editable values and such. I ended up having to split it up into a bunch of tabs just to reduce the size of the vdom.
"The size of the vdom" would not destroy performance like you're saying.
I've been told that before. Maybe it was something else; I don't know.
All I know is that I was unable to figure out what it was, and I bounced it off a few people online, and the performance scaled inversely with the number of DOM nodes.
This is not correct. SPAs and web components were pioneered by Google with the introduction of Angular. Later, Vue was invented by a previous Google employee who had worked on Angular. Finally, Facebook came up with React (it's a "reaction" to Angular) because they could not be seen using a Google product. If anything, SPAs make metrics harder because they hide the real behavior of the page in local JS/TS code and do…
A lot of misconceptions here. Google is an AdTech company par excellence. You don't need to do hacky URL tracking with SPAs. That's the point. >Also, fewer server interactions means fewer opportunities to capture user behavior or affect it at the server level. SPAs certainly do not have "fewer server interactions". What do you think an API call is? "React" comes from "reactive web app", not "reaction to a competitor'…
I work with SPAs with API calls every day. It definitely reduces the server interactions over computing everything on that side, and it gives fewer points of contact with the server about the user's behavior. For example, many clicks and other actions will not result in any server contact at all.
I'm aware that they call it "reactive" but I'll stick with my rationale. There is no way they would use a Google product like that.
meta: I love when htmx is highlighted in HN because the discussions branch into alternatives and different ways of doing web dev. It's very enriching to think outside the box!
This is not correct. SPAs and web components were pioneered by Google with the introduction of Angular. Later, Vue was invented by a previous Google employee who had worked on Angular. Finally, Facebook came up with React (it's a "reaction" to Angular) because they could not be seen using a Google product. If anything, SPAs make metrics harder because they hide the real behavior of the page in local JS/TS code and do…
React was significantly better than Angular (version 1). Please don't pretend it was merely NIH syndrome that led to its creation.
But that would suffice! Facebook does not use any platforms from people who might compete with them. Why would they?
They're limited in some ways but they're just about powerful enough to do almost everything you'd need or want to do client-side without making a network request. In my opinion it doesn't make sense to try to fit in tons of complex validation logic in the frontend.
Why make a round trip if you don’t have to?
Some kinds of validation really do need the round trip. If somebody is choosing a user name on a sign up for you do need to do a database lookup.
If your back end is fast and your HTML is lean, backend requests to validate can complete in less time than any of the 300 javascript, CSS, tracker, font, and other requests that a fashionable modern webapp does for no good reason...
It's true though that many back ends are run on the cheap with slow programming languages and single-thread runtimes like node.js that compete with slow javascript build systems to make people think slow is the new normal.