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

151–160 of 875 posts

Re: Htmx Is the Future

#151

Post by Spivak »

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…

> prevent your servers from ruining the experience for everyone.

This never panned out because people are too afraid to store meaningful state on the client. And you really can't because (reasonable) user expectations. Unlike a Word document people expect to be able to open word.com and have all their stuff and have n simultaneous clients open that don't step on one another.

So to actually do anything you need a network request but now it's disposable-stateful where the client kinda holds state but you can't really trust it and have to constantly refresh.

Re: Htmx Is the Future

#153

Post by yawaramin »

dfabulich wrote: post #56

People were making this prediction ten years ago. It was wrong then, and it's wrong now. This article makes its case about Htmx, but points out that its argument applies equally to Hotwired (formerly Turbolinks). Both Htmx and Hotwired/Turbolinks use custom HTML attributes with just a little bit of client-side JS to allow client-side requests to replace fragments of a page with HTML generated on the server side. But…

> there's no good story for what happens when one component in a tree needs to update another component in the tree.

Huh, no one told me this before, so I've been very easily doing it with htmx's 'out of band swap' feature. If only I'd known before that it was impossible! ;-)

Re: Htmx Is the Future

#154

Post by mtlynch »

summarity wrote: post #142
mtlynch wrote: post #119

Earlier quoted context omitted.

I'm not sure what you mean. htmx and alpine.js are both client-side frameworks. To me, they seem to have similar goals and similar functionality. What do you see as the difference?

They're neither different nor similar. In fact they work together, with Alpine managing client side reactive state (NOT app state, just interaction) and htmx managing the actual request model. That's why the htmx docs often refer to Alpine. They should be used in combination, not to displace each other.

Ah, gotcha. Thanks!

Re: Htmx Is the Future

#156

Post by lolinder »

jksmith wrote: post #132

You know, nobody likes this argument, but desktop is still just better. Yeah, yeah, the updates, security issues, I get it, but the tools are simple better, render faster, better functionality/complexity ratio, less gnashing of teeth.

Desktop on which OS? Using what GUI framework? The web is a single platform, but the desktop developer experience seems to vary wildly depending on the OS.

I'm genuinely curious what OS and tooling you use that you find so much better, because every time I've tried desktop development I eventually give up and go back to the web. It might be because Linux support is always a requirement for me.

Re: Htmx Is the Future

#157

Post by com2kid »

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, instead of writing HTML on the client and debugging it, you get to write code that writes code that you then get to debug. Lovely!

Even more complex frameworks, like React, you have tools like JSX that map pretty directly to HTML, and in my experience a lot of the hard to debug problems come up with the framework tries to get smart and doesn't just stupidly pop out HTML.

Re: Htmx Is the Future

#158

Post by mtlynch »

jeremyjh wrote: post #126
mtlynch wrote: post #119

Earlier quoted context omitted.

I'm not sure what you mean. htmx and alpine.js are both client-side frameworks. To me, they seem to have similar goals and similar functionality. What do you see as the difference?

The purpose of htmx is to enable the server to send fragments of markup to update the dom in response to UI events. Alpine.is is purely client side, you may not even have an application server.

Oh, I didn't realize that. Thanks!

Re: Htmx Is the Future

#159

Post by account-5 »

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…

Complete novice here; what are the advantages of hyperview over something like flutter?

I looked at a bunch of frameworks before settling on dart/flutter for my own cross platform projects. I did look at htmx but since I wasn't really wanted to create a web app I moved on. But I like the idea of a true rest style of app.

Re: Htmx Is the Future

#160

Post by robertoandred »

RHSeeger wrote: post #61
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…

> We moved away for MPAs because they were bloated, slow and difficult to work with. SPAs have definitely become what they sought to replace. Plus we now get the benefit of people trying to "replace" built in browser functionality with custom code, either The SPA broke it... Back button broken and a buggy custom implementation is there instead? Check. or They're changing things because they're already so far from def…

Neither broken back buttons nor messy scrolling are unique to SPAs. You're just talking about bad websites.
Post reply on HN