How does this differ from what we called rehydration a decade ago?
If nothing else, it's less of a silly moniker: Why would I want to get my Web page wet in the first place?!? Remember, DRY!
Htmx Is the Future
861–870 of 875 posts
Re: Htmx Is the Future
#862Earlier quoted context omitted.
https://htmx.org/essays/splitting-your-apis/
So, by your own words, in htmx: > the new API is simply reflected in the new HTML returned by the server Whereas with SPAs (my words) > the new API is simply reflected in the new json returned by the server I think I prefer the mental model of the api serving data and client rendering it.
HTML is the data format of Web pages. That's what the client, the browser, is built to render.
Re: Htmx Is the Future
#863Earlier quoted context omitted.
> Imagine some cool feature like... collaborative editing. In my opinion, the whole point of the article and for everyone who is backing htmx is that SPA frameworks are too complex (and a liability) for solo/small teams or projects that don't need `collaborative editing`(or other advanced stuff).
> In my opinion, the whole point of the article Well, in my opinion, the article claims "HTMX is the future" as its title, and so it's impossible to interpret the arguments in any other way than "the user experience benefits of the SPA might matter to the users, but I think it's stupid because I dislike JS"
> Well, in my opinion, the article claims "HTMX is the future" as its title,
Titles are by necessity summary in nature. If you want the whole complexity and nuance of the article in the title, the whole article would have to be the title. It's a bit too long for that. (And then everyone would complain that there was no additional meat to the body text.)
> and so it's impossible to interpret the arguments in any other way than "the user experience benefits of the SPA might matter to the users, but I think it's stupid because I dislike JS"
No, sorry, that's BS: It's eminently possible to interpret the arguments differently. All you have to take into account is that a less abbreviated (and frankly still a bit too long) version of the title could have been "HTMX is the future for solo/small teams or projects that don't need `collaborative editing`(or other advanced stuff)".
HTH!
Re: Htmx Is the Future
#864I don't like XML syntax.
Yeah, frightfully verbose. (I suppose that's why JSON seems so much more popular nowadays; at the very least a large contributing cause.) But WTF does that have to do with anything here, which wasn't about XML at all?
Re: Htmx Is the Future
#865Earlier quoted context omitted.
> In my opinion, the whole point of the article Well, in my opinion, the article claims "HTMX is the future" as its title, and so it's impossible to interpret the arguments in any other way than "the user experience benefits of the SPA might matter to the users, but I think it's stupid because I dislike JS"
> Well, in my opinion, the article claims "HTMX is the future" as its title, Titles are by necessity summary in nature. If you want the whole complexity and nuance of the article in the title, the whole article would have to be the title. It's a bit too long for that. (And then everyone would complain that there was no additional meat to the body text.) > and so it's impossible to interpret the arguments in any other…
> Titles are by necessity summary in nature
Ok, that's why I made arguments against the body of the text. Did you read my initial post? I'm sure you must've, which makes it so strange you'd come attack this argument while pretending that the other ones don't exist
> It's eminently possible to interpret the arguments differently.
It's really not. The whole thing is a series of strawmans aiming to justify degrading user experience to avoid developer "complexity", but then that developer complexity is grossly overstated, as if from someone who has never dipped their toe in it decided that each complaint they had heard about it was spoken by God himself.
Indeed, my whole first comment is thoroughly discarding each of these strawmans before I grew frustrated by the fact that the author and the thread were both reciting this 2015-era anti-JS dogma.
I suggest you go try to make counterarguments to those points instead of my exasperated reply to someone adding nothing to the convo.
HTH!
Re: Htmx Is the Future
#866I don't know. The tabs example on the htmx page is perceptibly slow to me. Making a rest call every time I switch a tab, each time sending 90% of the same html skeleton data over the wire feels like a sin to me. Returning html from my api also feels like a sin.
> Returning html from my api also feels like a sin. Sorry, but that's just... Silly. HTML is what the Web is all about.
Most of my apis are consumed my multiple clients, many without user interfaces (other backend systems), some with mobile user interfaces, some with web interfaces. I should make my backend clients parse HTML? Or my mobile clients parse HTML? I don't see any benefit to coupling data to a visual markup language, unless you are only serving web ui clients, and have no plans for that to ever change. Or I should stand up additional services (and pay for their operation and maintenance) just to server side render my data wrapped in html? That seems sillier to me, but to each their own.
Re: Htmx Is the Future
#867I 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…
Unpoly and Hotwire are somewhat similar to HTMX, but they update entire sections of a page (i.e., "page fragments") as you describe. They perform a DOM diff and update everything wrapped inside an HTML tag (e.g., a ) with a special attribute. Unpoly does this within the app's normal request/response cycle, while Hotwire uses websockets to stream updates.
Re: Htmx Is the Future
#868Earlier quoted context omitted.
I remember that all the web shops in my town that did Ruby on Rails sites efficiently felt they had to switch to Angular about the same time and they never regained their footing in the Angular age although it seems they can finally get things sorta kinda done with React. Client-side validation is used as an excuse for React but we were doing client-side validation in 1999 with plain ordinary Javascript. If the real…
Even worse: Client-side validation and server-side validation (and database integrity validation) are all their own domains! I call all of these "domain logic" or domain validation just to be sure. Yes, they overlap. Sure, you'll need some repetition and maybe, indeed, some DSL or tooling to share some of the overlapping ones across the boundaries. But no! They are not the same. A "this email is already in use" is se…
Even worse^2, client-side validation may differ from server-side validation and from database-side validation. I cannot imagine client-side checking for a validity of a phone number using freshly downloaded database of current carriers and assignment rules in different countries, I prefer to maintain it server-side, even though it could be possible (thanks to guys from Google and their Libphonenumber). But again, I don't trust the client, so it needs to be re-validated later. Then it will be converted to some native data structure on order to make things faster and unified, a later it will go to a database with its own coercion and validation routines just before application will do a query. This validation trusts the format so it will just make sure the result of conversion is correct. But then the query itself carries a validation aspect: when the number must be unique in some context, it will return error, which will bubble up to user.
Re: Htmx Is the Future
#869Earlier quoted context omitted.
I remember that all the web shops in my town that did Ruby on Rails sites efficiently felt they had to switch to Angular about the same time and they never regained their footing in the Angular age although it seems they can finally get things sorta kinda done with React. Client-side validation is used as an excuse for React but we were doing client-side validation in 1999 with plain ordinary Javascript. If the real…
It really wasnt about client side validation or UX at all. You can have great UX with an MPA or SPA. Although I do think it’s slightly easier in an SPA if you have a complex client like a customizable dashboard. Ultimately it’s about splitting your app into a server and client with a clear API bounday. Decoupling the client and server means they can be separate teams with clearly definied roles and responsibilities.…
IMHO it is completly doable to do a state transfer with HTML to a mobile device instead of writing a separate application using a separate technology. Then we can deal with coupling server-side, e.g. "view's team" can use some templating system and "core team" can play with logic using JSP-Model2 architecture or something similar.
Re: Htmx Is the Future
#870Earlier quoted context omitted.
It really wasnt about client side validation or UX at all. You can have great UX with an MPA or SPA. Although I do think it’s slightly easier in an SPA if you have a complex client like a customizable dashboard. Ultimately it’s about splitting your app into a server and client with a clear API bounday. Decoupling the client and server means they can be separate teams with clearly definied roles and responsibilities.…
Generally you don’t want to reuse the same API for different types of clients, you want backends for frontends (BFF) that are specialized for each use and can be moved forward in their own pace. The needs and the requirements differs a lot between a browser, app and server-to-server call. And just because you serve HTML doesn’t necessary mean that you backend code is tightly coupled with the view code, HTML is just o…
Agreed! There are many things in IT industry that are prone to this kind of almost magical thinking, and "boundaries" / "tight coupling" is one of them. I realized that when tried to actually compare some stuff I had been doing at work through years, being fascinated with uncoupling things. Well, if you start measuring it, even at the top level (time, people, money spent) then it is so clear that there are obvious tight couplings at architecture level (like data on wire containing some structure or transferring a state of application), and it is very tempting to remove them. But then we may actually find ourselves having a subtle tight coupling, totally not obvious, but effecting in a need of two teams or even two tech stacks and a budget more than twice the size because of communication / coordination costs.