[browser] reinvent internal JS interfaces between modules

[pavelsavara]

@SingleAccretion said

I would like to see these small helpers implemented as Emscripten JS libraries / EM_JS for linking and layering reasons

I strongly prefer TS with ES6 style over Emscripten JS libraries C like style, which break closures and have other sins.

I need to re-invent the way how our JS/ES6 modules (privately) interface each other. So that we can allow emscripten linker to play better with it. And at the same time we could conveniently share utility code. (logging, asserts, memory access, etc ...)

There is also question of how many published .js file we have. For now I would like to stick to current published assets so that we don't break Blazor and others.

Another aspect is parallel download/compilation/startup of various parts. I'm not friend of single file on web.
I believe that we have has best cold download start perf as is.

Another consideration is rollup/webpack bundlers, for people who don't share my view.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

[SingleAccretion]

I need to re-invent the way how our JS/ES6 modules (privately) interface each other. So that we can allow emscripten linker to play better with it. And at the same time we could conveniently share utility code. (logging, asserts, memory access, etc ...)

Yes, that would be ideal. Note I am excluding the "host/loader" code from this discussion (that code is already layered above the runtime and can't be trimmed anyway). So this is only about JS which we call from the app and which may call back into the app to use some services.

Here is my north star for the experience:

1. Possible to use a single emcc invocation to link the whole app.
2. The linker is able to drop JS which isn't used.
3. The linker is able to drop native/app code which is used by these unused JS references.

Emscripten's JS libraries achieve this via the __deps annotation and #STUB libraries support in wasm-ld.

[pavelsavara]

I think I have acceptable compromise.
PoC buried here

// example of common infrastructure that lives on global closure of TS codebase
const Logger = {
    info: function (msg) {
        console.log(msg);
    },
    log_warn: function (msg) {
        console.warn(msg);
    },
    error: function (msg) {
        console.error(msg);
    }
};

// another example of common infrastructure that lives on global closure of TS codebase
const dotnetInternals = {
    //.. our internal interfaces
}

// example of C trimmable utility function
function trimmableBar(bufferPtr, bufferLength) {
}

// example of C trimmable PInvoke/ICall 
function SystemJS_RandomBytes(bufferPtr, bufferLength) {
    Logger.log_warn("demo of using Logger object from function that was moved by emscripten from it's global closure to Module object closure");
    // foo() is not part of emscripten trimming/dependency graph
    dotnetInternals.foo();
    // this would be protected by manual `SystemJS_RandomBytes__deps` annotation
    trimmableBar();
    return -1;
}

///////////////////////// above ^^^ was brought into this JS by the TS compiler
///////////////////////// below vvv is emscripten lib factory

const commonInfra = {
    dotnetInternals,
    Logger,
    // few other common objects that arrived from dotnet.js and dotnet.runtime.js can be added here
};

const trimmableDotnetExports = {
    SystemJS_RandomBytes,
    // This needs to be done by hands and 
    "SystemJS_RandomBytes__deps": ["trimmableBar"],
    // I don't believe we would have too many such functions, for sanity reasons
    trimmableBar,
};

function dotnetLibFactory() {
    // Symbols that would be protected from emscripten linker
    const commonInfraTransformed = {};
    const moduleContextDeps = [];
    for (const exportName of Reflect.ownKeys(commonInfra)) {
        if (!Object.prototype.hasOwnProperty.call(commonInfra, exportName)) {
            continue;
        }
        const emName = "$" + exportName.toString();
        commonInfraTransformed[emName] = commonInfra[exportName];
        moduleContextDeps.push(emName);
    }
    const DotnetLib = {
        $DOTNET: {
            dotnetLibInitialize: async (dotnetInternals) => {
                Object.assign(dotnetInternals, internals);
            }
        },
        "$DOTNET__postset": "DOTNET.dotnetLibInitialize(Module.dotnetInternals)",
        "$DOTNET__deps": moduleContextDeps,
        ...commonInfraTransformed,
        ...trimmableDotnetExports
    };
    autoAddDeps(DotnetLib, "$DOTNET");
    addToLibrary(DotnetLib);
}
dotnetLibFactory();

For completeness sake: if we wanted to let emscripten dependency trimmer to fully own our JS:

• there is rollup plugin which probably does the __deps annotations.
• emscripten project should adopt some JS AST parser like babel and stop using Function.toString() !

But I think we don't want that.
Our rollup could do better job of minification/name mangling in the separate .js files.
Moving the boundary of what is in dotnet.runtime.js not trimmable vs dotnet.native.js trimmable is possible on function by function basis. I don't believe we would move many such JS functions.

[dotnet-policy-service]

Tagging subscribers to 'size-reduction': @eerhardt, @SamMonoRT, @marek-safar
See info in area-owners.md if you want to be subscribed.

[SingleAccretion]

I think this is a good compromise.

I don't believe we would move many such JS functions.

I agree. In fact I think it would be desirable to also keep the back-channel of the dependencies from this code to the "runtime API" minimal. It would work towards goals 1 and 3.