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

41–50 of 88 posts

Re: htmx 2.0.0-beta1

#41

Post by mejutoco »

merpnderp wrote: post #19
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…

Isn’t this really just going back to the server side templating days and using jquery to load html snippets?

But without jquery, everything defined in html attributes, and hence the server responses can further define behaviour in their html attributes. Declarative, not procedural, if you want.

Re: htmx 2.0.0-beta1

#42

Post by lebean »

merpnderp wrote: post #19
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…

Isn’t this really just going back to the server side templating days and using jquery to load html snippets?

Yes it's that, but more. I enjoy the out-of-bound swaps and triggering hx events or specific targets of render via response headers.

Re: htmx 2.0.0-beta1

#43

Post by andybak »

merpnderp wrote: post #19
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…

Isn’t this really just going back to the server side templating days and using jquery to load html snippets?

The problem was that on the whole people didn't use jQuery to "load html snippets" and the architecture of jQuery tended to push people towards client-side spaghetti.

htmx encourages you to put most of the logic on the server and to keep the client lean and clean.

Re: htmx 2.0.0-beta1

#44

Post by p_l »

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?

Not unless you plan on explicitly executing sent snippets of JS, iirc

Re: htmx 2.0.0-beta1

#45

Post by chuckadams »

paulddraper wrote: post #5
hu3 wrote: post #3

> DELETE requests now use parameters, rather than form encoded bodies, for their payload (This is in accordance w/ the spec.) As someone who rarely use DELETE requests, what's the best practice for passing parameters and why?

Query params. DELETE cannot have request body, just like GET cannot have a request body. (Well, it's a syntactically valid HTTP message, but there's no semantic meaning to the body.)

DELETE and GET can have bodies, the spec is just vague about it. Elasticsearch commonly uses request bodies for GET, treating it identically to POST. It's not always regarded as a good idea, but it does work.

Re: htmx 2.0.0-beta1

#46

Post by djbusby »

mlhpdx wrote: post #7
hu3 wrote: post #3

> DELETE requests now use parameters, rather than form encoded bodies, for their payload (This is in accordance w/ the spec.) As someone who rarely use DELETE requests, what's the best practice for passing parameters and why?

I tend to make DELETE work without parameters, but allow them in the body (JSON) for non-essential but helpful options. And example is allowing a flag to override delete protections. I doubt this is a “best” practice but I’ve never had a problem with it, or been asked to change it for compatibility.

I do this too. And some resources require two DELETE requests - the first with parameters and the second one (after a minimum time) doesn't.

Re: htmx 2.0.0-beta1

#48

Post by camdenreslink »

Terretta wrote: post #40
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

Actual hackers, the ones who try to hack your e-commerce site. For such things, if you're not doing everything Server Side to Render fully validated and sanitized data safely, you should be.

If you do server-side rendering of your React application, then it would be very similar to htmx from that perspective.

If it’s is purely a SPA, then all business logic would be behind secure APIs, so I don’t really understand your point.

Re: htmx 2.0.0-beta1

#49

Post by hendi_ »

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…

We use htmx (mostly via our django-livecomponents) on our production website, for several public facing features. We've initially replaced numerous small things that were built with Alpine before, and once we've gained confidence we rewrote our whole messaging app from reason/react app.

Fun thing, customers find the new version (htmx/django-livecomponents) to be more responsive than the old version (react+REST). New version is less lines of code and easier to hack on die to fewer context switching.

Give htmx a try, it's worth a shot!

Re: htmx 2.0.0-beta1

#50

Post by leptons »

Terretta wrote: post #40
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

Actual hackers, the ones who try to hack your e-commerce site. For such things, if you're not doing everything Server Side to Render fully validated and sanitized data safely, you should be.

That sounds like an irrational fear of front-end.
Post reply on HN