Htmx Is the Future • Hacker News Board

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…

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

(I'm not actually arguing with you, just thinking out loud)

This is often repeated but I don't think it even close to a primary reason.

The primary reason you build JS web clients is for the same reason you build any client: the client owns the whole client app state and experience.

It's only a fluke of the web that "MPA" even means anything. While it obviously has its benefits, we take for granted how weird it is for a server to send UI over the wire. I don't see why it would be the default to build things that way except for habit. It makes more sense to look at MPA as a certain flavor of optimization and trade-offs imo which is why defaulting to MPA vs SPA never made sense now that SPA client tooling has come such a long way.

For example, SPA gives you the ability to write your JS web client the same way you build any other client instead of this weird thing where a server sends an initial UI state over the wire and then you add JS to "hydrate" it, and then ensuring the server and client UIs are synchronized.

Htmx has similar downsides of MPAs since you need to be sure that every server endpoint sends an html fragment that syncs up to the rest of the client UI assumptions. Something as simple as changing a div's class name might incur html changes across many html-sending api endpoints.

Anyways, client development is hard. Turns out nothing was a panacea and it's all just trade-offs.

Re: Htmx Is the Future

#819

Post by scoofy » Sun, May 07, 2023, 1:54 PM UTC

niux wrote: post #600

scoofy wrote: post #53

Earlier quoted context omitted.

I use htmx on my current project, and it's like a dream. I'm happy to sacrifice a bit of bandwidth to be able to do all the heavy lifting in python. On top of that, it makes testing much much easier since it turns everything is GET and POST requests. I'd add a couple features if I were working there (making css changes and multiple requests to multiple targets standard), but as it stands, it's a pleasure to work in.

What framework do you use for Python?

Flask

Re: Htmx Is the Future

#820

Post by bigtunacan » Sun, May 07, 2023, 5:14 PM UTC

berkes wrote: post #729

philderbeast wrote: post #494

Earlier quoted context omitted.

"A "this doesn't look like an email-address" unfortunately this also needs to be done server side, unless your trusting the client to send you information that is what your expecting? client side validation makes for a good user experience, but it does not replace the requirement to validate things server side, and many times you will end up doing the same validations for different reasons.

"It depends". If it's merely a hint for the user (did you make a typo?) there's no need to ensure "this is a valid email address". in fact: foo@gamil.com is perfect valid email-address, but quite likely (though not certain!) not what the user meant. I've seen hundreds of email-adres-format-validations in my career, server-side. The most horrible regexps, the most naïve assumptions[1]. But to what end? What -this is a…

Just because some places implemented the validation wrong does not mean the validation should not occur.

The validation is there to catch user mistakes before sending a validation email and ending up with unusable account creation.