Request For Contribution: I'd like to include some documentation on integrating datatables.js w/ htmx including: - properly initializing data tables in new content received by htmx - properly de-initializing data tables before snapshotting for history - properly initializing dynamically added content within datatable itself I think this would be a good thing to have on the docs page, to show how a big, heavy, DOM-mutation happy JS library should be integrated w/ htmx

if anyone has experience w/ datatables and htmx, please let me know if you'd be interested in this

I would like to use htmx to create a terminal GUI. This means I need a tool which can render html on the terminal and supports JS. Lynx does not support JS. There are browser which connect to a real browser which render to unicode characters (eg browsh). But that's not what I was looking for. I would like to see html rendered to text (which I can copy and paste). Background: I am too lazy to use ncurses or a modern alternative. I don't need support for CSS or pictures, since there is no need to render arbitrary html. Support for tables would be great. Goal: write a modern pager like 'less', for showing and filtering structured logs (json lines).

https://github.com/textualize/textual Not HTMX or even web related but I’ve used Textual and Rich for visual CLI needs. It has a CSS-ish model applied to terminal graphics.

Seconded for textual. They have a Discord server as well

A textual based hypermedia client + a new terminal hypermedia !

Hyperview for the terminal!

Just some loose newcomer thoughts: I am trying to wrap my head around performance if I move a lot of the usual fronted to the backend, and I found a case that occupied me a bit. A preview that converts e.g. markdown to its visual representation as the user types. This seems expensive to send back and forth and therefore JavaScript would be more ideal. And then I would already have the functionality for converting markdown to it visual representation, so it does not make sense to this on the backend in other cases. But this is not necessarily bad, just how it is…

There are cases where moving everything to the backend is a bad idea, and whatever you are building you are eventually bound to find that case where you'll need clientside code. HTMX/Unpoly and other "hypermedia-driven frameworks" just allows you to minimise writing unnecessary clientside code.

I personally go by a couple rules deciding what should be on the backend and what should be on the frontend: If it doesn't demand a network request, I (USUALLY) keep it clientside. If it does - if it's simple "filling in the template", I SSR it. If it's something more complex like drawing a graph or formatting text - I (try) keep it clientside

Thanks for commenting. Seems reasonable!

if I recall htmx had an article for that

I've found this tweet also very useful: https://twitter.com/htmx_org/status/1646542857485049859

Now I feel like writing one that supports htmx attributes

I’ll have to write that one down

It sounds like fun

why htmx? why not a server sending strings to the terminal?

uhm

hyperview for terminal.l iguess clicks better for me

so instead of clicking links I could think of you are given a set of allowed commands to allow for hateoas?

i still dont think you need the full extend of htmx or js ( i am assuming you inly want js because you wanting htmx)

what i think you need is some sort of lightweight protocol...

web server returns regular html (perhaps with some extra attributes on links)

terminal renders html (no need of js) and reads the extra attributes on links to list a series of "commands". if you send one of those commands the http call is performed

i feel like ajax doesnt make sense on terminal therefore htmx doesnt and js doesnt

a web 1.0 GET, POST redirect, full page refresh sound better

but i am not well versed on terminals as browser so maybe i am way off

I use _hyperscript for client side stuff, it plays very well with htmx (obviously :)) and keeps everything readable. Some rudimentary JS can also be integrated using hx-on.

Second this. But if you really want to do something with htmx, I would actually say going into the backend Route gives you more opportunities to use it. For example we have two kind of projects in our company: full scale, which include separate front and backend. And then we have the smaller projects which are just build by a backend dev using Django and it’s templating system. There, I currently introduce htmx to make them prettier. I guess where backend devs are not locked in the cellar, there is a higher chance to use it