I was kidding. I've had a lot of offline stuff going on that has made it hard to focus on htmx, and I got side tracked w/ the idiomorph exploration, etc. It looks like the offline stuff is coming to an end and I'll be able to address all the little annoying issues, starting w/ OOB (which I kinda f'd up, but I want to fix in a backwards compatible way)

It's not about dropping. It's about pros and cons. Pros must contain solution to problems that we currently have. If not - we don't want cons that come with that. I'm always open for discussions.

Oh i mean if its just a bridge too far or not really desired then its silly to rehash. If the reason its not done is nobody want to take the plunge and rule7b that's a different story

I'd just do it but its the response will be, meh... pass then its not worth forking over

if we end up w/ a built tool, u r my guy

i just want to tooling to do my extension nicely... its htmx all over again in microcosm... writing more code to write less

I find htmx great, but it's lacking one thing. Optimal diffing. I'm working on this page right now and it has a lot of granular swaps. It's fcking Excel with filters and stuff. So for this thing to work FAST it requires from me to pick what I want to render in response by hand. Otherwise if I render big chunkgs and rely on morph, it takes 1-2s to accomplish (not full page, parts of it, but still). So ideally I need something like Phoenix LiveView granular diffing that's done automatically. But I hate LiveView - it looks cool, but is very heavy and complex. And I don't need websockets that come with it. So right now nothing is left but just render pieces manually. It's productivity killer though :/

what's your backend?

How do you deal with that? Is there a pattern to avoid this hand-picking of responses?

Node

hmm, i have ideas for go

I'm open for ideas. No matter the language

before find htmx had a go version of liveview but with binary diffs https://github.com/gogoracer/racer/blob/main/pkg/gas/protocol.proto

I have gazillion variations of different responses, and it's killing me

but for 95% of problems htmx makes more sense. have you tried morphdom for the diff?

Can you explain a bit? Conceptual idea

morph takes 1-2s to perform on the client side. So my server is faster than the client diff

It's a spreadsheet. It's huge

so in go world there is too version of liveview... one is template->HTML->parse back to *html.Node and diff on the nodes. Other is to have a vdom in the backend and generate the diff skipping the templating

Catching up on the last week - isn't this whole PR/build step discussion surrounding making htmx play nicely with https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/importmap ? I don't think something that's supported by most browsers is a flavor-of-the-month; it sounds to me more like some hidden gem that will be discovered. It is ironic that, to support not having to build it, you have to build it; but htmx's pitch is using JavaScript so you don't have to use JavaScript, so it's not unheard of... LOL

https://github.com/jfyne/live/blob/master/diff.go#L201 is the main diff of the dom nodes

But its kinda antithetical to htmx way I think @some-airline-73512

You could side channel with socket. My stuff like that I'm doing with NATS

mmm

I do like the fact that the change has...

js
var htmx = ...

at the start

Yeah, this seems to be the way. I will need to do some experiments with it. Thanks

rather than

js
//AMD insanity
(function (root, factory) {
    //@ts-ignore
    if (typeof define === 'function' && define.amd) {
        // AMD. Register as an anonymous module.
        //@ts-ignore
        define([], factory);
    } else {
        // Browser globals
        root.htmx = root.htmx || factory();
    }
}(typeof self !== 'undefined' ? self : this, function () {
return (function () {

\> mf every time I look at that code

Not that the decision to introduce a build step should be taken lightly - just that this doesn't look like flavor-of-the-month stuff. 🙂

i have to say I am not feeling particularly happy about some of the historical decisions made by javascript thought leaders and I do not intend to sugar coat this fact