As a next step (could be next PR), this could be replaced by promise/Task instead of Begin/End pattern.

Yes that would be good. We did the begin/end thing because it predated support for Task in the WebAssembly runtime's interop mechanism.

I don't know if this is perf critical but if so, it could be re-implemented as passing int[] Ids, string[] assemblies etc.

Good point. However it's only a one-time thing that happens during startup, so my guess is that we wouldn't be able to observe any difference.

In next PR we could try re-invent how the goal of invokeJSFromDotNet could be achieved otherwise.
To ged rid of things like BINDING.js_string_to_mono_string

Is the exception type name still exposed on the JS side somehow? Seems like that would be valuable for debugging.

Unfortunately, it looks like that information is lost now. The JavaScript errors that get created from exceptions thrown in [JSExport] methods have a message property equivalent to the C# exception's Message property, which excludes the exception type and stack trace. We could fix this by catching exceptions on the .NET side and wrapping them in a new Exception to simulate the old behavior, like:

try
{
    return DotNetDispatcher.Invoke(Instance, callInfo, argsJson);
}
catch (Exception ex)
{
    throw new Exception(ex.ToString(), ex);
}

Or I wonder if there's a way to address this on the runtime side, perhaps by updating ManagedError to include information about the type of exception that got thrown?

They are just a proxy and could also cross the boundary back to managed.
Collecting stack trace is very very expensive and we do it when you call toString() on it (I think).

Collecting stack trace is very very expensive and we do it when you call toString() on it (I think)

@pavelsavara Does that mean we could change the JS-side code to call throw new Error(exceptionProxy.toString()), and thereby get back the information we had before? Or is there some other mechanism you'd recommend?

no, please don't do that. It would be slow as you would pay the cost of stack trace creation also for exceptions which would be caught and handled silently.

We override the implementation of ManagedError.stack property to provide it on demand.

https://github.com/dotnet/runtime/blob/8d938ec1d18de3211040bccca1ea73f2574dc87a/src/mono/wasm/runtime/marshal.ts#L339

I think error.toString() and console.log(error) would both include stack property (at least on chrome). I'm open to suggestions how to improve it.

Proxy in the other direction is also lazy

https://github.com/dotnet/runtime/blob/8d938ec1d18de3211040bccca1ea73f2574dc87a/src/libraries/System.Runtime.InteropServices.JavaScript/src/System/Runtime/InteropServices/JavaScript/JSException.cs#L40