7 ms·

Hey Dan, htmx maintainer here. I would love to know in what other two ways relative links are broken, and which event stopped working, so we can get those fixe

Hey Dan, htmx maintainer here. I would love to know in what other two ways relative links are broken, and which event stopped working, so we can get those fixed. With respect to the fix you PRed (thank you, by the way), we did get that merged very quickly, and would love to do the same for whatever is broken here, even (especially) if you are no longer interested in doing the fix yourself. [0] As for the DX of making changes to htmx: absolutely true! The single file is a DX we've chosen, and it has both costs and benefits, which we've written about in "Why htmx doesn't have a build step". [1] [0] https://github.com/bigskysoftware/htmx/pull/1960 https://github.com/bigskysoftware/htmx/pull/1960 [1] https://htmx.org/essays/no-build-step/ https://htmx.org/essays/no-build-step/

everybodyknows 2y ago
Maybe I'm missing something here, but JS modules do not require a build step. * Note to non-JS hackers: JS module symbol scope is per-source file.
- recursivedoubts 2y ago
  JS modules can't be imported with a plain script tag.
  - throw5959 2y ago
    Script type=module doesn't work?
    - rob 2y ago
      Not if you want to support the 0.2% market share that IE 11 has.
      - danpalmer 2y ago
        That's true, but also a trade-off that is a perfectly valid engineering choice for many or even most teams.
      - cryptos 2y ago
        HTMX 2 stopped IE support, so that shouldn't be an issue.
      - knowitnone 2y ago
        we don't :)
    - recursivedoubts 2y ago
      we want to support the traditional script tag w/ a src attribute and nothing else
      - throw5959 2y ago
        Why?
        recursivedoubts 2y ago
        idk just like it better that way
        Andrex 2y ago
        Chiming in to say modules are awesome and you shouldn't be so scared.
        recursivedoubts 2y ago
        I'm not scared, I just want people to be able to include htmx on their page the same way, for example, good ol'jQuery is included. We generate esm and cjs modules for people who want to use htmx in that manner though: https://github.com/bigskysoftware/htmx/tree/master/dist https://github.com/bigskysoftware/htmx/tree/master/dist
  - seumars 2y ago
    you can define import maps in a separate <script> tag and reuse the module name elsewhere
    - recursivedoubts 2y ago
      sure, but I wanted the same experience of, say, jquery, where you just drop in a script tag w/ a src attribute and it just works an aesthetic decision, I suppose
- paulddraper 2y ago
  Depending on the import tree depth, it significantly increases latency. (Which is why bundlers still exist.)
danpalmer 2y ago
Hi Alex, thanks for the reply and for your work on HTMX. I love the idea and think there's a strong need for something like HTMX, and if HTMX can live up to those promises then great. For me it doesn't, currently, but it sounds like it does for others. The relative link bugs are [0] and [1], and I fixed [2]. My fix was merged quickly, but the other two bugs of what appears to be similar significance, have been open for well over a year each. My issue however is less about these specific issues, and more the general lack of support for hypermedia, which speaks to a general state of HTMX not living up to its promises. As for the DX, I think not having a build step, and code structure, are somewhat orthogonal. I agree with much of that essay, but most of it is about issues with complex build systems and the use of Typescript. It's not about having 190 top-level functions, which, with all due respect, I think indicates a lack of architecture. Again, the issue is less about the specifics, and more about the fact that HTMX is not living up to its promise of simplicity because of how impenetrable the codebase is in this regard. As mentioned, so far I have found Stimulus and Turbo to be better implementations of what HTMX appears to promise to be. More activity in this space from anyone and everyone is great here though! [0]: https://github.com/bigskysoftware/htmx/issues/1476 https://github.com/bigskysoftware/htmx/issues/1476 [1]: https://github.com/bigskysoftware/htmx/issues/1736 https://github.com/bigskysoftware/htmx/issues/1736 [2]: https://github.com/bigskysoftware/htmx/pull/1960 https://github.com/bigskysoftware/htmx/pull/1960
- francasso 2y ago
  Why is the number of top level functions a problem? As long as they are named and organized appropriately I don't see the issue
  - justinator 2y ago
    See: php.
  - striking 2y ago
    I love writing prototypes as a single file as much as the next guy, but there's almost 5k lines of code in this one file: https://github.com/bigskysoftware/htmx/blob/master/src/htmx.js https://github.com/bigskysoftware/htmx/blob/master/src/htmx.... They're sectioned off, so "event/log support" and "AJAX" and such are grouped by the type of method, but they're not prefixed so there's no way for your editor to help you explore grouped functionality. Given that the code isn't particularly organized or structured in any way that I could quickly glean (aside from the aforementioned grouping of related functionality, which is only so helpful), I think I'd be put off from wanting to contribute to this codebase.
