I use Postgres with a library called postgres-simple to execute raw sql against the db. For simple queries I use a query builder called selda (https://selda.link/). Did this answer the question?

> As Selda uses a lot of fancy type magic to achieve a safe yet flexible programming model, figuring out how to use it from type signatures alone can be hard. While the types keep queries nice and safe, Haskell's type errors can be a bit daunting even under the best circumstances.

😑

@User @User Yes, this is true. That's why I recommend only using thin abstractions over SQL such as

postgresql-simple

or

hasql (my fav)

. I was never a fan of query builders or ORMs. SQL is good at what it does and it's the right tool for querying relational databases in my opinion. I'll be linking to an example of how I use htmx in Haskell very soon.

I'm making solid progress on moving

hx-sse

into an extension. It looks like it will require a lot of subtle changes to the way that htmx currently handles extensions. I have posted some questions on GitHub for @User , @User , and everyone else who's interested -- I'd love to get your input on how to move forward (https://github.com/bigskysoftware/htmx/issues/618#issuecomment-950355002)

will reply this afternoon, thank you ben!

the "types save time" meme runs deep.

Promising but initial progress on SSE

I hope you don't mind if I write on the Week that you'll write about it

Sure thing!

this week 2 is out https://thisweek.htmx.org/issue/2/

anyone watched react's Server component and thought it's quite similar to how Htmx do with html chunks from endpoints? 🤔

to an extent, but seems pretty darned complicated

yep, they seems to be obsessed with their "component" concepts and bring it everywhere, so much crazy stuffs just to be able to write a React component for the server

having components span the client and the server and syncing state seems too complicated to me, and antithetical to the web architecture i don't like dogging other peoples work, but I do prefer the htmx/REST-ful style for most use cases

yea it feels more natural with tradditional rest-json/html approach, at least learned that simple concept helped me in my entire career. seeing web concepts has been pushed too far from simple like that makes me worry about the next generation..

also server component implies both ends (client/server) has to run React, then React has turned in to an engine/framework rather than "just a library" from the beginning

that's a good point not exactly back end agnostic, is it?

yea its not, React runtime will serialize a server's component jsx response into an alienated json, at least from their demo vid it looks impossible to read

and I assume that means you have to have a javascript backend

yes correct

and I think some webpack magic as well

because they demoed it like "name a component *.server.jsx and React will run it only on the server"

Here's how I'm doing bootstrap5 modals with htmx (and Django) https://www.andytwoods.com/django-htmx-modal-popup-loveliness/

New to HTMX. I'd like to use the ActiveSearch example with hx-get and append parameters to the request URL. Would this code trigger /search?search=param_value <input type="text" name="search" hx-get="/search" hx-target="#search-results" >

if you want the URL included, but yes, a GET will parameter-encode value to trigger

/search?search=<whatever>

Thanks! Trying it now.

Hi all! 👋 I just watched Carson's talk () from DjangoCon and liked it a lot. I've got a few conceptual questions: 1. I like the idea of enabling standard HTML elements to trigger requests etc. That said, that seems to be a slippery slope of building a website that cannot fall back to default behavior when it's used without JavaScript enabled. This can be seen in the Active Search example: https://htmx.org/examples/active-search/, which doesn't work at all with JS disabled. Does anyone of you have any experience in trying to strictly use HTMX for progressive enhancement? Should I be able to simply wrap the

<input />

element into

<form />

elements properly and can expect the browser to just work fine with that if JavaScript is disabled? 2. Hotwire's (https://hotwired.dev/) default behavior in response processing seems to be to extract the content of the turbo frame the interaction originates from, from the response. That enables me to keep the rendering code untouched, still render the full page and Hotwire still optimizing the default replacement. HTMX has

hx-select

to achieve something similar. I.e. if I decorated an HTML element with the id

foo

to

hx-select="#foo"

that would result in pretty much the same behavior. Is that understanding correct? 3. Hotwire's concept of Turbo Streams (https://turbo.hotwired.dev/handbook/streams) seems to find a similar idea in

hx-swap-oob

(https://htmx.org/docs/#oob_swaps). A fundamental difference though seems to be that with Hotwire, the response defines the type of swapping (e.g. replace VS. append). With HTMX, I don't seem to be able to define the swap mode for OOB swaps in the response? Did I miss something here?