The Teams client is built on Electron? Why? Developers need to stop building slow applications. This is ridiculous. It's 2019 and software is slower than it was in the 90s. It must take an enormous number of CPU cycles to execute simple tasks in an Election-based app. It's just incredibly inefficient. I heard similar things about Slack – that it was built on Node, maybe Electron, and was dog slow, especially to open.…
The Horror of Microsoft Teams
151–160 of 344 posts
Re: The Horror of Microsoft Teams
#152The Teams client is built on Electron? Why? Developers need to stop building slow applications. This is ridiculous. It's 2019 and software is slower than it was in the 90s. It must take an enormous number of CPU cycles to execute simple tasks in an Election-based app. It's just incredibly inefficient. I heard similar things about Slack – that it was built on Node, maybe Electron, and was dog slow, especially to open.…
This has been discussed many times here... of course running a Chrome instance is inefficient but in some cases that's acceptable. Especially for the gains in cross-platform compatibility and reliable user interfaces. Almost no other platform can guarantee that a UI elements will look pretty much exactly the same on all different operating systems. Most people don't mind the extra RAM consumption for some application…
Re: The Horror of Microsoft Teams
#153At my work, we use Teams a fair bit, and I'll go out on the limb to defend it (a limb I'm quite familiar with at this point ;) ). Thinking of it as a Slack alternative is, IMO, the wrong starting point. We barely use it for chat (as we have Slack as well). Instead, we use it as a file share and central information home. Each group within a team has a channel and we use the tabs to track meeting notes, embed external…
So essentially Microsoft's chat app is not good at chat, but you use it for file-sharing instead because Microsoft's file-sharing app is not good at file-sharing?
Re: The Horror of Microsoft Teams
#154Earlier quoted context omitted.
This has been discussed many times here... of course running a Chrome instance is inefficient but in some cases that's acceptable. Especially for the gains in cross-platform compatibility and reliable user interfaces. Almost no other platform can guarantee that a UI elements will look pretty much exactly the same on all different operating systems. Most people don't mind the extra RAM consumption for some application…
Who cares if an application's UI elements look the same across platforms? I want it to work on the platform I am using. I simply do not care what it looks like on someone else's platform, and I especially do not want to pay a performance penalty so some designer can have a virtual feather in their cap over it.
Apps are lauded for providing "dark mode" now; when ten years ago I simply switched GTK themes.
To say nothing of accessibility.
We've gone way backwards in UX.
Re: The Horror of Microsoft Teams
#155For extra fun, block access to the telemetry endpoint and watch Teams' memory footprint bloat to crazy levels as the data accumulates and re-attempts the sending. There's some fun inspecting this data, too..
I don't use the windows partition on my laptop for this reason. Once Unity and my steam has Linux support, I never looked back. Only issue is Matlab sometimes.
Re: The Horror of Microsoft Teams
#156The Teams client is built on Electron? Why? Developers need to stop building slow applications. This is ridiculous. It's 2019 and software is slower than it was in the 90s. It must take an enormous number of CPU cycles to execute simple tasks in an Election-based app. It's just incredibly inefficient. I heard similar things about Slack – that it was built on Node, maybe Electron, and was dog slow, especially to open.…
This has been discussed many times here... of course running a Chrome instance is inefficient but in some cases that's acceptable. Especially for the gains in cross-platform compatibility and reliable user interfaces. Almost no other platform can guarantee that a UI elements will look pretty much exactly the same on all different operating systems. Most people don't mind the extra RAM consumption for some application…
Re: The Horror of Microsoft Teams
#157Earlier quoted context omitted.
Who cares if an application's UI elements look the same across platforms? I want it to work on the platform I am using. I simply do not care what it looks like on someone else's platform, and I especially do not want to pay a performance penalty so some designer can have a virtual feather in their cap over it.
I prefer native widgets to whatever application-enforced fad of the year is current. Apps are lauded for providing "dark mode" now; when ten years ago I simply switched GTK themes. To say nothing of accessibility. We've gone way backwards in UX.
Re: The Horror of Microsoft Teams
#158I doubt the numbers MS throws around though to show how they are succeeding. If they are bundling Teams with Windows or Office of giving it away for free with Office 365 or Outlook, they could claim every single Windows laptop and PC as an active user and soon be at 1B users. Technically correct but oh so wrong!
Re: The Horror of Microsoft Teams
#159Earlier quoted context omitted.
This has been discussed many times here... of course running a Chrome instance is inefficient but in some cases that's acceptable. Especially for the gains in cross-platform compatibility and reliable user interfaces. Almost no other platform can guarantee that a UI elements will look pretty much exactly the same on all different operating systems. Most people don't mind the extra RAM consumption for some application…
The problem with regard to RAM consumption is the tragedy of the commons. One electron app is okay, but once you're running up to ten or more of them, the resource usage gets out of hand.
Now it's all JS and Electron and every single complaint people used against Java is an order of magnitude worse and everybody seems to be happy about it.
Progress have definitely been going backwards.
Re: The Horror of Microsoft Teams
#160I think the biggest problem with Teams can't be discovered by feature comparisons and performance metrics.
Teams enables a company to "secure" the application in the same way other MS products can be. That makes the product easy to sell, but in practice, it prevents Teams from being an effective collaboration tool.
If I want to create a new channel, I need to get approval from IT. If I want to invite a vendor to participate, I need to convince IT that the benefit of adding this particular vendor to Teams outweighs a raft of vague "security" concerns. In the end, it's not worth the trouble of asking and I end up setting up Slack channels instead.
By creating a product that can satisfy the IT policies of their enterprise customers, Microsoft has unwittingly created a platform completely unsuited to flexible and open collaboration.