Htmx Is the Future • Hacker News Board

Re: Htmx Is the Future

#871

Post by bigtunacan » Sun, May 14, 2023, 12:03 AM UTC

berkes wrote: post #831

bigtunacan wrote: post #820

Earlier quoted context omitted.

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.

You are missing the point. Sorry for that. It doesn't matter if an email has a valid format: that says almost nothing about it's validity. The only way you can be sure an address can receive mail(today) is by sending mail to it. All the rest is theatre. And all this only matters if the business cares about deliverability in the first place.

No, I understood your point and I agree sending the email and getting some type of read receipt is necessary.

You seem to think that because of this client validation should be skipped. On that point I disagree. If you can tell that it's not a valid email address (bigtunacan@goog obviously invalid since missing a TLD) then no email should be sent. Good UX is to let the customer/user know there is a mistake in the email address.

Re: Htmx Is the Future

#872

Post by nymanjon » Sun, May 14, 2023, 8:31 PM UTC

ukuina wrote: post #833

decross wrote: post #827

Earlier quoted context omitted.

You can embed a "backend" as a service worker and use htmx to interact with it. A proof of concept here: https://github.com/richardanaya/wasm-service

This is cool! A possible extension to HTMX would be to allow this kind of offloading to pure JS functions instead of requiring hacky intercepts. You would still have a clear separation of responsibilities between frontend rendering (by the browser only) and application logic (which only generates HTML as output).

I've done the same thing with vanilla JS in a service worker. I did it with my HTMF library -- similar to HTMX -- but not production ready and based on forms rather than being able to put your attributes everywhere. I'll have to create a simple to do app with HTMX that shows this same functionality. The Rust one is cool as you can do it with 150kB library. But I can do the same thing with 10kB with just simple JS.

Re: Htmx Is the Future

#873

Post by nymanjon » Sun, May 14, 2023, 8:33 PM UTC

dfabulich wrote: post #224

OliverM wrote: post #89

Earlier quoted context omitted.

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.

You should be able to do this with events in HTMX also. So, you could do an update or create something and then in HTMX capture the event and reload the component when that happens.

Re: Htmx Is the Future

#874

Post by thomond » Thu, May 18, 2023, 8:46 AM UTC

redonkulus wrote: post #286

We've been using similar architecture at Yahoo for many years now. We tried to go all in on a React framework that worked on the server and client, but the client was extremely slow to bootstrap due to downloading/parsing lots of React components, then React needing to rehydrate all the data and re-render the client. Not to mention rendering an entire React app on the server is a huge bottleneck for performance (can'…

I had no idea Yahoo

Re: Htmx Is the Future

#875

Post by elwell » Sun, May 21, 2023, 9:43 PM UTC

CRConrad wrote: post #864

elwell wrote: post #473

I 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?

HTMX is HTML is XML