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

831–840 of 875 posts

Re: Htmx Is the Future

#831

Post by berkes »

bigtunacan wrote: post #820
berkes wrote: post #729

Earlier quoted context omitted.

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

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.

Re: Htmx Is the Future

#832

Post by nsonha »

bigtunacan wrote: post #519
nsonha wrote: post #505

Earlier quoted context omitted.

Can you argue a bit more genuinely and not pick on such a minor point as validation? I think parent mentioned other points? How about the logical shift to let client do client things, and server do server things? Server concatting html strings for bilions of users over and over again seems pretty stupid.

No more stupid than concatting json for those same users

Why not stress the argument further and say server "concats" http strings or sql strings? It's because of the nonsense from the web platform that inefficient text-based transports such as json became prevalent in the back-end btw.

Re: Htmx Is the Future

#833

Post by ukuina »

decross wrote: post #827
ukuina wrote: post #465

Earlier quoted context omitted.

Doesn't this make serverless read-only apps (that only require a fileserver) effectively impossible? In a serverless read-only app, all business logic and state is maintained on the browser.

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

Re: Htmx Is the Future

#834

Post by roguas »

com2kid wrote: post #157
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…

> Also, there was a push to move the shitty code from the server to the client to free up server resources and prevent your servers from ruining the experience for everyone. People forget how bad MPAs were, and how expensive/complicated they were to run. Front end frameworks like svelte let you write nearly pure HTML and JS, and then the backend just supplies data. Having the backend write HTML seems bonkers to me, i…

We decided for fun to do a small project in htmx (we had to pick something, one person opted strongly). Yeah, I was cringing and still am. I fully support frontend/backend split status quo.

For stuff that is uncomplicated I much prefer svelte as it still keeps the wall between frontend/backend but let's you do a lot of "yolo frontend" that is shortlived and gets fixed. I run small startup on the side" svelte fe + clojure be. It works great as I have different acceptance for crap in frontend (if I can fix something with style="", I do and I don't care). I often hotfix a lot of stuff in front where I can and just deploy to return later and find better solution that involves some changes in backend.

I can't imagine that for moving a button I would have to do deployment dance for whole app that in my case has 3 components(where one is distributed and requires strict backwards compat).

Re: Htmx Is the Future

#835

Post by La_Beffa »

emodendroket wrote: post #82
pphysch wrote: post #18

Earlier quoted context omitted.

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

A possible solution could be what ASP.NET does where you can just set the validation rules in the backend and you get the client side one too, the magic is done by jQuery unobstrusive validation. Of course something a bit more up to date than jQuery would be ideal but you got the gist.

https://learn.microsoft.com/en-us/aspnet/core/mvc/models/val...

Re: Htmx Is the Future

#836

Post by RussianCow »

narag wrote: post #571
cromulent wrote: post #515

Earlier quoted context omitted.

I think this is the point of the client side check though - if the user makes a typo (e.g. gamil.com) then the client side validation can prompt them to check, before the server sends the validation email and annoys the owner of the typoed address.

My point is that it doesn't matter if some arbitrary string looks like an email address, you need to check. If it isn't valid the server won't annoy anyone. The problem is that the address is valid. And not theirs, it's mine. The moment the users need to be careful, they will. Make the problem theirs, not mine. "Sorry sir, the address you provided returns error" or "haven't you received the confirmation email YET? re…

You can (and should) definitely do both. But needing to validate that a user has access to the entered email address doesn't mean you should do away with client-side validation entirely.

Re: Htmx Is the Future

#837

Post by 149203 »

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…

Every company I've been a part of has redesigned their front end at least once.

These redesigns would be a lot more difficult if we had to edit HTML on the client and the HTML that a server returns.

Also, HTMX is best styled with semantic classes. Which is a problem for companies using Tailwind and utility classes in their HTML. With class-heavy HTML it's nearly impossible to redesign in two different places. And performance suffers and returning larger chunks of HTML.

Despite all that, I want HTMX to be the standard way companies develop for the web. But these 2 problems need to be addressed first, I feel, before companies (like mine) take the leap.

Re: Htmx Is the Future

#838

Post by gofreddygo »

giraffe_lady wrote: post #36
duxup wrote: post #11

Earlier quoted context omitted.

I often work on an old ColdFusion application. It's amusing that for a long time the response was "oh man that sounds terrible". Now it is "oh hey that's server side rendered ... is it a new framework?". The cycle continues. I end up writing all sorts of things and there are times when I'm working on one and think "this would be better as Y" and then on Y "oh man this should be Z". There are days where I just opt for…

I also switch back and forth between two large projects written in different decades and it definitely gives an interesting perspective on this. Basically every time I'm in php I go "oh yeah I see why we do react now" and every time I'm in react I go "oh right I see why php still exists."

> ... I see why we do react now

I switch between a fair variety frontend, backend myself and have never had that reaction.

It's always, I could do exactly this in 2005 using jquery + JSP, it would not need any of these 1500 dependencies and the user would see absolutely no difference (except downloading 10 times more js today at 5G speeds)

The scalability issues non-facebook scale webapps are trying to solve for do not exist. These apps will be dead before they reach a 10% of that scale and yet the project folks just don't get it.

anecdotally, github project bookmarks I have 3-4 years ago won't even compile today. a large chunk of projects from 2010 still work. Including mine I wrote a decade ago as a newbie js junkie.

Why ? Dependencies.

Re: Htmx Is the Future

#839

Post by willio58 »

ukuina wrote: post #461
agrippanux wrote: post #440

Earlier quoted context omitted.

You may of not used React in the past few years, but setState fell out of favor a while ago with the release of the useState hook and Redux (which I agree is an abomination) isn't necessary for 95% (imo) cases, again thanks to hooks. For bound variables you can use MobX or signals in Preact.

How does something "fall out of favor" in React? Is it deprecated?

The recommendation for React projects for the past few years has been to write everything using functional components vs the old class-based components. In function-based components, you can only use hooks so useState is that's why the parent comment is referring to.

Re: Htmx Is the Future

#840

Post by taeric »

kbenson wrote: post #830
taeric wrote: post #488

Earlier quoted context omitted.

I find it hard to really agree that the backend of Gmail would be more involved with a thinner frontend. The "low bandwidth html" version sorta gives the lie, there...

I'm not sure what you're getting at. I'm not talking about bandwidth usage at all . I'm talking about CPU, memory and IO (as in disk, not client server transfer) usage.

I'd wager all of those things are still lower on their "low bandwidth" option.

Now, I will grant that it does less. Probably lacking a lot of the "presence detection" that is done in the thick client. Certainly lacking a lot of the newer ad stuff they are pushing at.

But the rest could be offset by a very basic N-tier application where the "envelope" of the client HTML is rather cheaply added to any outgoing message. And the vast majority that goes into "determining what data is being sent, being able to just redisplay the data you have when you browse back to the main page instead of request it again, [etc.]" will probably be more identical than not between the options.

Now, I grant that some of the newer history API makes some tricks a bit easier for back button changes to work. Ironically to the point, is that gmail is broken for back button usage. So... whoops.

Post reply on HN