Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving from React to htmx

htmx.org

Post reply on HN
Print view View original

311–320 of 326 posts

Re: Moving from React to htmx

#311

Post by miiiiiike »

recursivedoubts wrote: post #310
miiiiiike wrote: post #307

Earlier quoted context omitted.

JSON APIs are usable beyond the browser and using htmx feels like using Django+jQuery 14 years ago. I'd rather not go back to that.

cool cool https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/hypermedia-apis-vs-data-apis/

Passive aggressively posting links to overlong tracts won't change my mind. I've read all of it and I fundamentally disagree with it. I'm happy to be done with this.. Unless, of course, you feel that you need the last word? Or, can we let this go and move on? Yeah?

Re: Moving from React to htmx

#312

Post by recursivedoubts »

miiiiiike wrote: post #311
recursivedoubts wrote: post #310

Earlier quoted context omitted.

cool cool https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/hypermedia-apis-vs-data-apis/

Passive aggressively posting links to overlong tracts won't change my mind. I've read all of it and I fundamentally disagree with it. I'm happy to be done with this.. Unless, of course, you feel that you need the last word? Or, can we let this go and move on? Yeah?

All of it? ;)

Re: Moving from React to htmx

#313

Post by miiiiiike »

recursivedoubts wrote: post #312
miiiiiike wrote: post #311

Earlier quoted context omitted.

Passive aggressively posting links to overlong tracts won't change my mind. I've read all of it and I fundamentally disagree with it. I'm happy to be done with this.. Unless, of course, you feel that you need the last word? Or, can we let this go and move on? Yeah?

All of it? ;)

Have I read what you’ve posted in this thread? Yes. And more when I was learning to use htmx. I gave it a good-faith effort and I’m completely unconvinced. If we were having this conversation ten years ago, I might be excited. Today, not so much.

Re: Moving from React to htmx

#314

Post by miiiiiike »

bsder wrote: post #89
miiiiiike wrote: post #48

The hoops people will jump through to avoid learning HTML/CSS/JS. I say this as a Python/Django dev who resisted learning web tech for 20 years: It's time to just learn this stuff. You can slap on a mound of band-aids and watch the wound bleed forever. Or, you can go in, get three stitches, suffer a little pain, and let the healing process begin.

The problem is that you don't "learn Javascript". The problem is that you need a whole ecosystem to do anything useful and that ecosystem is highly fractured and never seems to converge. One of the bullet points was "They reduced their total JS dependencies by 96% (255 to 9)". That's an enormous support burden that simply vaporized.

'The problem is that you don't "learn (Python|Rust|Ruby|C++|Go)". The problem is that you need a whole ecosystem to do anything useful and that ecosystem is highly fractured and never seems to converge.'

My virtualenv has close to a hundred deps. Tried packaging anything in Python lately? How about type checking? It's the same everywhere, the grass just looks patchier when it's not a park you're used to going to.

There are over seven billion people on this planet, convergence of opinion is the exception.

Re: Moving from React to htmx

#315

Post by bsder »

miiiiiike wrote: post #314
bsder wrote: post #89

Earlier quoted context omitted.

The problem is that you don't "learn Javascript". The problem is that you need a whole ecosystem to do anything useful and that ecosystem is highly fractured and never seems to converge. One of the bullet points was "They reduced their total JS dependencies by 96% (255 to 9)". That's an enormous support burden that simply vaporized.

'The problem is that you don't "learn (Python|Rust|Ruby|C++|Go)". The problem is that you need a whole ecosystem to do anything useful and that ecosystem is highly fractured and never seems to converge.' My virtualenv has close to a hundred deps. Tried packaging anything in Python lately? How about type checking? It's the same everywhere, the grass just looks patchier when it's not a park you're used to going to. The…

If you are deploying to Django, you've likely converged to a specific set of Python dependencies that have been pretty static for close to a decade.

I'd be surprised if my Django virtualenv has ever had more than 20 dependencies.

Re: Moving from React to htmx

#316

Post by miiiiiike »

bsder wrote: post #315
miiiiiike wrote: post #314

Earlier quoted context omitted.

'The problem is that you don't "learn (Python|Rust|Ruby|C++|Go)". The problem is that you need a whole ecosystem to do anything useful and that ecosystem is highly fractured and never seems to converge.' My virtualenv has close to a hundred deps. Tried packaging anything in Python lately? How about type checking? It's the same everywhere, the grass just looks patchier when it's not a park you're used to going to. The…

If you are deploying to Django, you've likely converged to a specific set of Python dependencies that have been pretty static for close to a decade. I'd be surprised if my Django virtualenv has ever had more than 20 dependencies.

