https://htmx.org logo
Join Discord
Powered by
# htmx-general
  • m
    I don't know anything about roll up
  • m
    i have to admit i get angry when I try to learn about packaging/modules in javascript, a disaster even by javascript standards
  • g
    I don't see how a single-file library with no dependencies would need a bundler
  • g
    Just to convert modules -> modules+UMD?
  • m
    ESM I guess
  • m
    but this is my feeling too
  • m
    I really want to avoid a build system if at all possible
  • g
    there has to be a simpler way to do this
  • m
    and, if there isn't, obstinance is always my go to option
  • e
    I’ve just realised that your package.json has 50 lines and your lock file is nearly 8k lines
  • e
    It’s really impressive that all of this somehow works
  • m
    @mysterious-toddler-20573 moving the build to rollup, or maybe better vite, does make things like tree shaking and lazy imports possible. Nice part about vite is for your needs rollup with extra options and dead simple dev environment
  • m
    i like simple, i also like only paying for what i use. in htmx case its not a big deal but if you have to bundle other js/ts side stuff it would be nice if it played well with others.
  • r
    It's this months attempt to marry HTMX to a more complex build system. Just busywork making htmx conform to a specific build tool flavor of the month, while not thinking of long term technical debt or interoperability.
  • r
    devs being devs.
  • r
    Simplicity is a priceless asset that many teams try desperately to get back. htmx has actually been able to hold onto it for a long time. And does tree shaking really make any sense in a library this small? All that to "shake" away a few kb.
  • r
    Its pretty difficult to break copy+paste and it works with everything.
  • r
    mostly auxillary stuff like the test suite- you don't need it to modify htmx.
  • a
    I am changing the target in beforeSwap based on xhr success or error . I have modal, toast initialization based on target in afterSwap callback. The changed target is not available in evt.details.target in afterSwap
  • h
    That's just the reality of how a lot of devs use javascript today. Everyone knows it's a huge mess, but you might as well shout at the sea. Making htmx play nicely with ESM will definitely help drive adoption. If the tooling gets out of date, well, just update it. Nothing is for ever.
  • r
    What ever happens when your own team moves on from the flavor of the month build system, and htmx still uses it? 😛 It's short-term expedience for a limited set of developers to make things slightly easier for them specifically without any concern to the ginormous list of "stacks" used by everyone else.
  • r
    And monthly reminder- since this comes up every month literally - the reason htmx.js doesn't switch to ESM because of CORS. Requiring the installation of a web server to use htmx is not great for adoption. The moment browsers fix this, I'm sure htmx will switch.
  • h
    Devs could use whatever ES module compatible build system they like to import htmx as a dependency. Or just link to the like now. How htmx is put together from then on is a separate discussion, really. This is just about making it easy for end users to consume.
  • e
    The question is how many are there users like that? Because if most of the htmx audience is just downloading htmx.js and call it a day, then maybe it’s not worth it for the time being
  • s
    🙋‍♂️ I pull in htmx (and hyperscript) as part of the build system I have in every project. Every project I work on uses SCSS, and there are always third-party JS libs or custom code. I find it much easier and more efficient to bundle them all up as 
    main.js
    and 
    main.css
    and their corresponding 
    main.min.*
    files than loading having half a dozen separate JS files. If I have to build SCSS anyway, I may as well do JS at the same time.
  • s
    Copy code
    import 'htmx.org/dist/htmx.js';
import _hyperscript from 'hyperscript.org/src/_hyperscript.js';
const htmx = window.htmx;
window._hyperscript = _hyperscript.browserInit();
    This is what I use to make it work; i's not a huge problem. But I gather (from messages on here and over on GitHub) there's a "more right" way of "building" htmx so that it follows the standards that build systems in general will use - whether that's webpack, vite, esbuild, flavour-of-next-month - as well as satisfying 
    <script>
    tag usage.
  • a
    Anyone?
  • r
    I'm not sure, if it's a bug or intended behavior, but the implementation indeed does not take target change into account between those those events. https://github.com/bigskysoftware/htmx/blob/master/src/htmx.js#L3087 - this line breaks the referential link between event data objects. I suppose, this could be submitted as an issue?
  • m
    Maybe I've swam too long in the js/TS ocean but vite does feel like it's "won". It's piggy backing on esm and roll-up in smart ways so it's dead easy. Vitest is fast. Having multi-target builds just work is wonderful. I guess I'm saying that htmx has to be the last JavaScript you have to run to make HTML restful, might as well make that part easier to deal with
  • s
    What problem are we solving with a bundler? Tree shaking and lazy imports are not a problem, they are a solution to problems that we don’t have.
1...102610271028...1146Latest