So it’s a lot of explaining to everybody what’s going on, why we have to make the changes that we are making, and so far everybody’s been on board, which is great, and hopefully it will continue to be that way. But the goal of the work is – right now, as I said, there’s an imperative JavaScript API; basically, you have to tell JavaScript to build this WebAssembly module for you, and you have to go step by step. You have to tell it “Okay, fetch the file first, and then take the imports that I need to pass into the module and initialize those. Then pass those in, instantiate the module using those imports”, and then finally you can actually use whatever export from that module you wanted to whatever function or value you wanted to from that module.

So what we wanna do is move it to a declarative API, like what you have with ES modules, where you can just say “import foo from bar.js”, and it just gives it to you; it does all of the other work for you. The tricky parts there are figuring out where exactly, because the ES module spec breaks up the process into three different phases. First you construct the module graph, you download all of the module files that you need, and you parse them into module records so that you know what’s going on in this file… But this process has to happen in kind of an iterative way, because you first get the first file, then you have to parse that to figure out what modules it depends on, and then you go and fetch those from the web, then you parse them… So you have to keep going down and down and down, fetching and parsing and fetching and parsing through this whole module graph.

Then the second phase, once you have your whole module graph figured out, the second phase is linking them together, so finding places in memory for exports and then connecting both the export statement and the import statement to that same place in memory when they are referring to the same thing. Then you actually fill in the values that will be in those variables.

The second step, that linking step is called instantiation, and the third step is called evaluation. That’s where you’re actually evaluating the code that’s outside the functions in the module. So figuring out how to make WebAssembly fit with this, but there are certain ways in which it can’t quite, so figuring out what to do in those cases - that is a little bit tricky, but so far we have some good plans in place for how to make that work.