The whole of the Django community has not converged on the same deps. Same with JavaScript. With Python/Django there's uWSGI vs. Gunicorn vs. etc, etc, etc. Then there's ASGI with Uvicorn vs. Daphne vs. Hypercorn. That's just running your code. Nothing is one-size fits all.

Re: Moving from React to htmx

#317

Post by David-Guillot »

Glyptodon wrote: post #120

Expected this to be more interesting than a maybe fancier version of turbolinks. Am I missing something?

Hi there ; I'm the author of the talk linked in the article.

Technically you're not missing anything: htmx is nothing more than another turbolinks, maybe more flexible and easier to learn.

What you might be missing is the non-technical implications of these new tools. The idea behind the talk (and behind htmx, and behind turbolinks, or unpoly) is to prove that the usual arguments for Javascript application frameworks are just not valid for 90% of use cases. And *that's* a complete game-changer, even an industry-changer.

Because since 2016, every small-and-not-super-rich company that wants to create a rich UX on the web is told to hire at least 2 developers: one "front-end" (i.e. "JS"), and one "backend-end" (i.e. everything else, from API to hosting through domain stuff and user data). Or one superman with both back-end and React skills, which is, IMO, almost impossible.

From what I've seen, what businesses need is, indeed, 2 devs: one "back-end" (i.e. workers, databases, user data, domain stuff, and even hosting), and one "front-end" (i.e. "the website", from DB queries to CSS). One person should be enough to address this second scope, even with complex UIs and rich UX. And as this is almost impossible with Javascript application frameworks (because they require a lot of work), it becomes possible again, like in 2008, with htmx/hotwired/unpoly (and without the spaghetti code we had in 2008).

One more thing: of course the idea was *never* to do JS-bashing, only people who are too tied to Javascript and not caring about tech cost-effectiveness would see htmx as a thing for JS-haters. In my talk I actually show some Javascript code, because it's useful for handling client-side-only stuff like a custom dropdown, a modal, etc. The whole idea is to put Javascript back at its place: pure client-side advanced interactions.

Re: Moving from React to htmx

#318

Post by David-Guillot »

spion wrote: post #294
pwdisswordfish0 wrote: post #288

Earlier quoted context omitted.

Well, sure, the value of an input is in its value property, but you build your stuff in such a way that you don’t access it unless you absolutely have to.

Did you actually watch the video? The things are built in such a way that there is global state shared among components.

I'm the one who gave this talk, and I can assure you there is no such thing in our code. htmx just enables us to fire some JS events and react to them by triggering AJAX calls then replacing some with some HTML fragment. No state management, just a hook system.

Re: Moving from React to htmx

#319

Post by 0xblinq »

panoply wrote: post #269
nickjj wrote: post #265

Earlier quoted context omitted.

Sounds really good, do you have that code published somewhere? Any plans to get it merged into the official libs?

I do indeed. The project is called SPX (Single Page XHR) which is a play on the SPA (Single Page Application) naming convention. The latest build is available on the feature branch: https://github.com/panoply/spx/tree/feature - You can also consume it via NPM: pnpm add spx (or whichever package manager you choose) - If you are working with Stimulus, then SPX can be used instead of Turbo and is actually where you'd ge…

This looks extremely similar to Unpoly to me.

Re: Moving from React to htmx

#320

Post by spion »

David-Guillot wrote: post #318
spion wrote: post #294

Earlier quoted context omitted.

Did you actually watch the video? The things are built in such a way that there is global state shared among components.

I'm the one who gave this talk, and I can assure you there is no such thing in our code. htmx just enables us to fire some JS events and react to them by triggering AJAX calls then replacing some with some HTML fragment. No state management, just a hook system.

Ok, then I've explained myself poorly. I see that there are both facet filters and favorites on the page, both of which affect what the rest of the page shows. In my mind, that's client-side state. It doesn't have to mean that its managed with JavaScript, but the state does exist; its changed any time the user makes changes into any inputs in the browser. Furthermore, those changes together seem to affect the rest of the page, if I'm not mistaken?

My question was where is the favorites (and facet) state stored. Is it in "html inputs", in which case, I suppose they are included in the requests somehow later? (perhaps via `hx-include`). The answer could also be that e.g. favorites are permanently stored on the backend...

Additionally I was also wondering what htmx can do in more complex cases, like e.g. a "sort direction" button, where you need to set the sort column(s) and direction(s) of columns. It feels like its really easy to exit the htmx comfort zone, after which you have to resort to things like jquery (which is a nightmare). Or perhaps web-components, which would actually be a nice combination...

Post reply on HN