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

htmx 2.0.0-beta1

v2-0v2-0.htmx.org

Post reply on HN
Print view View original

21–30 of 88 posts

Re: htmx 2.0.0-beta1

#21

Post by andrewstuart2 »

danielvaughn wrote: post #17
traceroute66 wrote: post #15

There's a lot to like about htmx, but one thing that does not sit well with me is its opinionated design decision that it will only render content if its sent with a 200 OK (tech TL;DR: shouldSwap defaults to false for non-200 response codes). Most sane services will only return a 200 OK if, well, things went OK. Most sensibly designed services will return 400 range if an error has occurred that has been handled grac…

I didn’t know that, that’s interesting. I’d expect 100-199 responses to be able to render a result as well, at the very least.

All response codes should really be able to contain content that doesn't look terrible. A 404 can be a nicely formatted "not found" page that's consistently styled and looks like the rest of the app, for example.

Re: htmx 2.0.0-beta1

#22

Post by ledgerdev »

wqtz wrote: post #4

I am interested in learning about how something is being used and in what context, instead of what it has to offer. Can anyone tell me if they are using HTMX in a proven environment, like a user-facing environment? I think adopting HTMX as a framework would be difficult to switch from a React, Vue, etc. environment. I think using it inside internal tooling or a hobby project will not be able to justify its merit. I u…

I used htmx to build a now in production multi-step payment form that's currently in use by several hundred thousand people per month. It's been great, but not perfect and I would say a less well trodden path to get the edge cases right. I would absolutely say it's been a simpler overall solution for us as a small team than a full js client side framework would have been. Things that were hard to get right were setting up loading indicators, error display, keeping step/form state on browser history back/forward, tab sleep restoration after htmx navigation(especially tricky), and injection of third party form elements that had to be injected/remove and re-injected on back/forward between steps. I would be surprised if these sorts of edge cases weren't already handled by a popular js-frameworks but can't say for sure. The site load is very fast and we haven't even rolled out client side js validation on forms the server validation responds so fast. We are planning to use more htmx across other apps at present, so overall positive hypermedia for the win.

Re: htmx 2.0.0-beta1

#23

Post by mr90210 »

jonathanberger wrote: post #13
mr90210 wrote: post #10

Earlier quoted context omitted.

For now I’ve decided to sit on React/Nextjs and actually focus on solving problems rather than playing the framework/UI library game that leads me nowhere. I totally get your sentiment.

By “sit on” do you mean “keep using” or “avoid”?

Keep using… Apologies for the lack of accuracy.

Re: htmx 2.0.0-beta1

#24

Post by dpkirchner »

sibit wrote: post #9
lentil wrote: post #8

Earlier quoted context omitted.

The resource to be deleted should be identified in the URL, so there is no need to pass a body. This is the same for `GET`.

This is how I've used DELETE. Something like DELETE /users/{uniqueUserId}. In ~10 years of building CRUD apps I don't think I've ever sent a body or query params with a request.

Some tools let you pass a parameter to indicate that you only want the request to take effect if the requested resource is in some specific state. For example, Google Cloud Storage uses headers to allow you to set preconditions that must be met before the action takes place. For DELETEs you can use this to say "delete this resource but only if its generation (sort of a timestamp) is exactly $foo", where $foo is the generation last known to the client.

https://cloud.google.com/storage/docs/request-preconditions

Re: htmx 2.0.0-beta1

#25

Post by j3s »

sick! i’ve been using htmx for a few personal projects & i have to say, it feels like exactly what i was looking for.

light, well documented, snappy, easy to work with - i love the idea of endpoints returning pure html instead of json - it feels obvious.

Re: htmx 2.0.0-beta1

#26

Post by blopker »

wqtz wrote: post #4

I am interested in learning about how something is being used and in what context, instead of what it has to offer. Can anyone tell me if they are using HTMX in a proven environment, like a user-facing environment? I think adopting HTMX as a framework would be difficult to switch from a React, Vue, etc. environment. I think using it inside internal tooling or a hobby project will not be able to justify its merit. I u…

I'm using HTMX with Django for totem.org[0]. My over all experience is good.

I'd say the main thing I like is testing. With a JS framework I have to have tests spread over both JS and Python, with HTMX I can mostly just focus on Python tests and assume the HTMX is going to work correctly. There's a good, stable testing story for Django, so I know the tests I write won't have to be rewritten all the time when dependencies change. I just don't write many JS tests because stuff changes so fast.

