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

201–210 of 875 posts

Re: Htmx Is the Future

#201

Post by pengaru »

duxup wrote: post #11
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…

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…

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

How much of that is just a garden variety "grass is always greener on the other side" effect?

> the important thing is to do the thing thoughtfully.

And finish! Total losses are still total losses no matter how thoughtfully done.

Re: Htmx Is the Future

#202

Post by Joker_vD »

afavour wrote: post #181
robertoandred wrote: post #165

Earlier quoted context omitted.

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.

Or simply unaware about the whole "back button" debacle. Which is yet another stone to throw at the SPA camp: if using technology A requires a programmer to learn about more stuff (and do more work) than technology B for achieving pretty much the same end results, then technology A is inferior to B (for achieving those particular end results, of course).

Re: Htmx Is the Future

#203

Post by mal-2 »

I like some concepts from HTMX but I don't understand how it tracks the relationship between these addresses and the identifiers in the markup. It seems to be just that the identifier strings match - the markup identifies the targets/swaps and it just refers to itself.

When I compare this to Phoenix LiveView I much prefer LiveView, because it both provides the markup templating engine and tracks the meaning of the relationship, with server-side tokens and methods.

Re: Htmx Is the Future

#204

Post by infamia »

pictur wrote: post #64
infamia wrote: post #50

Earlier quoted context omitted.

You can always incrementally add dynamic features using web components when HTMX and similar things aren't a good fit. It doesn't have to be either HTMX or JS-first frameworks. Our industry's fixed mindset of JS/React vs. Hypermedia (e.g., HTMX/Hotwire/Unpoly) needs to change.

I am not for or against anything. I don't live in a fantasy world like in the article. I want to talk about real world problems, not dreams.

A Real World React -> htmx Port

https://htmx.org/essays/a-real-world-react-to-htmx-port/

Re: Htmx Is the Future

#205

Post by qgin »

As long as native apps live alongside web, then the architecture of web is going to trend towards that of native apps, managing display state on the client while managing business state on server.

Re: Htmx Is the Future

#206

Post by ZephyrBlu »

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

You shouldn't have to wait until you submit something to get feedback on it. It's poor UX.

Frontend and backend validations are also different. Frontend is more about shape and type. Backend is content and constraints.

Re: Htmx Is the Future

#207

Post by dalmo3 »

recursivedoubts wrote: post #29
sublinear wrote: post #25

> SPAs have allowed engineers to create some great web applications, but they come with a cost: ... Managing state on both the client and server Having a separation of concerns between server and client is the whole point, and replacing JSON APIs with data trapped in HTML fragments is a massive step backwards.

https://htmx.org/essays/splitting-your-apis/

So, by your own words, in htmx:

> the new API is simply reflected in the new HTML returned by the server

Whereas with SPAs (my words)

> the new API is simply reflected in the new json returned by the server

I think I prefer the mental model of the api serving data and client rendering it.

Re: Htmx Is the Future

#208

Post by gpapilion »

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 actually tend to think of it to add feature degradation and handle micro service issues. It always seemed better to have the client manage that, and more graceful.

Re: Htmx Is the Future

#209

Post by lucasyvas »

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…

You're on the money with this assessment. It's all bandwagon hopping without any consideration for reality.

Also, all these things the author complains about are realities of native apps, which still exist in massive numbers especially on mobile! I appreciate that some folks only need to care about the web, but declaring an architectural pattern as superior - in what appears to be a total vacuum - is how we all collectively arrive at shitty architecture choices time and time again.

Unfortunately, you have to understand all the patterns and choose when each one is optimal. It's all trade-offs - HTMX is compelling, but basing your entire architectural mindset around a library/pattern tailored to one very specific type of client is frankly stupid.

Re: Htmx Is the Future

#210

Post by kokanee »

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

There are two things that engineers tend to neglect about validation experiences:

1) When you run the validation has a huge impact on UX. A field should not be marked as invalid until a blur event, and after that it should be revalidated on every keystroke. It drives people crazy when we show them a red input with an error message simply because they haven't finished typing their email address yet, or when we continue to show the error after the problem has been fixed because they haven't resubmitted the form yet.

2) Client side validation rules do occasionally diverge from server side validation rules. Requiring a phone number can be A/B tested, for example.

Post reply on HN