Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Htmx Is the Future

quii.dev

Post reply on HN
Print view View original

181–190 of 875 posts

Re: Htmx Is the Future

#181

Post by afavour »

robertoandred wrote: post #165
afavour wrote: post #98

Earlier quoted context omitted.

I don’t think “forces” is the right way to think about it. By default a SPA breaks navigation history etc (it’s right in the name). It’s not onerous to reimplement it correctly but reimplement you must.

No it doesn't and no you don't. Every modern SPA framework has solved that problem long ago.

Right, so you agree: you have to reimplement it. You can just use a framework to do so.

It might be news to folks to learn that every single SPA framework has solved the problem entirely because it's really not an uncommon experience to have your browser history broken by a SPA. I believe that most frameworks implement the API correctly. I also believe a good number of developers use the framework incorrectly.

Re: Htmx Is the Future

#182

Post by yawaramin »

emodendroket wrote: post #171
yawaramin wrote: post #122

Earlier quoted context omitted.

Because HTML form validation is a built-in native feature of HTML, and it's integrated in the browser: Constantly reinventing the wheel in every app is silly.

These validators are rather limited and you’ll end up needing JavaScript for any Web app with anything beyond the simplest requirements.

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.

Re: Htmx Is the Future

#183

Post by MisterSandman »

brushfoot wrote: post #10

I use tech like HTMX because, as a team of one, I have no other choice. I tried using Angular in 2019, and it nearly sank me. The dependency graph was so convoluted that updates were basically impossible. Having a separate API meant that I had to write everything twice. My productivity plummeted. After that experience, I realized that what works for a front-end team may not work for me, and I went back to MPAs with J…

Angular is nototiously bad for single developers. React is much better, and things like Remix and Gatsby are even better.

Re: Htmx Is the Future

#184

Post by robertoandred »

mtlynch wrote: post #58

I really want to switch over to htmx, as I've moved away from SPAs frameworks, and I've been much happier. SPAs have so much abstraction, and modern, vanilla JavaScript is pretty decent to work with. The thing that keeps holding me back from htmx is that it breaks Content Security Policy (CSP), which means you lose an effective protection against XSS.[0] When I last asked the maintainer about this, the response was t…

If you don't like abstraction, why would use something as abstracted and non-standard is htmx?

Re: Htmx Is the Future

#185

Post by cogman10 »

recursivedoubts wrote: post #39

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…

It's not clear to me, but how and where is state managed?

In the OPs article, it looks like the only thing going over the line is UUIDs. How does the server know "this uuid refers to this element"? Does this require a sticky session between the browser and the backend? Are you pushing the state into a database or something? What does the multi-server backend end up looking like?

Re: Htmx Is the Future

#186

Post by jgoodhcg »

dfabulich wrote: post #56

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 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, even if what the user clicked on is a button heavily nested.

> it's impossible to implement "optimistic UI," ... hurting the user experience

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.

In the case of "useless without internet connection" do we really need optimistic UI. The actual experience of htmx is incredibly fast. There is no overhead of all the SPA stuff. No virtual dom, hardly any js. It's basically the speed of the network. In my limited practice I've actually felt the need to add delays because the update happens _too fast_.

I'm still evaluating htmx but not for any of the reasons you've stated. My biggest concern is ... do I want my api to talk in html?

Re: Htmx Is the Future

#187

Post by emodendroket »

yawaramin wrote: post #182
emodendroket wrote: post #171

Earlier quoted context omitted.

These validators are rather limited and you’ll end up needing JavaScript for any Web app with anything beyond the simplest requirements.

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?

Re: Htmx Is the Future

#188

Post by SoftTalker »

obpe wrote: post #3

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…

Well by definition the "average" team is not capable of writing a "great" app. So it doesn't matter so much what the technology stack is -- most of what is produced is pretty shitty regardless.

Re: Htmx Is the Future

#190

Post by recursivedoubts »

cogman10 wrote: post #185
recursivedoubts wrote: post #39

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…

It's not clear to me, but how and where is state managed? In the OPs article, it looks like the only thing going over the line is UUIDs. How does the server know "this uuid refers to this element"? Does this require a sticky session between the browser and the backend? Are you pushing the state into a database or something? What does the multi-server backend end up looking like?

https://htmx.org/essays/hateoas/
Post reply on HN