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

51–60 of 88 posts

Re: htmx 2.0.0-beta1

#51

Post by loneboat »

sebazzz wrote: post #39
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…

> 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 gracefully. Yes, but you are not designing your MVC controller as a REST service, and are not trying HTMX to your REST API directly. This makes sense if you think of it from this perspective, like the classic MVC view-rendering controller behind…

Can you elaborate on this? I've seen HTMX and considered trying it out in some projects, but would like insight on how to best use it in a stack.

Re: htmx 2.0.0-beta1

#52

Post by sibit »

joshlemer wrote: post #27
sibit wrote: post #9

Earlier quoted context omitted.

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"

My gut says I would use query params though I typically stick with 1 action effects 1 record. I can't recall any specific times when I built bulk item management into an app but I'd say that's a personal preference on my end.

Re: htmx 2.0.0-beta1

#53

Post by thom »

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…

It depends on your options for managing state. If you can build a largely stateless UI, that can update from the server via a form submission or query parameters, then it’s a big win, both in terms of your code complexity and the complexity of the team you need to build it. You can still have lots of widgets on your page and even fancy CSS transitions to make it feel like an SPA if you really want. But if you’re making something very highly interactive or canvas based, with complex stateful UI components and gestures, then you probably have nothing to gain.

Anywhere I could conceivably get away with HTMX over React I would (and tbh I’d launch with no JavaScript at all before that). But if you’ve got a massive React codebase then you’re already in quite deep, both codebase and team structure.

All that said, some really high level apps are moving to WASM anyway, so I don’t know that an investment in React is safe for the long term.

Re: htmx 2.0.0-beta1

#54

Post by thom »

traceroute66 wrote: post #37
thom wrote: post #32

Earlier quoted context omitted.

This is all handled in an extension: https://htmx.org/extensions/response-targets I don’t know what kludge you’re referring to, it requires you to add basically two attributes to your HTML, it’s really no hardship at all.

> This is all handled in an extension And why should I need to load an extension to handle a 400-series ? That's just nuts. The kludge is loading the following JS snippet on your page: if(evt.detail.xhr.status >= 400 && evt.detail.xhr.status

Every web framework has error handling features. These are HTMX’s. It’s two HTML attributes and you’re done, if you don’t want any of the additional functionality.

Re: htmx 2.0.0-beta1

#56

Post by lukevp »

leptons wrote: post #33
mamcx wrote: post #30

Earlier quoted context omitted.

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…

Curious what part of React you think makes it "hacker friendly". React can be done very simply, and I see no part of it that makes it any friendlier to "hackers" than HTMX. Seems that HTMX requires unsafe-eval? https://github.com/bigskysoftware/htmx/issues/2260

SPAs require implementing safety checks on both sides in 2 different languages. Many junior devs believe the client code is trustworthy and put important validation only in the client. I’ve worked with many codebases like this. If there’s only one place to specify validation, it should always be the server. So server side frameworks have this built in to their model and thus are less susceptible to this whole class of bugs.

Re: htmx 2.0.0-beta1

#58

Post by blopker »

jwells89 wrote: post #29
blopker wrote: post #26

Earlier quoted context omitted.

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?

Maybe. I think it's just a high-level library for a specialized domain. It's not like imperatively coding JavaScript, spelling out each action step-by-step. The fact that I just need a little of it to do a lot means I just don't need to use it that much, and then I forget how.

I could see a better tutorial experience with live examples for common patterns. Something like SolidJS does (https://www.solidjs.com/tutorial/introduction_basics). That would be a good reference. Alternatively, a copy/paste pattern library, like what a lot of people are doing with Tailwind (https://daisyui.com/components/).

Re: htmx 2.0.0-beta1

#59

Post by leptons »

lukevp wrote: post #56
leptons wrote: post #33

Earlier quoted context omitted.

Curious what part of React you think makes it "hacker friendly". React can be done very simply, and I see no part of it that makes it any friendlier to "hackers" than HTMX. Seems that HTMX requires unsafe-eval? https://github.com/bigskysoftware/htmx/issues/2260

SPAs require implementing safety checks on both sides in 2 different languages. Many junior devs believe the client code is trustworthy and put important validation only in the client. I’ve worked with many codebases like this. If there’s only one place to specify validation, it should always be the server. So server side frameworks have this built in to their model and thus are less susceptible to this whole class o…

>SPAs require implementing safety checks on both sides in 2 different languages.

Nodejs is quite popular. One language works on front-end and back-end. Like any language, security is up to the developers.

>Many junior devs believe the client code is trustworthy and put important validation only in the client.

Who is letting "junior devs" make these decisions? It sounds like they deserve to be hacked.

Re: htmx 2.0.0-beta1

#60

Post by mhitza »

seanwilson wrote: post #18

Does general usage of HTMX require `unsafe-eval` in your Content Security Policy (CSP) to allow JavaScript eval? Or there's workarounds that still keep things simple?

Probably yes if you use the inline event handler feature it has.

https://htmx.org/essays/web-security-basics-with-htmx/#bonus...

Post reply on HN