danpalmer 2y ago
Sorry, forgot about this bit: > and which event stopped working It was `htmx:load`. On 1.x this fired on first page load, which I used to do a bunch of setup of the other little bits of JS I needed, and which would cause that JS to re-setup whenever the page changed. On 2.x this never fired as far as I could tell. Maybe I got something else wrong, but only downgrading to 1.x seemed to fix it immediately, I didn't investigate further. I did wonder if there were breaking changes in 2.x, but as far as I could tell from the release notes and documentation there were not.

everybodyknows 2y ago

Maybe I'm missing something here, but JS modules do not require a build step. * Note to non-JS hackers: JS module symbol scope is per-source file.

recursivedoubts 2y ago
JS modules can't be imported with a plain script tag.
- throw5959 2y ago
  Script type=module doesn't work?
  - rob 2y ago
    Not if you want to support the 0.2% market share that IE 11 has.
    - danpalmer 2y ago
      That's true, but also a trade-off that is a perfectly valid engineering choice for many or even most teams.
    - cryptos 2y ago
      HTMX 2 stopped IE support, so that shouldn't be an issue.
    - knowitnone 2y ago
      we don't :)
  - recursivedoubts 2y ago
    we want to support the traditional script tag w/ a src attribute and nothing else
    - throw5959 2y ago
      Why?
      - recursivedoubts 2y ago
        idk just like it better that way
        Andrex 2y ago
        Chiming in to say modules are awesome and you shouldn't be so scared.
        recursivedoubts 2y ago
        I'm not scared, I just want people to be able to include htmx on their page the same way, for example, good ol'jQuery is included. We generate esm and cjs modules for people who want to use htmx in that manner though: https://github.com/bigskysoftware/htmx/tree/master/dist https://github.com/bigskysoftware/htmx/tree/master/dist
- seumars 2y ago
  you can define import maps in a separate <script> tag and reuse the module name elsewhere
  - recursivedoubts 2y ago
    sure, but I wanted the same experience of, say, jquery, where you just drop in a script tag w/ a src attribute and it just works an aesthetic decision, I suppose
paulddraper 2y ago
Depending on the import tree depth, it significantly increases latency. (Which is why bundlers still exist.)

danpalmer 2y ago

Hi Alex, thanks for the reply and for your work on HTMX. I love the idea and think there's a strong need for something like HTMX, and if HTMX can live up to those promises then great. For me it doesn't, currently, but it sounds like it does for others. The relative link bugs are [0] and [1], and I fixed [2]. My fix was merged quickly, but the other two bugs of what appears to be similar significance, have been open for well over a year each. My issue however is less about these specific issues, and more the general lack of support for hypermedia, which speaks to a general state of HTMX not living up to its promises. As for the DX, I think not having a build step, and code structure, are somewhat orthogonal. I agree with much of that essay, but most of it is about issues with complex build systems and the use of Typescript. It's not about having 190 top-level functions, which, with all due respect, I think indicates a lack of architecture. Again, the issue is less about the specifics, and more about the fact that HTMX is not living up to its promise of simplicity because of how impenetrable the codebase is in this regard. As mentioned, so far I have found Stimulus and Turbo to be better implementations of what HTMX appears to promise to be. More activity in this space from anyone and everyone is great here though! [0]: https://github.com/bigskysoftware/htmx/issues/1476 https://github.com/bigskysoftware/htmx/issues/1476 [1]: https://github.com/bigskysoftware/htmx/issues/1736 https://github.com/bigskysoftware/htmx/issues/1736 [2]: https://github.com/bigskysoftware/htmx/pull/1960 https://github.com/bigskysoftware/htmx/pull/1960

francasso 2y ago
Why is the number of top level functions a problem? As long as they are named and organized appropriately I don't see the issue
- justinator 2y ago
  See: php.
- striking 2y ago
  I love writing prototypes as a single file as much as the next guy, but there's almost 5k lines of code in this one file: https://github.com/bigskysoftware/htmx/blob/master/src/htmx.js https://github.com/bigskysoftware/htmx/blob/master/src/htmx.... They're sectioned off, so "event/log support" and "AJAX" and such are grouped by the type of method, but they're not prefixed so there's no way for your editor to help you explore grouped functionality. Given that the code isn't particularly organized or structured in any way that I could quickly glean (aside from the aforementioned grouping of related functionality, which is only so helpful), I think I'd be put off from wanting to contribute to this codebase.

danpalmer 2y ago

Sorry, forgot about this bit: > and which event stopped working It was `htmx:load`. On 1.x this fired on first page load, which I used to do a bunch of setup of the other little bits of JS I needed, and which would cause that JS to re-setup whenever the page changed. On 2.x this never fired as far as I could tell. Maybe I got something else wrong, but only downgrading to 1.x seemed to fix it immediately, I didn't investigate further. I did wonder if there were breaking changes in 2.x, but as far as I could tell from the release notes and documentation there were not.