https://htmx.org logo
Join Discord
Powered by
# htmx-general
  • e
    FYI we ended up being able to leberage hx-preserve.. which makes sense 😆. no need for merging at all
  • e
    Damn, I'm sorry I missed this whole discussion about my PR 😂
  • e
    Here's my opinion:
  • e
    Ultimately, I wrote that PR for one reason: ESM is not currently correctly supported in htmx. In other words, if you do something like 
    import htmx from "https://unpkg.com/htmx.org@1.8.5/dist/htmx.js"
    then 
    htmx
    isn't defined like it should be.
  • e
    The reason I want to do that, is so that I don't have to treat 
    htmx
    as a global. I've always heard globals are bad, and 
    import
    is JS's solution to that
  • m
    i am grabbing lunch, but keep typing
  • m
    @echoing-dress-67727 I liked your PR 🙂
  • e
    So, to add ESM support I see two ways forward: 1. Continue manually having the weird wrapper around everything (what is currently dubbed "AMD insanity") 2. Set up a build system to add that wrapper for us. I opted for 2 because it's what every other library out there is doing.
  • e
    To be honest, I don't fully understand what that wrapper does. But I know it's currently wrong for ESM. And I know rollup (or other build systems I guess) handle setting that wrapper up for library in a standard way, without polluting the source code
  • e
    That was my main reason for putting in the effort for that PR
  • e
    That said... there are other benefits to the build system, which @mysterious-car-3675 has been advocating for well
  • e
    It sounds like I'm the contradictory opinion here, but I don't like having all of the source code in one file. Every time I've thought "hmm, why is htmx doing this?" and I go to dig through the source code, I want to pull my hair out because it's SO much going on in one file. I'd much rather see small files with single responsibilities, neatly organized, so I don't have to keep all of HTMX in my brain at once.
  • e
    If the code was split up, a build tool would be a requirement
  • m
    @echoing-dress-67727 brace yourself. Grug like stone, stone easier than bronze. Bronze hot scary, make big mess no future. 😛
  • e
    Also, fwiw, I'm also aggravated by the constant "build system of the week" problem in JS. I'm currently in the process of migrating from webpacker (which is Rails's wrapper around webpack) to importmap, because importmap has no build system which is AMAZING. But this lack of ESM support was a blocker for me to do that
  • e
    haha fair enough. I get it
  • m
    @echoing-dress-67727 wanna fork and just make htmx2 which is from i read on the MD is just making htmx more extensible 😉
  • e
    Also, this message hit the nail on the head for me
  • e
    Yeah! I'm excited about htmx2. BUT since it sounds like that's not coming for quite some time, I'd really hate to see lack of ESM support until then. ESM is part of ES6 which has been native in browsers since 2015
  • a
    I don’t understand why one file means you’ve got to keep it all in your brain. If you know what you’re looking for, I find cmd+f in one file much easier. If you don’t know what you’re looking for, I don’t see how splitting into lots of different files helps. One file to work through and include is a far simpler approach.
  • e
    You're right. It's not quite due to the file splitting. It's about Single Responsibility Principle. Each function or "chunk" should do its own thing. But separate files enforce that separation more than one file
  • e
    I think htmx does a better job of this than other libraries I've seen, but almost all one-file libraries I've seen that are this large have those lines blurred
  • e
    One function requires variables or functionality from another function, and soon you've got a spaghetti code mess
  • a
    Grug like juicer, juicer simpler than Juicero. Juicero add little value and be gone like wind.
  • e
    Sounds like this ought to be fixed.. but is there a way without the whole build process?
  • e
    I will also add: the htmx JS api is really buggy. I dug in and used it a bunch last year, and 😬 better JS testing would help with that. We could probably get by with current testing tools though to do the same thing
  • e
    Yeah. Someone has to figure out the ESM magic syntax to wrap around the source code. I think I know what it is and I could do that. But what's happening is basically that compiled source code gets wrapped around the real source code.
  • e
    With what I've set up, all Rollup is doing is adding that bit of wrapper, and "compiling" things correctly into separate files for ESM, UMD, AMD and CommonJS, with minified variants and gzipped variants for those interested. That is a lot to manage manually, so a build system deals with it instead
  • e
    All the source code can stay one huge file. I haven't changed any of that. So that discussion is separate
  • e
    I just wanted to point out that it enables things like that to happen, if this community so chooses. Right now without a build tool, it's impossible
1...103110321033...1146Latest