Electron to WebView2 – What does it really mean for the Teams desktop client, and for a Client SDK?

Last week was a busy one for news, including the announcement that Windows 11 will include some or all of Microsoft Teams:

However, what was almost more interesting was the Twitter thread that Rish Tandon started, as first reported (I think) by Brad Sams:

With 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 reactjs

— Rish Tandon (@rishmsft) June 24, 2021

In the thread, Rish says several things about Teams moving from Electron to WebView2, and to a 100% Reactjs model. This has been well reported elsewhere and I don’t want to copy that. Instead, I wanted to think about what I think this really means for the Microsoft Teams Desktop client.

WebView2 != Electron: Teams will be a “proper” Windows application

I think this is an important distinction to make. Electron is a wrapper application technology, to enable you to build something that is cross-platform but still a desktop application, and it is a host to a web application. It provides an abstraction to the desktop and means that all the “real” work of the application has to happen in JavaScript, with Electron being the “gateway” through which applications interact with the underlying desktop (for instance to show a popup or respond to a device being plugged in).

WebView2 isn’t that.

WebView2 is a control, like a text box, a button or a label is a control. It’s quite a sophisticated control but it’s still just a control. It is a control that renders webpage experiences, using the Chromium rendering engine built into Edge.

The reason it’s called WebView2 is that it replaces the WebView control, which in turn replaced the WebBrowser control, which old-school Win32 developers may remember. WebView used the original Edge (Trident) rendering engine and was a Windows10 only control. WebView2 uses the newer Edge rendering engine and is supported across many more Windows platforms.

It’s a powerful enough web-rendering control to host the Teams application, it would appear, and it’s using this control that the recently demoed application shown in Windows 11 is being built. WebView2 is a control that is part of an application, whereas Electron is the application (sort of). (if you disagree with this last bit, that’s OK, I’m just trying to broadly explain the difference)

That means that in order to use it, the Microsoft Teams team have needed to build a new Teams desktop application, and then used the WebView2 control to “host” parts of the Teams experience. A proper new application from the ground up: a File > New Project for someone in Engineering.

The distinction is subtle but important. With this new approach, the Teams developers are no longer required to use an intermediary to talk to the underlying system – because they are running a native application they can directly interact with devices, screens, the file system. So, things like support for multiple windows and spanning multiple displays become much easier. On the other side, they don’t get anything for free anymore: so all the hooks and events that Electron was providing need to be written in.

It’s not a rewrite of Microsoft Teams – remember that all the real logic and UI is in web components and that remains (expect that that has also all been re-written to use React instead of Angular, but that’s a different story!) the case. In a way this is “just” the housing .. but it’s also a big deal because it’ll make some things easier and some things harder.

Does this change a lot or a little?

The most simple implementation of this approach is to create a new application, add a single WebView2 control that fills the canvas, host Teams in it, and write an abstraction layer to deal with communication to the desktop.

However, I predict that the power and ease of being able to write client-side code that operates alongside the WebView2 control will prove too much of a lure and we will see innovations in the desktop client experience that aren’t possible elsewhere.

We should also see some performance improvements associated with removing a generic abstraction (Electron) and replacing it with something custom-built.

So, what about Mac & Linux?

One of the reasons given for using Electron to build the Teams application was that all clients would be on the same evergreen version and that this would limit the number of supported applications and enable faster development progress.

WebView2 is a Windows control, for .NET, Win32 or WinUI applications. It’s supported on lots of Windows versions, but nowhere else.

That means that (I think) one of three things will need to happen:

• Mac & Linux users will have to use the web-based version of Teams only
• WebView2 will start supporting Mac & Linux
• there will be 2 supported desktop clients for Teams: an Electron-based one and a WebView2-based one

In a GitHub issue comment, Nicolas Champagne-Williamson, Principal Software Engineering Manager on the WebView2 team confirmed that the WebView2 team were working on both Mac and Linux support, were prioritising Mac support over Linux support, and didn’t expect Linux support to come until at least 2022. This might be enough for Teams to justify waiting for WebView2 to be supported everywhere and is (I think) the most likely option.

It would be technically possible to support both Electron and WebView2 to ensure all clients can access Teams via an application, but it would involve creating an abstraction layer above WebView2 so that it resembled Electron (or the other way around but because all the code works with Electron already the former way makes more sense) so that the Teams business logic code could run on both platforms. However, doing this removes all the benefits and advantages of moving to a hybrid model using WebView2 because it doesn’t offer the flexibility and means developers are still constrained using the Electron abstraction even when they’re not using Electron. It’s the worst of all worlds but would mean both client types could be supported.

