Microsoft rebuilt Teams from the ground up, promises 2x faster performance
techcrunch.com
techcrunch.com
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:
- don’t be afraid to write good code
- profile often
Electron is a waste of resources. A high price to pay for the convenience of easy multiplatform applications.
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.
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.
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? ;)
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.
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.
---
In this case, I'm willing to bet actual money that most of the speedup is hiding in what they're calling the "Client data layer" here: https://techcrunch.com/wp-content/uploads/2023/03/new_teams_...
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.
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.
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.
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!
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.
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?
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.
Personally - I'd prefer to be on linux full time, but work issues macbooks, and I develop applications that run across all three, so I use all three.
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 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.
• 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.
It all adds up!
> 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.
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.
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.
https://docs.google.com/document/d/1oDBw4fWyRNug3_f5mXWdlgDI...
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.
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?
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.
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.
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.
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.
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.
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!
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 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.
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].
1: https://www.omglinux.com/microsoft-teams-pwa-now-available-o...
'Old' Teams opens in ~4 seconds on my M2 MacBook.
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
I’m quite impressed by the embarrassing honesty.
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.
Both. An endless fractal of low talent building on not caring building on not knowing better.
It’s amazing to me that a “work communication” tool has no inbox.
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).
Well, maybe it can be fixed as it enters public preview and they get more feedback.
I'm generally exposed to it via the video meetings, and it lags far behind Google meet.
To the point where I groan when I see a meeting invite come in with a teams link.
I know it's going to be a mishmash of difficult auth, slow loading, failure to load, refreshing and teeth grinding to get into the meeting.
Once you make it into the meeting everything seems fine and quality is generally pretty good.
It feels like there were different teams that worked on the actual webrtc meeting bits and all the other stuff.
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.
Edit: it's even worse. For some reason chat switching did barely improve at all and still take >2s on "low-end" hardware. Wtf. https://research.gigaom.com/wp-content/uploads/sites/1/2023/...
However in the end my boss didn't like teams and decided to pay up for slack, so we remained on slack and I never needed it.
I had begun to investigate the protocol. At the time it seemed to be doing polling to the server rather than using a websocket.
It could be that trick to make requests with a long timeout, and make them hang if there are no new messages.
Besides that I don't know anything.
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.
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.
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 regularly deploy to 50+ client systems at once and the ability to paste pre formatted comments would save me a lot of time -.-