Some thoughts on the new Microsoft Teams 2.0 architecture (WebView2/ReactJS)

#windows #desktop #webview2

Updated on 2021/07/24, Electron.js has published a great article on comparing Electron to WebView2. It's reassuring to know an improved form of IPC (between the WV2 host and JavaScript) is coming, in form of CBOR.

If you've been following the news from the remote collaboration software industry, you've probably heard that Microsoft Teams have migrated from Electron/Angular to WebView2/React for the upcoming version 2.0, which is also a part of Windows 11. A tweet by Rish Tandon, the CVP of engineering for Teams:

As a software engineer who is involved in both web conferencing tools and Windows Desktop app development, I've been curious about this move. Particularly, whether or not they may also be utilizing .NET on the Desktop now, along with WebView2 (and JavaScript interop via WebView2 IPC).

I thought, as long as they don't use Electron anymore and are being more Windows-centric now, they might as well be leveraging the power of .NET to do some media pre-processing on the client side. Similar to what Zoom is doing with WebAssembly, but potentially, in a more efficient way with some compiled .NET code?

I didn't have a chance to install any insider builds of Windows 11 yet, but with a little help from a fellow redditor, I managed to get a sneak peek into Teams 2.0 internals, using SysInternals' excellent ListDLLs tool.

Take these thoughts with a grain of salt, currently they are just mine (somewhat educated) guesses/speculations.

Teams 2.0 appears to be a Windows Store package, it's installed under "C:\Program Files\WindowsApps". Presumably, it can be listed from PowerShell with Get-AppxPackage -allusers *teams*.
I could not detect any traces of the .NET runtime DLLs in the memory space of the new Teams process. It does look like they use some Azure C++ SDK DLLs (azure-core.dll, azure-storage-blobs.dll, azure-storage-common.dll), a set of Boost C++ libraries (boost_*.dll) and SQLite (sqlite3.dll, presumably for storing the app's local state).
They use WebView2 (aka WV2) in shared "evergreen" mode ("C:\Program Files (x86)\Microsoft\EdgeWebView\Application\91.0.864.70\EBWebView\x64\EmbeddedBrowserWebView.dll").
It's now a single-instance msteams.exe process. This may look as a departure from the multi-process architecture of Electron, but of course, WV2 still runs a bunch of its own msedgewebview2.exe processes. No surprise here, as it's still a customized version of Chromium under the hood.

Is this pool of WV2 Chromium processes shared across other WV2 instances? I don't think so, but let's ask the WV2 team directly.
It's hard to tell if they just use pure WebRTC API inside WebView2, or do some custom video processing on the client, but I haven't spotted any FFmpeg-like DLLs or anything that might look like custom codecs (the Electron-based version of Teams does bundle ffmpeg.dll, although it might just be a part of Electron runtime).

Overall, Teams 2 appears to be a basic WinUI 3 Desktop C++ App, not using WinForms, WPF or any other .NET libraries, with all-HTML UI made with React and hosted in WV2. Except, perhaps, for the UI pieces like top-level menus bar, status bar and Windows native notifications.

I actually haven't seen the full UI yet, but such approach would make sense if they still aim to share the UI codebase between the Desktop app and the browser web app (at https://teams.microsoft.com). The HTML UI is most likely built with Fluent UI React, in line with the rest of Office 365.

One issue I've myself dealt with while hosting WV2 in a WPF app was with accelerator keys of native peer WPF controls and menus, when the focus is inside WV2. It'll be interesting to see if a Win UI 3 host app is also affected by this, how Teams 2.0 deals with this.

That's the whole picture I've got for now. I'd appreciate if someone who might know more could jump in and correct me. I'll be updating this post as I learn anything new about Teams 2.0 architecture.