https://htmx.org logo
Join Discord
Powered by
# hotwire-htmx
  • r
    **intuitive
  • m
    This is exactly what we've implemented and we're really happy about it. htmx and Stimulus play very nice with each other as: - They are both data-attribute-driven, so what happens to a DOM element is very clear just reading the HTML - They are both JS-event-centered, so they can communicate with each other very easily - htmx updates the DOM, Stimulus observes the DOM mutations, so no need for complicated event listener boilerplate It makes it very easy for us to apply advanced JS behavior to some elements that are lazily added to the page without having to write any inline JS, and keep the whole thing very understandable.
  • o
    These are great points and they solidify a lot of what I was thinking/feeling. In conjunction, I feel like this would be a very productive stack, and am excited to get it up and running. Are you running this on Rails?
  • m
    Yes: this architecture, coming from a React SPA consuming JSON:API, has improved our velocity, big time. And also improved end-user performance. And also reduced our costs. And also made us happier developers. All that is detailed in the talk I've given at DjangoCon Europe (

    https://www.youtube.com/watch?v=3GObi93tjZI▾

    ) 2 months ago. Our base stack is Django, which seems pretty similar to Rails from my point of view.
  • m
    Is the script tag a link to the file or an inline script
  • m
    If it’s a link does the browser still make a network call if it’s cached?
  • m
    Assuming it gets cached
  • r
    In my case, inline, for Locality of Behavior. 1 widget = 1 template file with everything it needs.
  • m
    I see so if the widget is used multiple times on the same page it’s still inline? Or that when you use a link
  • r
    So here's the thing. If it's a stateful widget, yes. Because you're keeping state in the DOM anyway.
  • r
    I try to keep complexity down enough that I don't have extra .js files except in circumstances that really warrant it
  • r
    One has to ask themselves realistically how many times they are using a widget on a page as well. There's major simplicity wins from having less files, less code.
  • r
    If I have 4 of the same widget that has 10 lines of logic... is that really worth having more files?
  • m
    So you do it this way until it becomes a problem then?
  • m
    Fair
  • r
    Stuff that compliments this pattern well... hyperscript tailwind htmx of course. Basically all of these allow you to write stuff inline without specifying classes, id's, etc. All strategies which drastically cut down the lines of code. Keeps the state in the Element the logic is directly attached to.
  • r
    And I mean of course, if you need all of X widget on a page, you just do that query and loop over them all. (
    any()
    in surreal)
  • r
    or if you really really need to give a specific name to a widget, just do it.
  • r
    Anyways, these ^ patterns are a whole extra level deeper than the original idea aha.
  • m
    Nice library
  • r
    Thanks. Yeah, heavily inspired by hyperscript, but focused on vanilla js.
  • d
    Dope concept. Any plans on pushing this to npm? Would be dope to have this picked up via unpkg/skypack
  • r
    I recommend people take a copy off github because 
    surreal
    is already taken on npm, and I don't really want to get involved in the politics to get the name just for 300 lines of code including comments.
  • r
    surreal isn't going to see drastic changes, it has zero dependencies, and only uses very typical browser javascript to work.
  • d
    yeah, fair enough
  • r
    Also thanks for the kind words, glad to be part of what seems to be an industry-wide rethinking of direction in front-end. @mysterious-toddler-20573's htmx community is the place to be.
  • o
    I have been using stimulus with htmx for a week now and it is awesome. I have been tinkering on a Roda application and it is small and fast and wonderful to work with.
  • m
    stimulus + htmx was not on my 2022 bingo card, but people seem to love it!
  • m
    All hotwire discussion must now take place in this channel
  • m
    DHH discussion too