In his tweet, Rish spoke about this being a 6-month “moonshot” project. However, I think now that it is here it’s going to stay. I think that this WebView2-based version will evolve to become the version of Teams for desktop clients, replacing the Electron-based one.

What about Virtualized Desktop Infrastructure (VDI)?

In general, because WebView2 is “just” a control and is being used within a Windows application, using it in a VDI should be fine. In practice though, there might be some vendor-specific restrictions or configurations needed.

When it renders in an application, WebView2 will start its own process (similar to how Chromium Edge starts a new process for each browser tab) called (I think): msedgewebview2.exe (although this name might be different for Teams when it launches, we’ll have to wait and see).

There have been some reports of problems with Citrix hooks and the WebView2 process which prevents it from starting. The workaround is to disable hooks for that process as described in Citrix CTX107825.

What about Client SDKs?

Since Teams launched, developers have been asking about a desktop client SDK. It’s a highly upvoted entry on the Microsoft Teams User Voice. The latest update is from July 2020 with a comment from the Engineering Team that “the team is reviewing possibilities in this space but does not yet have a date on this”.

It’s interesting to think through why such a popular item, that would promote more applications that use Teams, isn’t being prioritised.

One reason could be technical – that it’s hard or unfeasible to create an SDK that interacts nicely with the Teams application via Electron. Electron does support Inter-Process Communication (IPC) with external applications via a node module, but the reality might be that it is overly complicated or latent to be useful for real-time communications.

Another reason might be Microsoft would prefer all Teams-based applications to live inside of Teams, using the existing app model. These apps also have the advantage that they work on mobile devices as well. Having a class of Teams-based applications that only work on desktop machines (and likely only Windows-based desktop machines) might be seen as diluting the integration story, even though I think it would be useful in a number of scenarios.

We’ve seen some moves that seem to recognise that different devices behave differently from each other and sometimes need their own specific solutions: for instance SDK support for GPS and QR code reading for apps that are designed to be used only on mobile devices. The argument only gets stronger if we see the WebView2-based desktop application gain desktop-specific features (as I think it will).

So, a move to a purpose-built Windows application might make a client SDK more likely if it becomes technically easier to achieve, but it’s not a given.

So, is Electron dead?

Not yet. Don’t forget there are other high-profile and complex apps that use Electron, such as Visual Studio Code, Slack, Twitch etc. I don’t know whether the engineering teams for these products are planning on moving away from Electron to something more native or not.

Even if all the Microsoft-based products move away from Electron, I don’t see Microsoft ever “killing” it, at least not in the short term. They picked up ownership of the technology as part of the GitHub acquisition and so I think they will leave it to continue as it is. [Although, a fun fiction work might imagine a more dystopian world in which a Machiavellian Microsoft attempted to pull the Electron rug from under Slack…]

Electron is still a great solution for many applications and has its place for cross-platform development. In fact, it’s a lot more of a cross-platform solution than anything built with WebView2 is today! However, it seems that Electron has an upper limit for application complexity, as borne out by complaints of Teams’ high use of system resources, and it was time for a change.

Conclusion

The “new” Teams application, when it comes, is going to feel both different, and not at all different, both at the same time. The way it loads and interacts with the rest of your computer might change, but the UI and functionality will remain unchanged from the web experience (unless of course a new UI for Windows 11 is ushered into the Teams experience…we’ll have to wait and see on that).

More exciting I think will be how making a break from Electron will enable the Teams engineering team to do things they couldn’t previously and improve performance and experiences in areas that were under Electron’s control and couldn’t be changed.

Electron remain a fabulous way of building cross-platform applications, but recently it started to feel like Teams had outgrown it. Re-writing to remove Electron is (I think) the correct choice and will be the runway for another period of exciting product innovation from the Teams team. I’m looking forward to seeing what they do next!

Written by Tom Morgan

Tom is a Microsoft Teams Platform developer and Microsoft MVP who has been blogging for over a decade. Find out more.

---

Buy the book: Building and Developing Apps & Bots for Microsoft Teams. Now available to purchase online with free updates.

Related posts:

Under the Hood of the Microsoft Teams Desktop Application Weekly Update 25 June 2021 – Talking Microsoft Teams in Windows 11, Electron, WebView2 and more! You can now pop-out apps and tabs into their own window in Microsoft Teams Why Microsoft Teams isn’t in the Windows Store (yet) #LyncDevQ: Desktop & Application Sharing in UCWA