htmx

very unlikely the correct way of doing things

yeah my next step was just going to be either use hyperscript or just build the forms myself. Probably the latter. But first I'll try that dev branch.

htmx 2.0 (mid 2023) initial brainstorm: https://gist.github.com/1cg/f1a6d44c34195c4b6b30df864cf3dcef

inheritance is the big potential semantic change

<@252481517106888704> very interested in any additions you have re: web services, <@732737380167188501> similar for SSE, would love to hear from you both on it (of course w/ the extensions we can get more aggressive in the 1.0 line)

<@732737380167188501> maybe the 2.0 release is a chance to move extensions out to a separate repo and formalize that whole concept?

if we're dropping IE we might as well wait for navigation api to be implemented across browsers

Hello everyone. I've been working around some websocket related stuff recently, and I have to say, the events are the most lacking aspect of WebSockets rn. There is an issue that tracks it https://github.com/bigskysoftware/htmx/issues/699, so if I were to pick, this would be my top priority. 

This issue also suggests implementing shared websockets core for hyperscript and htmx. I think, the scale of such effort is quite appropriate for the 2.0 milestone, so we may look in this direction

On top of that, there is some potential for expanding on websockets capabilities. For example, implementing server message headers or implementing some sort of  "topics" or other message filtering mechanism. I imagine, this could apply to SSE as well. There would be a lot to discuss regarding design of these features though.

Also, yes, rip the legacy websockets from the core

Unrelated to WebSockets, this looks interesting https://github.com/bigskysoftware/htmx/issues/255

https://caniuse.com/?search=navigation%20api

Yes, definitely. I love the idea of a plugin repo.  Though, I’m hoping that we can enhance the extension/plugin mechanism enough that they’ll be near-ground-up rewrites.

Depending on when we’re targeting release, that may land in all browsers before we’re done.

But seriously, I’ll love to contribute to htmx 2.0. I’ll probably need you to lay out the basic structure, but I’d love to help fill in the details. (And shout old-man ideas from the bleachers)

It’s not my call, but probably not. <@725789255590215732> is still pushing to minimize the build tool chain, and I can’t blame him for tat.

However, we’ve gotten 90% of Typescript’s value out of jsdoc comments, so I’m not worried about it anymore.

True, but if I may say typescript built with esbuild no longer feels like building with webpack (Go Go!)

I would like to see jsdoc comments become the standard through all the code (instead of the retrofit we’ve done so far). It would make them more consistent and usable.

That’s cool to know. Honestly, I haven’t used any TS since switching to htmx/hyperscript.  Is that a win?

jsdoc comments certainly help. can you do global jsdoc declarations though? there are some structures/objects that could do with global dectarations

Ive come to realize that the "enemy" isnt the build pipeline, its the cornucopia of import dependencies that makes it such a nightmare.

my current rule is my builds only include my code. And that has worked wonders.

Also methinks that the win (wrt to using TS in htmx) would be that it makes it easier for new-ish folks to contribute. As long as we dont go crazy with interfaces and what not we would have defined structs with helpfull compiler/editor warning as we muck around the code base.

I would like to keep htmx pure javascript, although w/ dropping IE support we can take advantage of more modern features.  And I like the type annotation stuff Ben has been doing

how do people feel about explicit inheritance?

```html
  <div hx-target:inherit="this" ...>
     ...
  </div>
```

On this, it depends on some html specifics I’m not familiar with it. Are there anything like “wildcard queries” for CSS?  Is it reasonable (and fast) to do something like `document.queryAll(“hx-*”)`?  If so, then there’s no real penalty for putting the extra parameter in the attribute name. But if there’s is, then perhaps we need to find a standardized way to stuff that info into the attribute value instead.

I think it would be relatively fast to use it as a postfix

but the concept is more important than the syntax at this point: explicit inheritance rather than implied inheritance

given our recent experience pushing htmx pretty hard?

I’ve been thinking about it quite a bit too and also keep going back and forth on it. 

On the one hand, I’ve definitely run into the thing where suddenly unexpected things happen due to a parent element somewhere. It is almost always pretty simple though to just slightly restructure the hx attribute placement, or explicitly specify overriding hx attributes. I think we still don’t have a hx-disinherit situation anywhere in the codebase? We also do make use of implicit inheritance extensively in things like button bars, etc (I don’t like repeating myself). 

On the other hand though, removing implicit inheritance will mean less of having to override child elements with hx attributes and all round just reduce those “huh? Why is that happening? Oh, it’s because of a parent” moments. You could argue that having to explicitly say you want to inherit, is more LoB, less spooky action at a distance. 

If I’m being totally honest with myself, I’m probably fearing a switch to explicit inheritance mostly because it would mean a fair amount of work to go add hx-inherit in a bunch of places in our codebase. Is breaking backwards comparability in this regard enough of a reason to NOT make the switch in htmx 2.0? Probably not?

If I look at the recent stuff we did together <@725789255590215732>, it’s pretty tight… but also depends on the htmx attributes being placed in just the right places to avoid unwanted inheritance in some cases, whilst in other cases the inheritance serves us very well and helps with keeping the code clean and elegant. 

I observed how your brain always keeps the inheritance in mind, whilst I still sometimes get caught out and have to think a bit before I realize what’s going on. Perhaps making it explicit will help both old and slow folks like me, and people new to htmx, to avoid the head scratch moments?

Wow… I didn’t realize I was writing a blog post again, this was a proper brain dump 🙈

What does "this" represent, and what other options are there.
I'm all for explicit inheritance. If its that much of a breaking change couldn't we have a config option that toggles what ever the default is?

Javascript with tons of type annotations it is then!

my take on explicit inheritance
```
hx-swap="<value> | inherit [from <selector>] [with <object>]"

hx-get="inherit"
hx-put="inherit from #form"
hx-vals='inherit with {"a": 10}'
hx-vars='inherit from #el with {"b": 11}'
```

the `with` clause is meant to be used with complex object values, like hx-vals, to extend and override values (basically calling Object.assign)

if `from` is missing, the value will be inherited from the parent hierarchy (like current implementation)

of course, in case of a deep inheritance chain (`inherit from #input`->`inherit from #form`->`inherit from #something`->`inherit from #else` and so on indefinitely), this feature may become a performance bottleneck (also, cyclic inheritance is possible), so maybe `from` is not the best idea in the world, but I'll leave it up for discussion

interesting, so use site rather than decl site

Good Morning (or whatever) - I am under the impression that using `hx-boost` does not update `<link>` tags in the `<head>`. I'm I right? And is there a config I might have missed to choose what to update in the head?

correct, boosted links only update the body

But it still update some tags in the head, like `title` and other `meta`s

turbolinks does more elaborate updates of `head` from what I remember, I will add it to the list to look at for 2.0

Cool. With what I have in mind, I kind of need a full diff.

Yeah, Ive played around a bit with their stuff a couple months back.

you should be able to use turbolinks/turbo and still use htmx for more fine grained stuff if you want

boosting was kind of an afterthought for htmx and intercooler, and has become more important as people use it, so I need to put some time into the feature for 2.0

<@725789255590215732> wow, target = next td works!

```html
<select>
  <option value="?">--------</option>
  {% for flavor in listofflavors %}
  <option value="{{ flavor.id }}">{{ flavor.name }}</option>
  {% endfor %}
</select>
```

it was weird, I had to wrap what the htmx returned in <select>

before I didn't have to do that when I targted the id directly by name

https://jasonformat.com/islands-architecture/