The main downside I have with it though, is I just can't seem to remember how to use it. Every time I need HTMX I have to look at code I've written or go to the docs. There's just too many options with names that are confusing (hx-select, hx-swap, hx-swap-oob, hx-target?).

Aside from that, it's also a pretty large dependency. I'm also using Solidjs to mount web components (which is a pattern I love) and HTMX is a majority of the JS bundle. That was surprising to me. Maybe version 2 will be smaller?

[0]: https://github.com/totem-technologies/totem-server

Re: htmx 2.0.0-beta1

#27

Post by joshlemer »

sibit wrote: post #9
lentil wrote: post #8

Earlier quoted context omitted.

The resource to be deleted should be identified in the URL, so there is no need to pass a body. This is the same for `GET`.

This is how I've used DELETE. Something like DELETE /users/{uniqueUserId}. In ~10 years of building CRUD apps I don't think I've ever sent a body or query params with a request.

What about where you're not just deleting a single entity by id? Like, for instance where a user can bulk select multiple items and then choose to delete them all (like email for instance), or maybe deleting by criteria, like "delete all Entities created before time X"

Re: htmx 2.0.0-beta1

#28

Post by andybak »

wqtz wrote: post #4

I am interested in learning about how something is being used and in what context, instead of what it has to offer. Can anyone tell me if they are using HTMX in a proven environment, like a user-facing environment? I think adopting HTMX as a framework would be difficult to switch from a React, Vue, etc. environment. I think using it inside internal tooling or a hobby project will not be able to justify its merit. I u…

This feels like the wrong way to look at things. It's not that it's "difficult" to switch from React/Vue to htmx - it's that it's easier to build with htmx in the first place. I wouldn't throw out completed code, but I'd seriously consider using it next time you start something new.

The general philosophy is that "React etc are great for some things, but they are being used way outside of their sweet spots". There will always be a gray area - and your existing habits and skills are also a factor but for some of us - the "SPA framework" approach always smelt fishy for typical web builds.

Re: htmx 2.0.0-beta1

#29

Post by jwells89 »

blopker wrote: post #26
wqtz wrote: post #4

I am interested in learning about how something is being used and in what context, instead of what it has to offer. Can anyone tell me if they are using HTMX in a proven environment, like a user-facing environment? I think adopting HTMX as a framework would be difficult to switch from a React, Vue, etc. environment. I think using it inside internal tooling or a hobby project will not be able to justify its merit. I u…

I'm using HTMX with Django for totem.org[0]. My over all experience is good. I'd say the main thing I like is testing. With a JS framework I have to have tests spread over both JS and Python, with HTMX I can mostly just focus on Python tests and assume the HTMX is going to work correctly. There's a good, stable testing story for Django, so I know the tests I write won't have to be rewritten all the time when dependen…

> The main downside I have with it though, is I just can't seem to remember how to use it. Every time I need HTMX I have to look at code I've written or go to the docs. There's just too many options with names that are confusing (hx-swap, hx-swap-oob, hx-target?).

Perhaps this could be smoothed over with snippets or an autocomplete extension for whichever text editor is being used?

Re: htmx 2.0.0-beta1

#30

Post by mamcx »

wqtz wrote: post #4

I am interested in learning about how something is being used and in what context, instead of what it has to offer. Can anyone tell me if they are using HTMX in a proven environment, like a user-facing environment? I think adopting HTMX as a framework would be difficult to switch from a React, Vue, etc. environment. I think using it inside internal tooling or a hobby project will not be able to justify its merit. I u…

Htmx is what you want for making websites.

This means, that almost all uses of react and friends are wrong, a waste, or an unnecessary complication.

So, if you are serving HTML, then htmx.

When you reach for react? If you are making an app of the kind that you should have use a non-web thing (because is now necessary to bend with major complicated hacks HTML to make a clone of Photoshop).

(and in short amounts like creating complex widgets like maps, selects, etc).

---

I work for eCommerce, and there is terrible to use React: It is too easy to make "hacker-friendly" websites when using it: INSTEAD, you MUST validate, format, process, render, and display all on the server side.

For me, I retain all the logic on Rust, display HTML, and just put some extra interactivity with htmx, that because at the server-side is the same as without, means I CAN'T INTRODUCE A SECUIRITY BUG.

Post reply on HN