I wish we could just move back to native apps and stop using the pile of crap that is Electron or any other attempt at bringing web stacks to the desktop.
Honestly, I wish we could just skip straight to nothing but web apps. They work, they work consistently, they work cross platform.
Native apps are absolutely no guarantee you don't have performance problems, and I really don't think it's the render time for HTML/CSS in a webview that's slowing things down.
Most times it's just poor consideration for performance from the get-go. Chuck in a bunch of screens that are fetching remote resources before being displayed and viola... MS Teams.
----
Trust me, the development team that fucks up performance with Electron will absolutely fuck it up with native too.
This is like blaming the shitty bathroom remodel on the choice of tile instead of the poor craftsmanship.
> Honestly, I wish we could just skip straight to nothing but web apps
Why must you curse us like that? Web apps became such a clusterfuck because HTML and the world-wide-web were never intended to run applications, but more and more was piled upon it until it somehow did.
Apps in the browser have shown undeniable advantages, but now that we've seen what we need, why not design a cross-platform toolkit that allows web apps through a protocol actually designed for applications. Something like Java/Flash tried to do, but using what we learned about web apps, back ends, and standardization.
By the way, one of the wild-card impacts of GPT-4 might be that native apps arise again. It's very good at translating code from one platform to another.
> Trust me, the development team that fucks up performance with Electron will absolutely fuck it up with native too.
Microsoft is celebrating a "massive" performance improvement which means Teams, which mostly renders text chat, opens in 10s instead of a minute. I really doubt native apps would have delays like that.
I'm willing to bet a good bit that most of the performance improvement is coming from the "Client data layer" that they show in their updated graphic about the new stack.
I really doubt the performance issues are based on the webview's performance rendering text. If so, VSCode wouldn't exist... and it does exist.
I haven't used angular in a long time, so you could maybe convince me that it's a shite framework from a performance perspective (I'd believe this, honestly) but I still bet money the delay is not local processing delays, but waiting for remote resources.
There's a lot of space between rendering text and doing a slow remote database query. HTML is great but it just wasn't designed for building efficient UIs:
• No multi-threading, by implication you can't do things like deserialize large object graphs on a background thread. To get data to your UI you have to deserialize it on the UI thread, leading to jank.
• JS is a JIT compiled dynamically typed language. The memory overhead compared to C++ or even AOT compiled Java is correspondingly higher.
• DOM/CSS are extremely generic because they have to satisfy both document and app use cases. They're both low and high level simultaneously. On one hand that's great for making interactive documents - an important class of thing that non-web tech mostly ignores - on the other hand it means a lot of branches in hot paths, stringly-typed everything, big code footprint in the renderer, heavy objects, high level libraries can't use shared memory and more. The header file for Blink's DOM Element class is ~2000 lines by itself.
• No modularity whatsoever at any level. HTML just accretes more and more stuff as the years go by. There's no way to opt out, or select a lighter weight faster renderer. As it grows, memory usage and CPU time goes inexorably upwards despite fantastically huge budgets thrown at optimizing it.
• The one-size-fits-all sandboxing model imposes enormous overheads. Do I really need apps from well known brands like GitHub or Slack to be strongly sandboxed? Not really. It's nice to have a safety net in case of exploits, but I don't actually need these apps to be treated as radioactive all the time and the cost of doing so is very high. Native apps can use the latest DirectX on Windows, where hw features appear first, but Chrome serializes OpenGL command streams from the renderer across process boundaries and then does extensive validation before rendering them.
• JS was never designed for large teams. Why did Java become so popular in the enterprise? Because it has lots of rules and features that are intended to let lots of devs work together without stepping on each others toes or making too much of a mess. JS doesn't have the same approach.
So I don't disagree that this space has grown more organically than some, but I think most of what you've put there is fairly outdated.
> No multi-threading, by implication you can't do things like deserialize large object graphs on a background thread. To get data to your UI you have to deserialize it on the UI thread, leading to jank.
This is completely untrue today. I have a variety of ways to move work out of the UI thread as just a simple website. The easiest is to just use a modern networking API like fetch. If you're using response.json() on the result of a fetch call, you're done. The parsing is already off the UI thread by default.
If you don't want to do that (or you have a use case that's doing heavy lifting that's not a network request), you can easily add a serviceWorker and hand off the parsing to that JS context.
If you're on a browser that doesn't support serviceWorkers, you can simulate a similar handoff through framing your page (each page is getting a new JS context) and passing data around with postMessage.
If you're targeting Electron specifically - they start with the concept of a background worker (main) that is independant of the UI thread in the first place. It's easy to move work there.
----
> JS is a JIT compiled dynamically typed language. The memory overhead compared to C++ or even AOT compiled Java is correspondingly higher.
This is true but not really relevant. If you really need to be doing something with high overhead - electron allows you to easily call into native libraries, but you risk losing compatibility.
---
> DOM/CSS are extremely generic because they have to satisfy both document and app use cases.
I see this as a plus. DOM/HTML/CSS have literally been put through the ultimate trial by fire of use cases, and they are still standing.
---
>No modularity whatsoever at any level. HTML just accretes more and more stuff as the years go by. There's no way to opt out, or select a lighter weight faster renderer. As it grows, memory usage and CPU time goes inexorably upwards despite fantastically huge budgets thrown at optimizing it.
This is exactly what <meta> tags are for. They absolutely allow you control over the rendering process. Everything from specifying how to handle viewports to choosing the exact version of legacy IE you might want to target.
---
> The one-size-fits-all sandboxing model imposes enormous overheads. Do I really need apps from well known brands like GitHub or Slack to be strongly sandboxed? Not really. It's nice to have a safety net in case of exploits, but I don't actually need these apps to be treated as radioactive all the time and the cost of doing so is very high. Native apps can use the latest DirectX on Windows, where hw features appear first, but Chrome serializes OpenGL command streams from the renderer across process boundaries and then does extensive validation before rendering them.
I would argue that when the sandboxing is cheap, there's no reason not to use it. There's a reason that most enterprises allow their users to browse the web at large, but heavily restrict installed applications. Just from a bureaucracy and politics point of view, the sandbox is a plus.
---
> JS was never designed for large teams. Why did Java become so popular in the enterprise? Because it has lots of rules and features that are intended to let lots of devs work together without stepping on each others toes or making too much of a mess. JS doesn't have the same approach.
Yes, yes it does. It's called Typescript. Overkill for a single person project, but really freaking powerful for teams. Does exactly what you're describing - makes refactoring easy and safe, and allows teams to coordinate effectively.
------
It does add up, but it sounds like it's been a long time since you've done real work in this space. It's definitely not the same as it was 15 years ago, and while some of that change is probably churn, a lot of it is valuable additions that address nearly every complaint you've come up with.
1. Deserializing stuff in a service worker then requires it to be moved across to the main UI thread but you can't share the objects, right? It's message passing.
2. We're comparing to 'native' apps, right, so memory overhead of common things counts and saying you can use native code isn't really a rebuttal because you can't use it for the UI stuff.
3. We're not talking about how battle hardened they are, but about performance.
4. Meta tags have hardly any impact on the modern web, right? That's why you have to talk about legacy IE, they did try something like that but Chrome has no equivalent.
5. Sandboxing isn't cheap performance-wise, that's my point.
6. TypeScript isn't JavaScript, it's a different language that browsers don't understand.
1. I don't know if any of the major browsers do this, but one could imagine an implementation of that message passing, between threads or processes on the local machine, that has much lower overhead than deserializing from JSON.
6. If we assume that non-trivial web frontend projects these days always have a build step, then it doesn't matter; TypeScript compilation can be included in that build step.
Sure, and TypeScript is great, but I was talking about HTML rather than HTML plus all the layers people have added on top.
I'm also not totally convinced Typescript actually answers the point in question. It's a superset of JS in the end, and a part of why Java/C# type languages are popular in the enterprise is the list of things you can't do. Adding types can help, but it's not something that TS can enforce.
Couldn’t disagree more. Web stacks are abominations of a technology never intended to be actual apps. Yes, I am blaming the shitty web app rewrite on the choice of an inappropriate technology stack.
Web apps many times don’t even work on the same platform with browser dependencies. Ever had to load a web page on a different browser to get it to work?
I dunno, native apps from 2000 on much worse hardware were running more or less the same features much better. Web (and electron/etc.) apps combine encouraging anti-patterns with lowering the barriers of entry too much, it's like if we allowed anyone to build bridges out of 3D printed parts. I am libertarian on most things, but I make exception for things like that... infrastructure safety, air pollution, child abuse and web scripting - these are/got so bad they need to be heavily regulated to keep idiots in line.
The problem isn’t web tech, but rather software (of any kind) that is designed without performance in mind from the start, and by large teams. Something functionally-similar, still using web tech, but produced by one or two developers who care about performance (and yes, I seriously suggest this would be feasible) and are given free rein to do so would be better, lighter and faster than something “native” produced by a similar team to that which has made their existing apps.
Web tech is easy. This incidentally makes stuff built with it likely to be slower. Especially when you have a whole bunch of developers working on a thing. I have come to the conclusion that large teams more or less cannot produce good results by these sorts of measures.
I suspect also (without ever having used it) that a good chunk of Teams’ slowness will be in communications pieces that are nothing to do with web tech.
> I suspect also (without ever having used it) that a good chunk of Teams’ slowness will be in communications pieces that are nothing to do with web tech.
Ding ding ding. This is the winner. I have yet to see someone who is bitching about Electron actually show that the render time in the client is really what's causing the performance issues.
Almost always the issue is that fetching/updating a remote resource is just slow. It's SO freaking slow compared to local access.
Worse - almost every other aspect of computing is actually getting quite a bit faster, but RTT isn't going to change.
It sort of is the webstack since most of it was designed when bandwidth was the biggest bottleneck.
No one planned for a situation where you have a rats nest or 100’s of MB and sometimes even GBs of JavaScript code running in a browser, since just like with the 140K of RAM or w/e it was is enough for everyone one then JavaScript and the existing patterns were good enough when no one could load enough of it to cause actual performance concerns in the first place.
Its absurd that these products whose companies get bought for Billion+ can't have a team of 3-5 engineers focused on performance.
I understand that you have lots of people building features but I'm sure the performance engineering efforts can be focused on the fundamental platform layers which are seen in most flame-graphs.
Its also exactly these companies that grill you on performance and leet-code type problems but ship nothing like what they interview for.
Companies are terrible at tech. They don't know enough to make informed reasonable decisions.
Picking good smart architectures is so hard. The people least capable of judging have tons of power & they almost all push for simpler, almost always minize the challenges.
I wonder if some of that is just part of the incentives of a 2 person team vs a 20-200 person team. 2 people get praise for shipping it, 20 people get (individual) praise for “managing complexity”.
Lamentably, these work on Linux. Nothing else seems to excepting a few using Java (jetbrains) and libre-office and the open source big ones: Gnu Image, Krita and Blender.
Good point, I'm not sure many wanting the "return to native apps" are going to be happy when many places abandon the variety of platforms they currently support just to focus on their primary platform. In the end, performance is just another piece that comes with tradeoffs.
That's funny because Teams famously abandoned its heap of crap Electron (Skype?) Linux client. And when it was working, it was peaking the CPU to play one video stream.
Sorry but web stacks on electron are much less crappy than desktop UI toolkits which are dependent on Apple, Microsoft or also developer hostile QT and web stack is the only real open/standardized alternative.
MS Teams feels rushed, which is probably a good thing from the point of view of what a company should prioritise (being first is probably the most important thing in any market.)
Now that they've won over a large part of the instant messenger sector (every corporate place I've seen uses MS Teams), hopefully they'll chill out a bit and work on making it less clunky.
Message formatting in particular does my head in. Please just let we write markdown, and stop trying to live-replace backticks with rich-text-esque code blocks that I then can't move the cursor around!
You can build terrible software that is native and you can build good software on the web. Microsoft makes bad software, but this is not (at least entirely; you could argue that it encourages it) the web's fault. Look at the clusterfucks Microsoft's native apps are (they're the worst on their own platform ...). They just have extremely low standards for quality.
IMO the approach MS took was actually the correct one here - use Electron for your v1, then rewrite it once things are more established. There's nothing wrong with using a slightly less performant version of something for your MVP (could be argued against for someone as large as MS, but still). Rails is perfectly acceptable, you don't need Rust as your backend from day 1.
As a separate argument, this entire point might be moot. Native webviews are becoming more common (hell MS has used them for the OS for quite a while - when I was there working on the windows 10 start menu, it was actually a webview) and can be much more performant. Since you aren't bundling a full browser in the executable, the memory impact is quite low. Tauri seems to be gaining quite a bit of traction which leverages native webviews, and shows a lot of promise.
“There's nothing wrong with using a slightly less performant version of something for your MVP”
Twice as slow is slightly less? What about losing to competition because your app is slow and doesn’t feel like it belongs in the operating system? Or what about the cost and potential failure of a rewrite of a more complex app requiring technology the existing team has no experience with?
It's funny that the locally installed Photoshop took about 20s to launch, while Photopea launches instantly. Native is not necessarily better if it's poorly implemented.
vscode is the best-case scenario for Electron in my experience; this suggests that you need good diligence to ensure reasonable performance with the framework. Even then, performance is only acceptable, not exceptional.
Sublime Text is a great example of what performance can be like with a different toolkit. Compare it to vscode - even on a fast machine - and you'll start to notice all the little lags that can creep in.
hm but is it comparable? I've used sublime in the past but only as a bare-bones editor. I see vscode more in line with IDEs (it's kinda both), as there ist a lot of functionality and coding support available. Pycharm, Intellij etc are all clunkier in my experience and that's how I mostly use vscode.
The problem with electron software is it has to be fast for lot of people with varied age of computers and not just for those who upgrade machines every couple of years. Currently it is not happening and it is fast on my computer are unhelpful comments.
Is whining about Electron somehow helpful though? It's complained about constantly and the conversation inevitably goes through the exact same discussion points for the 8th or 9th year running.
that's great for 1980's editors, feel free to use them. But vscode is a different beast, a plug-and-play solution ranging from simple editor to a full blown IDE. It also stays snappy for me, as mentioned.
“a plug-and-play solution ranging from simple editor to a full blown IDE”
It’s still mainly just a text editor and not “full-blown”. There is no significant built-in user interface, gui designer/builders, or emulators for example. The plugins can be native, which could allow for this. Essentially, vscode is a text editor that allows for native plugins, which explains the high performance possible.
talking about vscode without its plugins or langue servers does not make sense. They provide 99% of the functionality. The plugins can create new views, from pdf-viewers to interactive coding environments with 3d plots ala plotly. Done in electron. The python language server provides all you can think of with python.
Emulators are not native to IDEs, there's always glue code, you can write a plugin for it. I don't know about GUI-Builders, but in principle you can do anything. It's just a web view after all. Vscode is incredibly flexible. I have written a paper with it including live preview of the pdf. But I don't care about GUI-Builders. You only need them for apps and then you are stuck with each walled garden anyway and forced to use e.g. Xcode. Except ios/android apps, who's native anyway in the 21st century? ;)
The issue is in the application architecture, not the platform architecture.
VSCode uses raw TS with no frameworks and all handcrafted events (manually attaching and detaching dom event listeners is commonplace, and hand wiring each event’s propagation chain is as well), Teams hops to the current flavor of the week framework when they get too far up a tree with the last rewrite’s.
VSCode has also never been rewritten from the ground up, whereas this is Teams’ fourth or fifth time by my count.
VSCode also has about 50 people on it, all said and done (PM, Design, etc included), teams has well over a thousand.
It’s really quite an interesting case study. The lesson being, IMO: stop worrying about electron vs native vs angular vs rust vs react vs blah blah blah and just:
Both are electron apps. I think the parent poster meant just to say "Here's an example of an Electron app that's quick, I'm not sure that Electron itself is the issue"
"Mac support is coming later this year." That means proper Linux support is coming some time between never and when hell freezes over. It can't be a proper general service when the vendor simply won't properly support other operating systems as they do their own.
They had the electron Teams drivel for Linux that at least worked slightly better than the web version, but even that got relegated to be scrapped by M$, telling everyone to just go use the crappy web version, which never really works right for me under Linux/Firefox.
Even when I used native Teams on a Windows VDI instance for customers, it is still horrible for resources, requiring a ram upgrade just to use it, with audio randomly working, restarting the client several times a day when I was using it to restore audio, Windows or Linux, and was quite painful. My last customer wanted to move their existing telephony (Cisco) to Teams - I said good luck and riddance with that and left them to their folly.
At the same time, I used zoom for anything I tended to schedule, and I NEVER have those problems with the Linux client there. Same with Google's conferencing, and WebEx, only Microsoft remains as the most commonly broken thing I use for conferencing or communications in general.
It's amazing the stuck-in-their-ways enterprise Micrsofties out there so used to broken Microsoft things that they just stick with the default checkbox Teams as an "easy" telecommunications solution. M$ gives it away like crack to enterprises for a taste, first hit is always free, everyone feels good for a bit, then they hit with the up sell tax.
Then you realize it has limits and problems... Friends don't let friends use Microsoft.
Meh, as long as they continue to offer Teams as a PWA, I really don't understand the concern. I already use Teams through Firefox and, unlike your claims to the contrary, with the one exception of notifications, it already works far better than the old Electron app, including proper Wayland screensharing and hidpi support.
Not to defend Teams here (it's still worse) but I've had the Zoom client crash on me 100% of the time when I screenshare on Linux, only since the latest version - and of course I could not stay on the old one... Reported it and hoping for a new version, but of course none has happened in.. quite a while.
This thread is probably going to be filled again by perfectionistic engineers who fail to understand the tradeoff between quality and quantity. Microsoft won the work from home game by delivering more features even though the quality admittedly suffered. Quality over quantity. Your perfect engineering mindset loses to the reality of doing business in a competitive market.
> Microsoft won the work from home game by delivering more features even though the quality admittedly suffered.
Microsoft won the work from home game by bundling Teams with an O365 subscription that companies were paying for anyway, making it cost-effective for the bean counters to use a "free" crappy tool instead of a paid better one.
Whether this is anticompetitive monopolist behavior in a legal sense is a question for the courts, but it's certainly anticompetitive in spirit, and undoubtedly true that Teams is not winning on merit.
This is exactly why my former (pandemic) employer moved from Zoom to Teams. When I was leaving, they were pushing Teams over Slack for text. That business has ~5,000 global employees. The move was simply a cost savings measure. Loss of productivity be damned.
> Microsoft won the work from home game by delivering more features
Citation needed.
First off, I don't know if Microsoft did win the work-from-home game. Do you have comparative sales numbers to support that assertion?
Anyway, I'd believe that they won the work-from-home game by...
- bundling Teams in with O365 subscriptions so frugal companies don't need to pay for a separate IM platform subscription, or by
- winning over IT administrators with out-of-the-box Active Directory integration.
Those aren't “more” features, really; they're just the usual, staple bullet points that you expect of every Microsoft productivity application. The feature Teams does need is performance. I don't know a single person who has used any Teams alternative and who still prefers to use Teams, and the chief complaint I hear is about Teams' poor performance. Yes, of course, there will always be those features that people don't know they want until they have it, but when everyone and their dog complains about every possible dimension of poor performance – poor interface responsiveness, high CPU load (“my fan is on!”), poor network utilization (“sorry, my video is worse on Teams”) – you should probably prioritize that.
They might have actually have more features to be ticked off for a general sense of office employees, but it's mostly software developers with a remote first attitude of active collaboration that have been asking about stuff like "working" code snippets not just "can paste code for it to be mangled" and switching rooms (god have mercy on you if you are part of several teams (in Teams) and need to use all those channel frequently) etc.pp whereas they could not care less about some office integration (especially if on Linux) - so I would not dispute the "more features", just that they might be broken or useless :P
Most people in here are users who want to have a slick, fast responding tool. Even if I understand the market gains point; as a user, I dont like it when I have to wait >1 sec to open an application that only shows texts and images. (I also dont like it as a perfectionistic engineer.)
Microsoft cloned Slack (poorly and got sued), used existing corporate agreements to entice companies to force Teams on unhappy employees and got lucky with COVID. It really think it has nothing to do with features. Of the dozens of teams I work with, almost none use any Teams features beyond text chat and calls.
For the same reason, there will always be people who tell you how stupid you are for moving your servers into the cloud. You could just host them yourself, don't you know that?
Sigh. My heart sinks when I get a Teams invite. 60 minutes of hairdryer fan? 4 minutes of waiting for the video feeds to kick in? Video that flickers enough to give me an epileptic fit? But don't worry about all that core usability stuff - at least I can use 'together mode' to make everyone look like they're sat outside! Thanks!
It's not ideal, but I've found that disconnecting the external monitor helps a little (My understanding is that the external monitor engages discrete gpu which heats up the wrong bits of the laptop). I usually only have issues when sharing video - screen sharing seems fine.
Once the hairdryer kicks in, the Intel CPU will drop down to a quarter of its normal speed. (I replaced my personal laptop with an M1 for this reason.)
I'm currently on the last Intel Mac. It's absolute trash. Worst Mac I've ever owned. I've been debating the M2 for a while, but feels like we're coming pretty close to a possible refresh. Never a good time, is there?! haha
Have you tried the PWA? I use it in Linux and it's much more performant than the Electron version. You can use extensions too with it, like uBlock Origin, which makes it even faster.
I mean it's still Teams so faster here means still not fast at all, and it still suffers from many other UX problems, but definitely worth trying if you are forced to use some form of Teams.
It's a maximum of 4 videos at once, isn't it? Sadly at least a couple of our monthly teams calls are bigger than that. Thank you though. It's nice to know I'm not the only one that feels the pain!
Hmm, what? Do you mean like max 4 participants in Teams calls? No I don't think there's a restriction like that, it should work exactly the same as the Electron version. Our team also has more than 4 people. Maybe you are thinking some restrictions on the free version of Teams? If you or your company is paying for Teams/Office, then you get the same "premium" features on the PWA as you would with the Electron app when you login.
If you go to teams.microsoft.com with Chrome or Edge and login, it should suggest installing the PWA [1].
I watched the video and saw 7.5 seconds compared to the older 15 seconds and was surprised that they are presumably proud of this?? Do they have no shame or do they simply do not know better? I worked on a data intensive app with 2D/3D graphics that launches in fractions of a second. All teams needs to do is primarily show some images & text.
Of all the companies that exist out there, Microsoft definitely has the resources to make full native apps for all the platforms they want Teams to run on.
My shitty Toyota Corolla can bring a metric ton of metal and composites to a velocity of 100kmph in less time than it takes Teams to launch… in their own promo video?!
Sorry for the histrionics but the reality of how far we’ve fallen just slapped me in the face
At this point, you just have to laugh. Meanwhile my coworkers keep telling me I need a m.2 ssd instead of a sata ssd so that my os can load in 0.1 second instead of 2 seconds (made up number). Guys, what's the point if everything else is dog slow.
It's a shame this isn't a top level comment as this deserves to be right at the top of the page. Who the hell makes a video to show off how slightly less shit they are?
I think they are referring to 'old' Teams opening in ~5 seconds. The MacOS version of 'new' Teams is not available yet. I imagine the new version will open in a second or so for the new application.
I'm curious if there's a more useful metric than this. I open Teams on monday morning. I close it 4pm Friday. 7.5 seconds a week isn't where I'd like to see improvements.
Yeah. Slack has no inbox, no single view of new messages. If I wake up in the morning and go to work, I have to hunt around for what’s new in the sidebar, clicking into different threads and DMs. I route new activity to email instead of using Slack.
It’s amazing to me that a “work communication” tool has no inbox.
Eh, it’s not usable as an inbox. It doesn’t exist on iOS. It still groups by channel, and if you read anything or click into something then you lose it (dealbreaker for me).
Whereas with my email inbox (which works the same on desktop or phone), I can read the messages without losing them. I can read all the new messages, work on the ones that are most important and earliest, and only when I’ve dealt with them do I archive them and remove them from the list. That way I can always look at my inbox to see what needs to be done (not what I’ve yet to read).
I have a similar experience. Actual call quality is far superior in Teams than Meet in almost every regard. Clarity for users dialed in over SIP is much better, stream quality is typically better, virtual backdrops perform better, and screensharing video performs so much better it's almost no comparison - it is essentially unusable in Meet, feels more or less the same way as screensharing video in 2016 was.
But yikes, every step of the experience up until actually joining the call is just brutal. And if you join the meeting from the browser instead of the native application, a lot of the better performance in-call is gone.
I have yet to find a solution that beats FaceTime in clarity of video and voice and bandwidth. Unfortunately, FaceTime is Apple only and everything besides meeting lacks or just doesn’t exist. Discord is one of the best for voice only.
Great that they are at least trying to improve, but even the improved almost one second channel switch time is imho still order of magnitude too much. How many ms did it take to switch window in irssi?
Anyone in here knows a lib, preferably python, to interact with the msteams API? I'm interested in developing an alternative client (or more accurately, an XMPP gateway).
Hopefully it can keep my camera going on through an entire 30 minute meeting now, like all the competition can easily do, but not Teams for some reason.
They need something like 10x and maybe a single person that cares about the resulting product.
You can't embed videos. Embedding images is extremely janky. Layout keeps glitching. Calls without windows I can click to accept them. You can't forward messages.
Maybe the reason for the neglect was the work on the new Teams, which they'll actually care about? Let's see, my expectations aren't high.
Looking forward to the improvements to Teams, just so that it'll put more pressure on Slack both on the business front and technical front.
Slack has been slacking (pun intended) on performance for a long time now, I'm honestly not sure what exactly it is that they're working on but nothing that I use daily is improved.
Speed and performance has never been an issue I noticed with Teams on my work machine. UX is also fine. Most competing apps are at feature and performance saturation IMO. They all do what we need except for some nitpicky things. I have switched to using self hosted Nextcloud Talk and sometimes Mattermost and Jitsi because of the sensitivity of some of my meetings. With Teams and similar services on some far away server I cannot assure participants that nobody else including AI is listening in.
I'd be embarrassed to show a video of an app of mine taking 20s to launch in the old version, and even more embarrassed to show it take 1s to change channels as an improvement.
They discontinued the Linux client last year so don't hold your breath. They forced everyone to switch to the Chrome PWA. My notifications do not work in Chrome so I had to go back to the desktop version.
It still kinda works fine (ymmv) for me in Firefox on Linux, you just need a full 2 minutes to join a call, so maybe click early if you don't want to be late. The connection is usually (90%) followed up by a small hiccup where it seems you might be disconnecting but then it's stable.
I'm saying this unironically. It's ridiculous and kind of a mess and I'm very glad I only have to join 2-3 per month, but it's reliably semi-working. Or maybe my bar has been set very low by other things.
I used Teams on Linux recently in Chrome since Microsoft doesn't seem to offer a native client download any more and it ran fine, audio and video. I didn't notice any sluggishness.
They need to get the team who makes the Mac Azure VPN Client to make the Teams version. It usually opens in under a second and establishes a connection after a few seconds.
Oh, it can... OCS / Lync / SfB was a nightmare. Compared to that Teams is App of the Year. Which is saying a lot because Teams is definitely not "good". It is "good enough" though, IMO.
As someone who used office communicator back in 2006/2007 time period, it felt more snappy and consistent than anything that came afterwards. It was simple and basic as hell, but didn't have all the quirks.
