[troupo]

All the hx-* attributes constitute a separate DSL with its own semantics and it requires the server to conform to this DSL that also subsumes a bunch of existing HTTP semantics like redirects.

  <!-- Some kind of inline DSL in an attribute? Check -->
  <div hx-get="/example" 
       hx-swap="innerHTML show:#another-div:top">
    Get Some Content
  </div>


  <!-- Some kind of inline DSL that is sorta kinda JS? Check -->
  <div hx-get="/clicked" hx-trigger="click[checkGlobalState()]">Control Click Me</div>

  <!-- Some kind of inline DSL that is marked as Javascript and with magic values passed in? Check -->
  <div hx-get="/example" hx-trigger="keyup" hx-vals='js:{lastKey: event.key}'>
    <input type="text" />
  </div>


  <!-- Is it Javascript? Jinx, it's custom DSL  -->
  <button hx-get="/info" hx-on::before-request="alert('Making a request!')">
    Get Info!
  </button>
  <button hx-get="/info" hx-on="htmx:beforeRequest: alert('Making a request!')
                              htmx:afterRequest: alert('Done making a request!')">
    Get Info!
  </button>

And so on.

[recursivedoubts]

i agree

we are tentatively working on a proposal with the chrome team that takes the most important concepts of htmx and integrates them into HTML using more standard attributes. Alex Petros, a core htmx dev, gave a talk at Big Sky Dev Con on this idea here:

https://www.youtube.com/watch?v=inRB6ull5WQ

this will obviously be a much longer and more difficult process, but hopefully it will give HTML enough oomph that htmx will often be unnecessary

all of that doesn't change the fact that the code above is hyperscript, not htmx

[naasking]

I'm convinced you can get most of htmx by extending standard attributes to other elements and using the standard on* attributes. htmx basically acts as a "universal/general event handler" that translates DOM events to requests and back to DOM events and modifications. It breaks down like this:

* use on* html attributes to delegate events to a universal event handler

* event handler pulls out the form attribute (if set), then pulls out action, method, target from element, or from the form if unset on the element (elements inherit these from the form they are tied to)

* if action is a URL, then initialize a fetch request using specified URL and method; if method is POST, then add a FormData payload for the specified form

* on fetch complete, the returned MIME type should match with the target attribute, which is extended to also accept a css selector:

   target=_self|_blank|_top  <=> content-type:text/html           => redirect | morph/hx-boost + push-url

   target=css selector       <=> content-type:text/html-fragment  => morph    | innerHTML

So something like:

    <a action="/url" method="post" onclick="universalHandler(event)" form="someForm" target="_self">click me</a>

I have ideas for extending beyond this, but this seems like the core of extending HTML to cover htmx semantics.

[recursivedoubts]

yep I think you could do a lot in this direction (see Alex’s talk) I would be hesitant to hijack existing attributes for more than a proof of concept at this point but maybe that’s me being too timid.

[troupo]

> all of that doesn't change the fact that the code above is hyperscript, not htmx

--- start quote ---

https://htmx.org/

htmx gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes: https://htmx.org/reference/#attributes

--- end quote ---

All my examples come directly from htmx documentation

[recursivedoubts]

sorry! Got you crossed up w sapling-ginger above and thought I was talking w the same person.

agree that htmx has a regular language core for config options but, as hyperscript indicates, I’m not afraid of even a recursive language when I think it’s useful.

Hopefully we can get some of the ideas into HTML in a more standard form!

[PDSCodes]

I would love for the authors to consider a book on Hyperscript.

I initially dismissed wanting to add another scripting language to an app, but after some experimenting I have used it to replace 100s of lines of JS. Mainly for UI animations.

It’s not for the faint of heart, but enjoyable to learn.

I find the docs difficult to follow and would enjoy another hardback manual to sit next to this book, which is superb.

[recursivedoubts]

i'd love to write a book on hyperscript, but i should probably get it to 1.0 first :)

maybe next summer

[dartos]

The point isn’t to erase the need for JavaScript entirely, but to make it possible to integrate and interact with a backend in a meaningful way using just mainly html.

[troupo]

That literally isn't what I talked about.

[dartos]

3 out of 4 of your examples mentioned using js or a js-like DSL.

Explain your point better

[troupo]

It's enough to read the context of the discussion, don't you think?

Original complaint: "it's describing a "whole other language" they call Hyperscript"

Response: hyperscript is a completely separate technology. htmx generalizes hypermedia controls, that's pretty much it, and it can be used with any scripting tool you'd like

My response:

In reality [1] htmx defines its own non-optional DSL that you have to use.

---

I will add that as with any organically grown nice-to-have utility DSLs it's quite haphazard (it's hyperscript-like in one place, js-like in another place, both in some other places etc.). But that's the nature of such ad-hoc informally specified DSLs

[1] which can be easily verified by just visiting https://htmx.org

[ungamedplayer]

> In reality [1] htmx defines its own non-optional DSL that you have to use.

---

I don't use hyperscript with my htmx, ergo it IS optional in objective reality. Citing a use with it does not prove it can't be used without it.

[troupo]

https://news.ycombinator.com/item?id=40746543

Nothing in the htmx docs shows it's optional.