Live data from Hacker News

Htmx Is the Future

quii.dev

171–180 of 875 posts

Re: Htmx Is the Future

#171

Earlier quoted context omitted.

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.

Because HTML form validation is a built-in native feature of HTML, and it's integrated in the browser: Constantly reinventing the wheel in every app is silly.

These validators are rather limited and you’ll end up needing JavaScript for any Web app with anything beyond the simplest requirements.

Re: Htmx Is the Future

#172
post #109
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 agree but one important point to consider is the dev effort of making a proper SPA which is not a very common occurrence. "The best SPA is better than the best MPA. The average SPA is worse than the average MPA." https://nolanlawson.com/2022/06/27/spas-theory-versus-practi...

The nice thing about htmx is it gives a middle ground between the two. Build with the simplicity of an MPA while getting a lot of the nice user experience of an SPA. Sure, you don't get all the power of having a full data model on the client side, but you really don't need that for most use cases.

Re: Htmx Is the Future

#173
post #11
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…

ActionScript is basically ES6 too isn't it?

Re: Htmx Is the Future

#174
post #95

Earlier quoted context omitted.

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

Username length does not "need" to be validated on the client. However, it is nice for UX to enforce it there.

I think a charitable reader could infer that this is often made a requirement out of UX concerns and therefore it “needs” to be done. Do you have a substantive objection to what I said?

Re: Htmx Is the Future

#175
post #84

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.

[deleted]

Re: Htmx Is the Future

#176
post #109
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 agree but one important point to consider is the dev effort of making a proper SPA which is not a very common occurrence. "The best SPA is better than the best MPA. The average SPA is worse than the average MPA." https://nolanlawson.com/2022/06/27/spas-theory-versus-practi...

Extend that statement with "Only True Web Gods can create the Best SPA".

Re: Htmx Is the Future

#177

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 have no love for unnecessarily bloated dependency graphs, but we can't have the cake and eat the cake too. Next.js for example, comes packed with anything and everything one might need to build an app. Sitting on the promise of hyperproductivity with "simplicity". Plus, is made of single responsability principles set of modules, kind of necessary to build a solve-all needs framework. And it does that. A bit like An…

So Next.js did everything right, but is built upon React that does too much. Okay?

Re: Htmx Is the Future

#178

Thanks for the reminder, I've been meaning to try it out. Just to get started, I asked ChatGPT to write an htmx app to show a 10-day weather forecast. It described the general steps and seemed to be able to describe how htmx works pretty well, including hx-get and hx-target, etc., but then said "As an AI language model, I am not able to write full applications with code". I replied "do the same thing in bash" (which…

HTMX is quite easy to code. Your prompt sounds rather generic, I mean, you can just serve 10 days of weather forecasts without any interaction whatsoever.

https://www.wunderground.com/forecast/us/ak/north-pole

It isn't clear what you were asking ChatGPT to provide, therefore not surprised it didn't come up with the exact answer you expected. I'd suggest learning HTMX by reading the docs, the majority is just a single page.

Re: Htmx Is the Future

#179
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 remember that all the web shops in my town that did Ruby on Rails sites efficiently felt they had to switch to Angular about the same time and they never regained their footing in the Angular age although it seems they can finally get things sorta kinda done with React.

Client-side validation is used as an excuse for React but we were doing client-side validation in 1999 with plain ordinary Javascript. If the real problem was “not write the validation code twice” surely the answer would have been some kind of DSL that code-generated or interpreted the validation rules for the back end and front end, not the fantastically complex Rube Goldberg machine of the modern Javascript wait wait wait wait and wait some more to build machine and then users wait wait wait wait wait for React and 60,000 files worth of library code to load and then wait wait wait wait even more for completely inscrutable reasons later on. (e.g. amazing how long you have to wait for Windows to delete the files in your node_modules directory)

Re: Htmx Is the Future

#180
post #109

Earlier quoted context omitted.

I agree but one important point to consider is the dev effort of making a proper SPA which is not a very common occurrence. "The best SPA is better than the best MPA. The average SPA is worse than the average MPA." https://nolanlawson.com/2022/06/27/spas-theory-versus-practi...

The nice thing about htmx is it gives a middle ground between the two. Build with the simplicity of an MPA while getting a lot of the nice user experience of an SPA. Sure, you don't get all the power of having a full data model on the client side, but you really don't need that for most use cases.

OTOH if you need to go back to the server after every interaction the UX can get pretty bad for distant users.
Post reply on HN