Consider supporting IJSInProcessRuntime in Blazor Desktop

[Eilon]

The IJSInProcessRuntime service exists to offer improved performance and behavior when Blazor code (e.g. app code) is running with a "locally available" JS runtime, such as in Blazor WebAssembly scenarios. This should also presumably be the case in Blazor Desktop scenarios, where there is also a locally available JS runtime in the WebView.

I'm not sure if it would have any real perf improvements or implications because everything is running locally anyway (maybe less marshalling/serialization?), but it could make it easier to have Blazor components work in Blazor Desktop if they require support for IJSInProcessRuntime.

Example from SkiaSharp: mono/SkiaSharp#1834

@SteveSandersonMS / @javiercn - thoughts on this? Any reason we couldn't or shouldn't?

[javiercn]

@Eilon isn't the WebWindow interop channel async? That's the main limitation for the InProcess one. If we can't guarantee that across implementations, we should avoid it, or just implement it where supported.

[Eilon]

Ah, so we'd need to ensure that on every platform we have a guaranteed sync way to invoke JS? Supposing that's possible, should/would we do it? (I'd have to check what each platform has, but your suspicion might be right.)

[javiercn]

Ah, so we'd need to ensure that on every platform we have a guaranteed sync way to invoke JS? Supposing that's possible, should/would we do it?

Don't necessarily see why not, the main problem could be in the future if there was an async only platform added to the mix. We might want to ensure that the experience doesn't change across supported desktop platforms and the experience becomes inconsistent.

[mattleibow]

What platforms are async-only? Maybe we should support in-process and maybe throw on platforms that do not support it?

In the case of SkiaSharp, I am setting up a render loop and all the overhead an async-ness for a drawing event is not super great. I can understand that maybe in the future this needs to support async, but if it is possible to have a sync way, then that is better.

And, regardless, if there are some platforms that support in-process, it will still be better to use that where it is supported, and then fall back to async on the others.

[SteveSandersonMS]

As far as I'm aware, WebView2 only supports async script invocation. Here's the API: https://docs.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2.executescriptasync?view=webview2-dotnet-1.0.992.28. There isn't a sync equivalent that I know of. It makes sense because of Chromium being a multiprocess system - I don't think that the browser's JS engine is in the same process as the host application (I could be wrong about that).

So if we really wanted synchronous script invocation, we should probably start by talking with the WebView2 developers and ask for such a feature there, if it's even possible given the architecture. That would cover most of our scenarios, though mobile and macOS would still be different, and we'd need MAUI to expose a common synchronous JS call mechanism to cover all of those. I don't know whether that's possible either - for example all the overloads of WKWebView's APIs for invoking script appear to be async.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[daniel-p-tech]

I inquired about this in a separate ticket - see question no. 4 that has yet to be answered by a Microsoft engineer.

dotnet/maui#2861

I also did not get an answer if calling exclusively StateHasChanged throughout my WASM application is going to work when porting the app to .NET MAUI (both desktop and mobile).

Thank you,

[javiercn]

but it could make it easier to have Blazor components work in Blazor Desktop if they require support for IJSInProcessRuntime

Components should not require support for IJSInProcessRuntime we should be very clear that this is always an opt-in optimization.

[javiercn]

@Eilon @SteveSandersonMS I propose we don't even consider this, since as a general rule, we can't guarantee the availability of sync interop across desktop platform implementations (which AFAIK none supports today) and if we were to implement it on some of them and not others, it would produce an inconsistent experience for Blazor Desktop developers. So I think the right call here is to resort to the common denominator for all desktop platforms.

IMO there can be two outcomes:

• Providing sync interop doesn't yield significant perf benefits, in which case, there's not much benefit on enabling it.
• Providing sync interop yields significant perf benefits, in which case, we end up with an inconsistent platform that offers different perf characteristics across platforms. I don't think we want to promote apps/frameworks that work well in one platform and don't in another.

[Eilon]

@javiercn - all good points, thank you.

I think that either way on these, there is no way to implement this right now anyway, and I don't think this is important enough right now to try to push all (or even any) of the browser vendors to support this, plus the relevant interop APIs. As such, I think there is little value in keeping this issue open because it doesn't have any reasonable path forward.