1. 25
  1.  

  2. 4

    See also: https://lobste.rs/s/nyxq4o/hotwire_html_over_wire

    The main difference seems to be in how the boundary of replacement content is specified. Personally, I find the hotwire way a bit easier to understand.

    1. 1

      htmx is smaller, and fortunately for me I understand htmx better.

      I’ve often thought “I want to fetch this element from the server every so often.” I’ve never thought “I want to frame this part of the page to be a lazy subscribe to the a topic on the server.”

    2. 2

      Similar to Unpoly, apparently.

      1. 1

        From a very brief look, Unpoly seems to at least be based on the principals of progressive enhancement.

        e.g. decorating a regular href, so that it is handled more “smoothly” via JS XHR/fetch, but still working fine without JS enabled/working.

        The OP article describes the lib with two examples that would just break completely without JS.

        It does however bother me how much these things all add randomly named attributes. I thought we’d all agreed upon data-* attribute names.

      2. 2

        I find the motivation part a bit of baffling:

        Why should only <a> and <form> be able to make HTTP requests?

        Why not? Isn’t that the principle of the least surprise? (I’m not trying to be condescending here, I’m really puzzled why would other elements be able to make HTTP requests)

        1. 1

          I mean at this point they’re basically asking for a markup language to be a scripting language.

          “Why can’t my italicized markdown make requests??”

        2. 1

          This is neat! I think this is definitely the direction we should be heading, but it’s very slow. I tried out https://htmx.org/examples/click-to-edit/ example and it just feels sluggish to edit the form whereas with JS it would’ve been much faster (just manipulating the DOM instead of sending a HTTP request).

          1. 1

            I wonder how much of that is the 100ms deliberate wait-to-replace.