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

21–30 of 875 posts

Re: Htmx Is the Future

#21

Post by obpe »

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 have never heard this before. Can you elaborate on the differences? What do you validate on the client side that you don't on the server and vice versa?

Re: Htmx Is the Future

#22

Post by EGreg »

We spent 12 years on https://qbix.com/platform and along the way saw a lot of fads come and go.

At one point we experimented with the server returning the stuff to replace the HTML with. We support that in our framework natively (through a mechanism called “slots”).

That said, I have come to believe that people this decade will (and should) invert the idea of progressive enhancement to be client-first.

Imagine your site being composed of static files (eg served on Hypercore or IPFS via beaker browser). As more people use it, the swarm grows. No worries about being DDOSed. No having to trust a server to not send you the wrong interface one day. The software is yours. It just got delivered via a hypercore swarm or whatever, and your client checked the Merkle trees to prove it hasn’t been tampered with.

The you just interact eith a lot of headless web services. Rather than bearer tokens and cookies, you can use webauthn and web crypto to sign requests with private keys. You can do a lot more. And you store your data WHERE YOU WANT.

Sure, htmx can be used there. But there, too, it’s better to fetch JSON and interpret it on the client.

Returning markup language like HTML actually mixes data with presentation. Consider what happens when you want to return a lot of rows. With JSON, you return just the structured content. With HTML, there is a lot of boilerplate mixed in there which is a lot of extra weight on the wire.

If you are interested in learning more, I gave a whole talk about it:

https://qbix.com/blog/2020/01/02/the-case-for-building-clien...

Re: Htmx Is the Future

#23

Post by ladberg »

zelphirkalt wrote: post #8
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. It's a pretty shitty client experience if you have to do a network request for each and every validation of user input. Node does not absolve from this. Any important verification still needs to be done on the server side, since any JS on the client side cannot be trusted to not be manipulated. J…

I feel like you misunderstood the OP, they are claiming that Node allows you to reuse the same code to do validation on both the client and the server. By definition that means they are also doing server-side validation, and they are not relying on it being checked on the frontend.

Re: Htmx Is the Future

#24

Post by pictur »

If your project consists of a todo list, these tools will do the trick. but they are useless for projects with larger and more complex needs. and yes, there may be cases where it doesn't work in frameworks like nextjs and you need to apply hacky solutions. but I don't see even libraries like nextjs being so self-praising. Come on, folks, there's no point in praising a small package that can do some operations through the attribute. It is inevitable that the projects developed with this package will become garbage when the codebase grows. because that doesn't exist in the development logic. It's nothing more than a smug one-man's entertainment project. sorry but this is the truth.

Re: Htmx Is the Future

#25

Post by sublinear »

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

Re: Htmx Is the Future

#26

Post by rektide »

haolez wrote: post #6
rektide wrote: post #2

Personally I believe strongly in thick clients but this is a pretty neat demo anyways. I see a lot of resemblance to http://catalyst.rocks with WebComponents that target other components. I think there's something unspoken here that's really powerful & interesting, which is the declarativization of the UI. We have stuff on the page, but making the actions & linkages of what does what to what has so far been trapped i…

Catalyst looks nice! What's the downside? Is it dead?

Catalyst is great. Definitely active, actively used, last updates in main were late February.

They have a big 2.0 branch that has a ton of internal changes. TypeScript 5.0 finally updated to support modern @decorator syntax & they're rewriting a bunch to support that, which is excellent.

Re: Htmx Is the Future

#27

Post by ademup »

brushfoot wrote: post #10

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…

Your story sounds similar to mine, and your choice to use HTMX has me motivated to check it out. The sum total of my software supports 5 families' lifestyles entirely on LAMP MPAs with no frameworks at all. Thanks for posting.

Re: Htmx Is the Future

#29

Post by recursivedoubts »

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/

Re: Htmx Is the Future

#30

Post by chasd00 »

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 remember the hype about javascript on the server (node) being front-end devs didn't have to know/learn a different language to write backend code. Not so much writing code once but not having to write Javascript for client-side and then switch to something else to write the server-side.
Post reply on HN