Under the Hood of the Microsoft Teams Desktop Application
I’ve been asked a couple of times about the Microsoft Teams desktop application and been in a couple of discussions with people about it.
The general consensus is that “something is different” with it. Not huge, just…weird. Whether that’s strange behaviour with logging in or just something picked up in the look and feel whilst using it, it deserved some attention. Here’s what I found:
It’s just a webpage!
This is the biggest surprise, and probably the number 1 reason for the application feeling different. The “application” is actually just a thin wrapper around the Microsoft Teams website. This is done using Electron.
This is pretty interesting. Rather than try and maintain a Windows client, a Mac client, a Linux client and a web presence, instead there’s just a single set of HTML and JS files which are then wrapped separately depending on where you are using them. 1 codebase, 1 place to fix bugs, 1 place to add new features. And, one set of developer skills so you don’t need different teams for web and desktop. However, I think (though I could be wrong) that this is the first time this approach has been used for the primary application of a core Microsoft product. As I mentioned before Visual Studio Code was built this way but the primary application for development experiences is still the Visual Studio IDE (a big C++ Win32 app).
Microsoft building their newest, hottest collaboration strategy around an open-source, web-based GitHub project, not a Win32 app? Welcome to 2017.
It’s not quite as simple as just calling https://teams.microsoft.com when the application starts however. There is functionality to the application and buttons that don’t exist on the webpage. Plus, by packaging all the assets (all the images, the JS etc etc) that the application needs during install, running and using the application will be fast and won’t require those things to be downloaded each time.
Every time you distribute an application you need to think about how users will update that application when things change. Back in the old days (the ’90s) when software came on disks, the update strategy was to send them some more disks, so you would release a new version of your software maybe once a year because updating was hard and expensive.
Now of course we have the Internet so we don’t have the disks. That’s meant that software can be updated almost continuously, many times a day in order to fix bugs and add features. However, to do this you need a mechanism to update your application. For instance the mechanism that Windows uses is Windows Update.
Did the Microsoft Teams team use Windows Update as their update mechanism, similar to Skype for Business and the rest of the Office Suite? Er, no.
They used Squirrel.
ClickOnce (by the way) is the Microsoft implementation of this approach that’s been around for years. Squirrel is open-source and maintained on GitHub. To be fair to the team, I don’t think this was an intentional hating of ClickOnce, Squirrel is built into Electron as the default auto-update mechanism so they likely just adopted it because it was easiest.
However, another interesting point. Microsoft choosing an open-source, community supported application in favour of a tried and tested, Microsoft-built alternative. Exciting times.
This is not your Grandfather’s Microsoft, or even your Father’s Microsoft. There has been huge change in the last few years in the development category of Microsoft applications, with a real move towards open-source first. It’s really interesting to see this move permeate out to the rest of the organisation and start to manifest itself in other areas like Productivity Applications such as this one.
Maybe we’ll see the Teams client itself added to GitHub soon? 🙂