Htmx Is the Future • Hacker News Board

Re: Htmx Is the Future

#81

Post by obpe » Fri, May 05, 2023, 4:32 PM UTC

pphysch wrote: post #34

obpe wrote: post #21

Earlier quoted context omitted.

I have never heard this before. Can you elaborate on the differences? What do you validate on the client side that you don't on the server and vice versa?

Some validations require capabilities that you don't want/need the client to have. There are also validations that can improve UX but aren't meaningful on the server. Like a "password strength meter", or "caps lock is on". Religiously deploying the same validations to client and server can be done, but it misses the point that the former is untrusted and just for UX. And will involve a lot of extra engineering and un…

I see, I have never implemented those types of validations. We do religiously deploy the same validation on client and server to explicitly avoid the mismatch of client/server validation. Having the client submit "valid" input only to have server reject it is something we have run into. Having only client side validation is something I have never run into.

Also, in my opinion things like you suggest you shouldn't do. A password strength metre is only going to give attackers hints at the passwords you have in your system. And I have not see a caps lock on warning in forever. The only password validation we do is the length which is pretty easy to validate on client and server.

Re: Htmx Is the Future

#82

Post by emodendroket » Fri, May 05, 2023, 4:32 PM UTC

pphysch wrote: post #18

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…

Client side validation is for UX. Server side validation is for security, correctness, etc. They are different features that require different code. Blending the two is asking for bugs and vulnerabilities and unnecessary toil. The real reason that SPAs arose is user analytics.

I don't understand why that should be the case. There are a lot of checks that end up needing to be repeated twice with no change in logic (e.g., username length needs to be validated on both ends).

Re: Htmx Is the Future

#83

Post by emodendroket » Fri, May 05, 2023, 4:33 PM UTC

nagyf wrote: post #63

obpe wrote: post #21

Earlier quoted context omitted.

I have never heard this before. Can you elaborate on the differences? What do you validate on the client side that you don't on the server and vice versa?

Everything has to be validated on the server side simply for security reasons. Even if you do all validation on the client side, which prevents the users submitting a form with invalid data, an attacker can work around that. e.g. submitting the form with valid data, but intercepting the request and modifying the values there. Or simply just using curl with malicious/invalid data. You still need the client side valida…

Yeah but that doesn't answer why you can't share validators between the backend and the frontend if both are written in the same language.

Re: Htmx Is the Future

#84

Post by jasfi » Fri, May 05, 2023, 4:33 PM UTC

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…

I'm using React, and I feel like I can manage as a team of one. But React has a huge community, which means lots of libraries for just about anything you need.

I previously used HTMX for another project of mine, and it worked fine too. I did, however, feel limited compared to React because of what's available.

Re: Htmx Is the Future

#85

Post by mlboss » Fri, May 05, 2023, 4:34 PM UTC

optymizer wrote: post #52

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?

It is doing the same. Just makes cleaner and easier.

Re: Htmx Is the Future

#86

Post by recursivedoubts » Fri, May 05, 2023, 4:36 PM UTC

benatkin wrote: post #77

recursivedoubts wrote: post #65

Earlier quoted context omitted.

it absolutely is hypermedia we generalize HTML's hypermedia controls in the following way: - any HTML element can become a hypermedia control - any event can drive a hypermedia interaction - any element can be the target of a hypermedia interaction (transclusion, a concept in hypermedia not implemented by HTML) all server interactions are done in terms of hypermedia, just like w/links and forms it also makes PUT, PAT…

Links and forms are the bread and butter of many frameworks. Like with HTMX, SvelteKit and Remix forms won't function properly without the framework.

if you read the article, you will see that you can use htmx as progressive enhancement quite easily since it is consonant with the vanilla HTML approach.

what makes htmx a hypermedia framework is the exchange of hypermedia with the server, this satisfies the hypermedia constraint (HATEOAS) of REST. there are other libraries that are also hypermedia oriented, such as unpoly.

it is a different approach to building web applications than the JSON/RPC style that is popular today

i encourage you to read the linked article, and, if it is interesting to you, the essays at https://htmx.org/essays, and then potentially https://hypermedia.systems

Re: Htmx Is the Future

#87

Post by recursivedoubts » Fri, May 05, 2023, 4:37 PM UTC

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…

never tell me the odds, kid

https://htmx.org/img/memes/whowillwin.png

Re: Htmx Is the Future

#88

Post by halfcat » Fri, May 05, 2023, 4:37 PM UTC

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…

> a major selling point of Node was running JS on both the client and server so you can write the code once

But we don’t have JS devs.

We have a team of Python/PHP/Elixir/Ruby/whatever devs and are incredibly productive with our productivity stacks of Django/Laravel/Phoenix/Rails/whatever.

Re: Htmx Is the Future

#89

Post by OliverM » Fri, May 05, 2023, 4:37 PM UTC

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 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 full-page responses solves the problem by default.

Of course, I've not used Turbolinks, so I don't know what issues applied there.

Edit: I'm not saying htmx is the future either. I'd love to see how they handle offline-first (if at all) or intermittent network connectivity. Currently most SPAs are bad at that too...

Re: Htmx Is the Future

#90

Post by jonahx » Fri, May 05, 2023, 4:38 PM UTC

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…

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

While I am a fan of MPAs and htmx, and personally find the dev experience simpler, I cannot argue with this.

The high-order bit is always the dev's skill at managing complexity. We want so badly for this to be a technology problem, but it's fundamentally not. Which isn't to say that specific tech can't matter at all -- only that its effect is secondary to the human using the tech.