@User seems like you might be in an inbetweener project, with a lot of interactivity in some spots. For those spots, using vue might be the right thing. But maybe htmx is useful in, for example, the settings area, where you don't want all that complexity.

It's actually the opposite. I've got a very sophisticated server-side object, I could serialize it, and then write custom UI to deal with that JS version of the model. Alternatively, I could implement more nuanced rendering server side, that could take advantage of state the client simply doesn't have. The question is how do I easily signal those events to the server, so it knows what to change. When you mouse, I'll need to update things. Hence, sockets and pre-rendering seem like an important approach. Most of this is simply a "view", so luckly, I'm not sending data back so much as I'm sending information about where I am in the information structure. I have a discovery process to happen.

what sort of user events would trigger a re-render?

So, I've got a multi-dimensional grid, you can only see some parts of it at a time, since it has to be flattened on to the screen. Hence, as the user clicked on parts of the graph, it'd pivot the viewport to that perspective.

OK, user clicks are something I think htmx can deal w

🙂

But if you are doing a multi dimensional fly through... maybe not so much

OTOH, right now the reality is that no one ever got fired for choosing react or view 😉

The other thing I have to work with is long computations on the server side, and I'll need a way to cancel them. In other words, I could move to one area, linger (setting off a bunch of server-side queries), but then when I move away, I need to cancel those queries. Users have really grown accustom to not clicking to save, or even view. Simply mousing over and lingering is what they really expect these days. It's like I want to start a process if a user lingers over an area for 50ms, but, if they leave before the computation is finished, abandon the computation, and start computing what ever they move to next. Something like this would give the visual interactivity that users have come to expect. In these cases though, I'm not sure Vue/React would help me anyway, as I'd need to either send the entire object up to the client, or find some incremental API.

hmmm, that's interesting

i like the idea of being able to cancel a request...

@mysterious-toddler-20573 Basically, my application is a query interface, and users will be debugging queries. So, think of it more like a notebook like Jupyter, only hierarchical. State of the art in Julia community is Pluto.jl (https://github.com/fonsp/Pluto.jl)

You can kinda do that with htmx. If your trigger is mouseenter, your server can immediately respond with a temporary "loading" div that has an onload trigger, which starts the actual long query. The outer element can have a mouseleave trigger that cancels the query

There's probably a billion edge cases that would need to be addressed

Or you can have an explicit "cancel" button that does an oob swap on the loading div

@User So, server side, requests will have to be spun as background generation tasks, and I want to be sending updates to the client, incrementally as the computation progresses. The issue is cancelation, it's always cancelation. The inability to cancel background processes is (one of many things) that killed my previous project... http://htsql.org

So, what I want to rebuild is a next generation of... http://demo.htsql.org/school%7Bname,count(program),count(department),%20/program,%20/department%7D

Only that I learned I can't show a tree with two branches at the same time, you have to collapse one branch, or the other and not show both at the same time.

I have no clue what I'm looking at

It's query results, from the query in the text area.

I'll get back to this later

Gotta get some of my own work done for a change

Yep, thanks for the chat. I like the div idea.

@User For data science people, which might be a great fit for HTMX, what they are often looking for are interactive screens like ... https://github.com/fonsp/Pluto.jl#html-interaction ... only where the interactivity basically causes a new computation, which causes a new graph to be displayed. Note that there's no cancel buttons. You drag a slider, it fires off update queries, causing it to be interactive. Pluto.jl uses client side widgets written in Preact, on events from those widgets, it sends off requests to a server-side process, which returns results in MsgPack, which are then put into the model used by the Pract widgets.

There is a significant disadvantage to this two-language approach, the primary language of the developer in this case is Julia, not React/JS. As a result, when adding new data types to Julia, if you want them to have specialized visualization, you have to make the front-end know about it as well. Hence, your packages now have to have both Julia and JS code, only that the JS code uses a node.js build process. This begs a monorepo approach, where you fork the application to make parallel changes in the front and backend to keep them in sync. It works well when the original project was intended to be forked... but it lacks a means of encapsulation. Anyway, perhaps the solution would be to use HTMX to send up Vue templates or JSX that orchestrates the particular widget.

Here is a 20 minute video of the most exciting visualization project at JuliaCon...

The Julia community is looking for something like https://shiny.rstudio.com/

Yeah, for a slider, I don't see any reason why htmx rerendering an SVG or whatever would be any slower than some crazy client side javascript. If the server side computation is fast, it will be fine. If that demo is doing a bunch of client side caching and/or computation to make that all work... maybe not so much.

> There is a significant disadvantage to this two-language approach @User This is one argument I make for htmx: you are always going to have at least two languages: HTML and something. So you might as well make HTML useful. 🙂