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:
Rish TandonWith this change, we are taking a major step in #MicrosoftTeams Teams architecture. We are moving away from Electron to Edge Webview2. Teams will continue to remain a hybrid app but now it will be powered by #MicrosoftEdge. Also Angular is gone. We are now 100% on reactjs15:33 PM - 24 Jun 2021
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-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.exeprocess. 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.exeprocesses. 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.