feature-request/question: Possibility of a version without top-level-await?

[FlorianLeutloff]

Hello,

I was wondering if a browser-version was possible, which did not rely on top-level-await to be imported.

I am trying to use this package inside of an existing angular 19 project,.
It is possible to allow for top-level-await in angular by stripping out zone.js and ditching the polyfills file, but the possibility of new bugs stemming from this change is worrisome in a large project.

I have seen other wasm-projects which are importable without relying on top-level-await like 7z-wasm

I cannot make a judgement on the merits of using top-level-await and exporting individual classes and methods as opposed to exporting a Promise from which you then access all classes and methods available. I would be happy for information on the pros, cons and barriers of both approaches.

my rough proposal:
The normal libxml2 import already imports the Module/moduleLoader Promise from libxml2raw.mjs and then awaits it at the top level.
The idea would be to have an export named libxml2, which is a Promise and from the result of the Promies you then access all classes and methods one requires. This would be roughly similar at a glance to what is being done in 7z-wasm.

[jameslan]

I’m not very familiar with Angular, but top-level-await is a runtime feature that has been supported by all major browsers for quite some time.

The main reasons for using top-level await are:

• The WASM loading API is asynchronous, so we need an async approach.
• The rollout of WASM support and top-level await happened around the same time, so a runtime that lacks top-level await likely also lacks WASM support.
• Using top-level await avoids having to wrap every function’s return value in a Promise.

The issue with a design like 7z-asm is that each time you call and await moduleLoader, it creates a new WASM instance. While an app using libxml2-wasm directly might be fine, problems can arise if multiple libraries use this pattern, as it leads to multiple isolated WASM instances without shared data, causing integration issues.

Which module system is your Angular app using?

• ES Modules have built-in support for top-level await since their imports are already asynchronous.
• CommonJS cannot require an ES module directly. Instead, it must dynamically import it, as shown in the documentation. This effectively allows the top-level await to run, and actually has a similar grammar to 7z-wasm.

[FlorianLeutloff]

Thank you for your thorough answer,

there is no longer a need for the feature-request. I will be trying to make libxml2-wasm work with the existing code through a web-worker with its own build-process or a later switch to zoneless-angular. Instead of trying to change libxml2-wasm itself.

"I’m not very familiar with Angular, but top-level-await is a runtime feature that has been supported by all major browsers for quite some time."
That is true, but from my research, the angular framework has utilised zone.js in the past to manage the different asynchronous behaviours, with zone.js not being able to deal with top-level-await. Angular versions from version 17 have started moving away from zone.js while offering experimental alternatives. With version 20 offering a developed non-experimental approach and documentation on zoneless angular.