https://htmx.org logo
Join Discord
Powered by
# htmx-general
  • m
    Isn't this kinda just svelte
  • m
    but like, coffeescriptified
  • s
    Seems like it
  • r
    Yeah I remember when this came on HN. Looks nice on the surface, but was turned off by all the compile steps + DSL's everywhere
  • r
    htmx could really use a tailwind, that just isn't as super thicc as tailwind. Same design philosophy as htmx, just a bunch of Locality of Behavior atomic blocks you can chain together to build shit.
  • r
    Single file, etc.
  • r
    2 tix left until jquery 4.
  • r
    3 -> 4 is a code removal release. replacing internals with standard 
    querySelectorAll()
    etc.
  • r
    Still, gonna be great to just use htmx for everything in some projects with the new 
    hx-on
  • g
    thought: if we require an 
    hx-on
    attribute for using event listeners, we don't need to require 
    hx-
    before the actual event listeners
  • r
    oooo, good point.
  • g
    Copy code
    html
<button hx-on onmycustomevent="doStuff()" on-htmx:before-request="doOtherStuff()">
  • g
    just parse 
    on
    attributes normally, with an optional 
    -
    or 
    :
    after the 
    on
  • r
    Copy code
    html
<div hx-on on-click="..." />
    More minimum example for people following.
  • r
    Yeah, I agree! Nice.
  • g
    we might need to avoid parsing the built-in event attributes
  • m
    Isn't this what you get by putting your templates in different files? I guess you don't get the backend behavior...
  • m
    You can always just write your templates next to the corresponding backend function,
  • o
    how can you de-thicc something that is based entirely on being bloat
  • r
    the original concept of bite sized styles came way before tailwind, it just fell out of fashion, came back into fashion.
  • r
    it used to fall apart quickly because some browsers had horrible consistency with others.. but with modern standards, makes sense again.
  • s
    Agree. So going back to building with boring tools
  • o
    I still don't get what you're proposing.
  • b
    Copy code
    <div hx-get="/some/view" hx-params="*" hx-trigger="load">
  <div hx-get="/another/view" hx-params="*" hx-trigger="click">
    <input name="foo" value="bar" />
  </div
</div>
    Is it expected that the outer div doesn't include 
    ?foo=bar
    when triggered even though specifying 
    hx-params="*"
    , if yes is it because nesting 
    hx-get
    will make the inner div "shadow" the outer one?
  • b
    (I could work around this using 
    hx-include
    so mostly just curious)
  • l
    I always thought the 
    hx
    syntax was just for the naming convention, but semantically this is my favorite version of the 
    hx-on
    proposal (valueless "listen" attribute, named attributes for each event)
  • h
    - with 
    hx-
    prefix it's easier to add / remove a single attribute, no risk to forget about necessity of handling 
    hx-on
    - multiple 
    hx-
    attributes is nicely sorted by an editor, so you see everything related to logic close together - it feels similar to flat vs nested structure
  • t
    I got it to work 🥲 Thanks for your help!
  • r
    Completely agreed, but unfortunately, as discussed fairly extensively in #1079191774976802867 ... 
    hx-on
    is required to prevent re-scanning the entire DOM when setting up event listeners because 
    querySelectorAll()
    does not have the ability to use wildcards for attribute names, only attribute values.
  • r
    I think that we should have 
    hx-on
    + 
    hx-on-[event]
    to highlight that these attribute are implemented by htmx. Just having `on:`/`on-`/`on` prefix without 
    hx-
    may lead to conflicts. Also, I'm not a fan of ambiguity with optional 
    :-
    separators.
1...107710781079...1146Latest