HTMX doesn't work if included with `async`

[MonstraG]

Basically, #142, except again. And there are no errors in the console.

[aburd]

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script

async- For classic scripts, if the async attribute is present, then the classic script will be fetched in parallel to parsing and evaluated as soon as it is available.

defer
This Boolean attribute is set to indicate to a browser that the script is meant to be executed after the document has been parsed, but before firing DOMContentLoaded.

I could see the async tag being problematic for htmx, because it needs to attach event handlers to all the elements, but if it’s doing it in parallel to document parsing, couldn’t this cause a race condition? Maybe what you want is the defer attribute.

[MonstraG]

I would want async to get the fastest page load. I would also expect htmx to wait for DOMContentLoaded already.

[aburd]

Well given your issue, I’m not sure but maybe using the defer attribute would solve your problem and do it even faster since it is “executed after the document has been parsed, but before firing DOMContentLoaded”.

But you’re right, in the absence of documentation it should just work. It should be fixed to work regardless of those attributes, or at least warn you in the console that the script is not meant to work with async if it is by design.

[MonstraG]

I can confirm that defer doesn't break it

[MonstraG]

Just tried on 2.0.0-beta1, same problem.

[f-liva]

Me too

[morganwahl]

I'm also running into this. Script tag without async or defer, script tag with defer and even loading it as an ESM all work fine. Loading it specifically with async as a classic script (not an ESM) results in none of HTMX's event listeners being added.

Note that this behavior is not consistent, since it will be dependent on how long it took the browser to fetch HTMX over the network. For me, doing a hard-refresh of a page hits this problem about half the time.

The problem seems to be in the ready function:

        //====================================================================
        // Initialization
        //====================================================================
        var isReady = false
        getDocument().addEventListener('DOMContentLoaded', function() {
            isReady = true
        })

        /**
         * Execute a function now if DOMContentLoaded has fired, otherwise listen for it.
         *
         * This function uses isReady because there is no realiable way to ask the browswer whether
         * the DOMContentLoaded event has already been fired; there's a gap between DOMContentLoaded
         * firing and readystate=complete.
         */
        function ready(fn) {
            // Checking readyState here is a failsafe in case the htmx script tag entered the DOM by
            // some means other than the initial page load.
            if (isReady || getDocument().readyState === 'complete') {
                fn();
            } else {
                getDocument().addEventListener('DOMContentLoaded', fn);
            }
        }

By sticking in breakpoints, I can see about half the time the condition is true, and HTMX works correctly in those cases. The other half of the time, it falls into the else clause and add the listener for 'DOMContentLoaded', but the handler never runs. I assume this is because 'DOMContentLoaded' fired before the listener was added. (The isReady variable is always false in the runs I have looked at.)

[morganwahl]

This seems to fail because an async script executes anytime after its done downloading, and there's a time gap where readyState is not complete, but DOMContentLoaded has already fired.

I think just needs to be

if (getDocument().readyState === "loading") {
  // Loading hasn't finished yet
  getDocument().addEventListener("DOMContentLoaded", fn);
} else {
  // `DOMContentLoaded` has already fired
  fn();
}

(Adapted from the example in the MDN docs: https://developer.mozilla.org/en-US/docs/Web/API/Document/DOMContentLoaded_event )

[morganwahl]

Fix PR'd here: #3398