Drop Electron.... for Edge Webview2. I mean, okay sure, half the memory is an improvement. But what is going on in the chat industry that everyone's converged on Electron? You'd think Microsoft of all companies would be able to figure out how to build native apps. If I want a chat service with native apps, it seems like my only option is IRC.
Native apps means essentially building at least 5 distinct apps: windows, mac, iOS, linux, android. What a mess to work with and maintain.
We already have cross-platfrom UI engines called browsers and they're very advanced and reasonably pleasant to work with these days. If you bundle the browser (electron) then you don't have to worry about differences between browsers. So electron makes plenty of sense to developers, even although it's an egregious resource hog.
If only Microsoft had a app development framework designed to allow developing apps for multiple mobile + desktop platforms with as much shared code as possible.
Cross-platform development is like communism. An unattainable utopia. There's no "magicking-away" the idiosyncrasies of cross-platform development with abstraction layers. It's simpler to use native tools and go for the best each platform has to offer while keeping the L&F UX as similar as possible.
React Native and (arguably) Flutter are going through a golden age right now. Major companies like Tesla, Coinbase, and Shopify have adopted them, and the developer experience has never been better. I'm not sure why it worked now, but didn't work for Xamarin / Ionic, though.
For Xamarin I would answer that with: Flutter and React native are 'light' on the developer: you get instant feedback. Xamarin, at least when we dropped it 2 years ago, was really slow and, besides c# which we will use on the server, hardly pleasant or light. I think these days, the developer needs a smooth experience (once the tons of crap has been installed and set up, which is why I prefer Flutter over react native) so things that are not that will fall over. I think, after that, comes author influence: so if you take that, you get to RN, Flutter, Xamarin, Ionic if you sort them by EasyOfDev,AuthorInfluence.
Popularity means popularity. It doesn't mean utility. There are plenty of dumb things large companies use. OTOH, there are also many unsexy, little-known, ubiquitous technologies essential to certain sectors of the economy.
I've never used it in anger, but I thought Xamarin probably had the most pragmatic approach. Their recommended path was to have a common core of business logic, but to build native UIs for each platform you wanted to support hooked into that logic.
It's basically rebranded Xamarin Forms. Outside of bundled Windows apps, Microsoft is going all into web technologies for consumer apps now. Even within bundled Windows apps usage of .net is almost nonexistent. Built in OneDrive client is written in Qt!
My SO just finished a term project that used Xamarin.Forms. Conceptually the framework is perfect then you actually use it and want to off yourself. MAUI, if taken seriously and isn't only a rebrand, could be quite an accomplishment and a great tool.
I'm not sure about the state of Xamarin Forms these days, but back when I worked with it a few years ago even the sample apps had memory leaks on iOS. I agree that conceptually it was amazing, as was Xamarin itself. If Forms doesn't have leaks these days it would definitely be a great way to build cross-platform apps.
I'm not denying that it's a complex or costly process, just lamenting that they don't care enough. Of course, the problem is compounded for me by the fact that at any given moment I end up having 3 different enterprise chat apps open on my work laptop for collaboration with outside parties.
And the result of that knowledge is a worse experience for users. However you frame it, users are losing because MS doesn’t want to shell out the cash for good UX.
Outlook is switching to WebView2-based UI like this soon. As for Excel, here's its PM saying "When you look at the overall allocation of resources on the team, a huge percentage is working on web app improvements" https://twitter.com/jones206/status/1388162347059978243?s=20
I don’t think that connecting the 4 buttons of functionality in 5 frameworks is all that much work, when the bulk of the work is backend. Also, it is a trivially scalable problem, where you can just throw 5x as many people at it.
I get the popularity of electron and other cross-platform tools for small startups, but for Microsoft..
> Also, it is a trivially scalable problem, where you can just throw 5x as many people at it.
Having done exactly this work it's really not as simple as throwing 5x as many people at it.
Though to be clear, I am an advocate of native apps on each platform and am not a fan of "wrap a webview around it" type fake-apps. That said, we need to be honest about level of complexity here.
The problem with maintaining 5x native apps is not just the cost of hiring 5x as many people - as you scale towards more platforms the inter-team coordination overhead increases exponentially.
The complexity of coordinating 4 teams to ship in lockstep on 4 separate platforms isn't double the complexity of 2 teams on 2 platforms.
There are a bunch of intersecting factors here:
- product management has extreme load - new features need to be designed for every supported platform at the same time, increasing complexity in feature definition. Some features aren't possible on some platforms, so that increases scope and complexity of the features as we include fallbacks or exceptions.
- engineering has to happen (roughly) in lockstep with one another. It's not acceptable to ship a new feature only on Windows and not Android - they don't have to launch on the same day, but neither can they launch a year apart. This means you have multiple engineering teams that basically have to move at roughly the same speed, even though they are developing on completely differently platforms.
- underlying platform changes affect your ability to move in lockstep - iOS and Android both have significant yearly updates that create additional testing needs. Both platforms also introduce more significant OS-level features that you want to add support for than the older/more mature platforms like macOS or Windows. This throws another wrench in having your teams progress in unison.
There are real advantages to cross-platform frameworks, even though I dislike them from a UX perspective. In particular I have beef with the use of web views, which while offering incredible consistency between platforms is probably the least CPU/RAM efficient way to do literally anything. A huge part of why computers feel slower than ever is the pervasive use of web views for everything.
I really, really wish we had a better cross-platform solution than a thing with an ill-defined render cycle, bases literally all rendering on an XML-like structure, and has all processing stuck to a single thread on an interpreted language. Yikes.
Regardless of what the financial markets value them at, their resources are proportional to profits, not market cap.
That aside, they also have lots of products and teams and some have more budget and resources than others.
Saving some memory usage in teams for more than double the development costs, is probably an unattractive position for that team. It also makes it hard to keep features consistent across platforms (as it is, teams struggles with that!)
Not a great example since they sold over a billion worth of stock. They do actually have more money now.
Microsoft generates more money than they know what to do with so they return large amounts in dividends and probably stock buybacks (I haven't checked for MSFT specifically, but it's all the rage these days.)
How can an organisation start a Web/Desktop project which can never ever be _good_ (not to mention great) and frustrate and annoy its customers all the time? If native is a mess, how is outsourcing the mess to the user justified?
What's the alternative? Be only on one platform? Not viable today. Implement 5 different apps, usually not viable.
The platforms are fragmented and the user pays the costs of that in the end, one way or another.
If you hide it by increasing development costs, the price of the app ( or amount of ads or premium only features) must go up to compensate and the user pays the cost as well.
Edit: downvote all you like, there is still no magical solution.
Abstract away the core of the product (data, connectivity etc) behind an internal interpreter, which is the same on all platforms and connects to native UI.
That's a hopelessly simplisitc way of looking at the situation. Every team at Microsoft has different levels of resources, and some would rather spend those resources improving their product rather than writing and maintaining 5 different versions of the frontend part of their product.
We also have Swing in Java which is mature, performant, and works across all our desktop stacks. Mobile UI is different enough that you need to write a different interface anyway.
In other words: outdated, ugly and barely supports modern requirements such as high dpi. Apart from Jetbrains who put in a literal buttload of engineering, there is not a single Java Swing application that is not an absolute PITA to use.
I‘m sorry but have you been living under a rock? SwiftUI, UWP and Jetpack Compose are platforms that differ extremely from the way Swing works. Swing on macOS looks like OS X 10.9 (still uses Lucida Grande as the System Font), we’re 5 releases past that. On Windows, it looks like Vista, we’re past that, too, see modern apps such as the Terminal.
I don't think the inversion of control that SwiftUI or Jetpack Compose do on MVC is particularly fundamental. Factoring out the diffing of state when an observer is notified of updates into a single place can be a useful thing to do in certain cases, such as when a bunch of teams are all putting things on the screen and you don't want one of them to screw up the update loop for everyone (thus Facebook's use of React), but it makes the creation of composable views less straightforward, and you end up with the new problem of annotations to try to keep recalculation of the whole UI from being a performance problem. In MVC, a compound view can usually short circuit updates of its child views very naturally when there are no changes needed.
I just opened a couple of Swing programs on macOS. Other than not having dark mode, I couldn't see any major difference. I can't check it on Windows right now.
Maybe mac users need to start paying for app instead of complaining about every app that doesn't use "native toolkits" or doesn't "support the most basic Mac behavior'. There's a reason that they don't, it's that mac users that care about this don't pay enough to justify a native app.
When and where it's a priority: creating a solid user-experience takes effort. If a project can't manage that when it matters, then their product or service is also going to suck in so many other ways their users will notice. Then native or not, it won't matter when everyone hates them.
Mac and iOS are relatively-straightforward, aren't terribly different, and share development resources.
Android (Kotlin) doesn't often lead to suicidal ideation.
Windows is meh.
Linux is so-so.
> So electron makes plenty of sense to developers
To mostly front-end developers who don't know much about the world outside of a browser.
> , even although it's an egregious resource hog.
Violating nonfunctional requirements to be usable, performant, and efficient.
> To mostly front-end developers who don't know much about the world outside of a browser.
Just for the record I'm a senior backend developer, who sometimes operates at CTO level in startups, and I suck at front-end development. But still electron makes sense to me. Or react native if it's mobile only.
The state of cross platform development is pretty bad.
It wasn't directed personally. The tendency is for front-end developers (the bulk of developers numerically) to treat software development like RMS does with emacs: everything extends from their perspective without consideration of perspectives or paradigms beyond their own. Embedded, native, real-time/mission-critical/fault-tolerance, resource-constrained, widely-compatible, ASIC/FPGA, and/or production-/shipping-scalable.
Cross-platform development will never be improved by N-times duplicated effort of abstraction layers on-top. The best that could happen is for OS developers to agree on common interfaces like UNIX/The Open Group for low-level operations, but for high-level media, UI, and common native development APIs more integrated than a patchwork of libraries like Qt, LibUV, etc.
I've worked on nuclear reactor simulators in F95, embedded industrial GPS equipment, deadline-oriented ad server meta-mediation, Fortune 500 client-facing consulting, compilers, functional programming projects, and now earn a paycheck doing SRE/PE since it's easy money to fund side-hustles.
There's also Ripcord https://cancel.fm/ripcord/ which is tiny, native, and works with slack. Going with electron is a simple way to get quick results so companies like it.
It looked interesting to me, but their disnhonesty just threw me back:
> Not a subscription—never expires
> Includes 1 year of free version upgrades
Are you telling me that a third-party slack client will keep working forever without updates? The "not a subscription" message here is effectively moot: this thing will stop working and you will need to pay for "another year of version upgrades".
Those are the two common models of proprietary software distribution - subscriptions or one-off payments. Did you actually expect lifetime updates for $20 - i.e. the benefits of subscriptions for the price of one-off purchase?
It's not promising you to work forever without updates, but also it doesn't force you to pay if you're happy and everything still works.
The big difference here is that nobody should expect this app to continue working without updates.
Contrast this with something like sublime text: years from now you can still expect it to work normally.
What I expect is that if your app will not continue working for a long time then you should not make "lifetime license" one of your selling points unless you are prepared to offer lifetime upgrades too.
Core text chat function has been solid for me the last 2+ years on Ripcord on macos and ubuntu. Image handling, search, notifications, e.g., have varied for Slack and Discord channels.
They are the one example of messaging done right on the client side.
And it maddens me that their whole team, including ops and backend is like 50 people.
At the same time, they used some pretty unconventional ways to find brilliant people. For example, for iOS and Mac and android apps, they simply held a contest for the best open source app fitting succinct and reasonable requirements. The winner got sizable prize and place on the dev team.
Then they released that app as a Telegram X and then gradually sunset the older app.
> And it maddens me that their whole team, including ops and backend is like 50 people.
But that's how they get so much accomplished. Fred Brooks was correct in 1975 and is still right in 2021. Throwing headcount at a problem only delays it.
I've never used Telegram, but I suspect the Teams integration with SharePoint/Office365 and the (terrible) way Teams tries to be cake icing and floor wax by integrating file store, wiki, document library, telephone, whiteboard, plugin app ecosystem and webhook scripting environment with Windows ACLs makes it more complex than an independent chat/call/video call program?
Don't get me wrong, I loathe Teams and its laggish bullshit nature as much as the rest of the pitchfork wielding people in this thread, it's just that it's not apples-to-apples comparison with a pure chat/call client and the headcount needed to develop it because of how much extra junk is hiding in Teams.
I agree with your point however it just goes to reinforce that part of the failure of teams is that it kind of does a lot of things but it does all those things really badly. If they had some notion of a product vision, some focus, some opinions and executed on those with a users first attitude then it might not be in such a sorry state and it would probably be a whole lot easier to deliver great native experiences. IMHO a big part of the problem is this idea of just throwing features at applications without designing an actual product that seems to be extremely popular but always dreadful. Do less and deliver excellence, don’t do everything half arsed and throw more adverts at the resulting problem.
Native is not a tool, nor a goal. Native is an implication of a user experience and performance. Very few non-native applications provide the same experience and performance as native applications (although there are exceptions and it's not always black and white).
"Native" is the implication that a certain level of comformity is present: the user generally gets an experience that is similar to other native applications.
As you develop with native APIs, and when you follow the best practices for the platform, you end up with a product where the UX is much easier to grasp for the user.
Non-native solutions very often have different UI/UX patterns, which leads to users having to learn these patterns before the application becomes understood by them.
> the user generally gets an experience that is similar to other native applications
This sounds like the goal you want to achieve using native as a tool.
But anyone who struggles to grasp non-native UI and UX is going to struggle to interact with the modern IT environment as there is no standard for web-apps.
If I order a cup of tea, you could argue that what I actually want is to achieve the goal of drinking something which has the taste, smell and general nutritional profile of tea.
Theoretically, there might exist a cup of coffee that achieves this goal. But I've never seen one, and if you serve me coffee it's almost certainly not going to achieve my goal.
For me personally, it's having a set of UI widgets as consistent as possible with everything else on the platform as the primary concern. Secondarily it's performance / battery life.
I think this has long stopped being a design goal. The OS is not the primary platform any more which everything orients around, it's an access point to the web. Products are determining design language now.
People don't expect Google to look 'like Windows' just because they're on a Windows OS, they expect Google to look like Material apps across all platforms. There's not 'windows spotify' or 'android spotify' but they expect the app to look the feel the same everywhere, and in that way companies actually benefit from using Electron.
In my experience the people who decide these things talk about branding. Not user expectations. Phone, tablet, and desktop apps have different interfaces anyway. And few people use more than 1 desktop OS and 1 mobile OS
I think this argument used to make sense to me as well, but since most apps I interact with are web apps in browsers these days, most of my interactions aren't with native widgets anyway and I don't really care anymore.
Many of us have been bludgeoned by web apps to the point of not caring any more … most web apps are slow, twitchy interfaces that shift constantly and the industry loves it because it allows them to utilize the armies of (used to be cheap) web developers but at a heavy cost to the user experience
As someone who switches between three platforms, I like that Electron apps are consistent and in sync. Back in the day when I was using Skype, I could never get used to either.
I don't know what Slack or Teams would look like with native UI components, but I am pretty sure I would consider it inferior to what we have at the moment. The possibly improved performance and memory footprint would be nice but not enough for me to care about.
Performance, small bundle sizes and native UI widgets. And judging by all of the Electron apps failing in these departments, I guess you really do need native apps.
It's the memory bloat that stands out to me. Many modern laptops have 8GB of RAM. (Curiously this number hasn't really changed in the last 9 years.) 500MB of bloat isn't a trivial fraction of that.
Also, an application that runs constantly in the background, is under a greater obligation to make efficient use of system resources.
> judging by all of the Electron apps failing in these departments, I guess you really do need native apps.
I'd put that differently: solutions heavily based on web technologies seem to consistently fail to be anywhere near as efficient as solutions that use conventional toolkits. (Sometimes someone will suggest this isn't true if the web-based solution is well implemented, but they are never able to give an example of such an application.) On most platforms, Qt doesn't count as being truly native, but it's still far more efficient than Electron.
BestBuy sells some Windows laptops with 64 GB eMMC. Space is precious on those. Chrome devices often ship with 16 GB; if Microsoft could make Windows viable at that size, they could push the absolute low end prices down a smidge and keep more users.
I get 60 Mbps down and an upgrade would be $50k. Bandwidth is relatively precious to me.
Going through the sunk cost of making 5 different GUI's and maybe wrapping some syscalls/API for the same 90% core app, resulting in minimal resource usage. It's the correct computerscientific approach and companies like Microsoft can (and should) commit to it. Breaking changes nowadays are too few and far between.
I don't think RAM conservation is high on anyone's list of initiatives to improve the world. The resource consumption of Electron is mostly of interest to computer scientists who like to see how small and efficient they can make something. But in this case, it does not really matter.
No. It also matters to the users of the laptop and to the people who have to buy it, as using too much RAM can lead to slowness due to swapping and can make older laptops unusable.
It's basically having a third-party forcing programmed obsolescence at your device.
> The resource consumption of Electron is mostly of interest to computer scientists who like to see how small and efficient they can make something. But in this case, it does not really matter.
It matters to sysadmins. Some people need to also work on the computer and when Teams uses all memory they will close it.
Somewhere along the line, we really lost it in software.
A few decades ago I paid about $1000 for a one MEGABYTE memory upgrade, and even that was needed only because a single graphics application at that time could clearly benefit from the extra RAM to do more things.
Now? I have 32 GIGABYTES of RAM, and we are celebrating that a chat client has now managed to find a way to use a slightly less absurd amount of memory, and has graciously returned some of our massive computing resources to us? This app barely does anything!! The apps that require all that power should at least be more useful...right?
As far as I can tell, every person on the planet is using more battery power and upgrading their machines more often just to make up for the laziness of software companies. In exchange for the ability of software teams to “easily” write one obnoxious cross-platform beast, we all get to burn through our CPUs and memory. These companies have more than enough money to invest in writing software for different platforms using the heavily-optimized system frameworks on those platforms.
You could argue that the companies were brought to the success they have due to the fact that they were fast to market to all available platforms. And to think of it, I don't reckon a small company writing a client for only windows/mac would make it big enough to get the money to port it to the other systems.
A few decades ago most software wasn't free and wasn't usable on the web.
> These companies have more than enough money to invest in writing software for different platforms using the heavily-optimized system frameworks on those platforms.
Companies don't work that way. Why put X million dollars in Teams if it won't really increase revenue?
Electron came out of Atom, which came out of GitHub, which Microsoft now owns. Obviously Microsoft is a vast empire and there's no reason every team will adopt other teams' work, but it seems curious to hear that electron was dropped for what's effectively the same tech (chromium rendering a web app).
The article tries to explain why Edge Webview2 is better, but I don't find the explanation very compelling. Chromium doesn't seem to be the problem, because both technologies use chromium. So is it the Node bits? Configuration of chromium inside of electron?
From the outside looking in, I find it curious that they didn't just change Electron to do whatever magic they wanted it to do. Certainly they have the expertise and resources.
I think there's two reasons memory usage is lower. First, WebView2 is essentially just another tab in an already running browser process. If they're not pinning to a specific version of WebView2, they're reusing the host machine's copy of Edge, which I believe is always running now, so startup latency is reduced. I think their numbers don't include the memory usage of this "always on" instance, and only count the Teams-specific memory usage. Second, Microsoft has done a lot of under-the-hood work to reduce memory usage of Edge on Windows that hasn't made it upstream into Chromium, so I suspect that gives them an additional decrease in memory usage simply by switching from Chromium to Edge-Chromium.
Does that matter? Microsoft employs probably all of the foremost experts on Electron right now. The decision to move away from electron didn't happen before Microsoft bought GitHub.
It seems to me that Electron is a scapegoat here - VS Code is built on Electron and is super snappy and responsive for me, even on large projects. This means two things:
1. Even complex Electron apps can be performant and responsive
2. Microsoft as a company has people that know how to make this happen.
The reality is (speaking as a former MSFT employee) that the Teams and VSCode orgs are so far separated that they might as well be in different companies. The average quality of devs and their respective management chains varies WILDLY across organizations, and given how shitty Teams has been and continues to be, I think it's fair to say one or both of these factors is at play here.
Everytime Electron is mentioned, VSC will be presented as counter example. The problem is VSC is the only snappy Electron app out there, Microsoft spend millions optimizing it, while most other Electron apps are crap.
Native programs can be made snappy easily. That's the whole point.
But then with native you have to pay the cross platform price. Which is higher do you think?
With Electron you get cross platform more or less for free and ostensibly you can make it faster later.
Don't get me wrong, I love doing native work, but as someone who has to deal with cross-platform issues in native applications (well games) on the daily, I can tell you that even with massive code reuse and good interfaces, that cost is incredibly high.
> But then with native you have to pay the cross platform price. Which is higher do you think?
You could for example use Qt. It is cross-platform and if you write your application well, the amount of platform-specific code will be quite small.
>With Electron you get cross platform more or less for free and ostensibly you can make it faster later.
It's not for-free. The effort/work for the developer is reduced, while the amount of work for the users' PC is increased. Sure, a lot will think, that this is a great deal, but at in my opinion, you should do it the other way round.
How often have you seen electron apps going faster? I never did. With a native toolkit, you have performance from the beginning for the same quality.
I mean, you are talking about making a goddamn text editor faster — it’s just ridiculous. There should be no lag whatsoever when it comes to UIs in 2021.
Building a text editor across platform with exact the same behavior is somewhat a thing that you almost always to redo "everything" in different platforms.
It isn't very unseasonable to just relies on something that already do most hard works for you.
If you must use some "native" alternative. It is probably something like GTK/QT. But I doubt do they actually have the ability to do such complex edit behavior and layouts.
> It is probably something like GTK/QT. But I doubt do they actually have the ability to do such complex edit behavior and layouts.
They actually can - QtCreator for example. Also, I really don't think that the web would be the panacea of UIs, on the contrary.
But I otherwise agree with you - text editors are surprisingly hard. But I still don't really get the why for teams. It could even just add a webview for the actual meeting part, but let the rest be something actually workable.
> "But then with native you have to pay the cross platform price. Which is higher do you think? With Electron you get cross platform more or less for free"
Don't pay the cross platform price. Stop developing inferior software for your core users so that other people on other platforms can also have inferior software. It's not a good tradeoff, it's a bean-counter's tradeoff.
It's like going to a steak restaurant and finding they only sell lettuce so vegans can eat there, or going to a bar and finding they no longer sell alcohol because they're trying to appeal to tetotallers who don't like bars. It's like Ferrari putting a Honda Civic engine in to try and appeal to both sets of customers and the Honda customers don't want the six figure price tag and the Ferrari customers don't want a low power reliable 4-cylinder engine. It's the "one size fits nobody very well" of software, it's the abandonment of your core competency to appeal to people who hate you.
Visual Studio Code is easily one of the most unresponsive IDEs I have used in a long time. If I edit a big file it just completely seizes up while trying to process it again, and everything feels delayed.
I still use Skype, as Discord is missing a feature I use. With Skype people can call me using a landline and I can dial out to landlines. It would be cool if Discord added VoIP landline support and could even transfer numbers from Skype to Discord.
Linux looks like it won't happen until 2022 but Mac is first. I'd guess they are aiming to have it release around the same time as a bunch of other stuff this Fall but still can't commit to that date yet.
Teams is an embarassing piece of software. I use it on work laptop - a Microsoft surface. The laptop is Microsoft branded and all their software is so slow. Clicking to change chats is 1-2 seconds of delay. Opening office files is 1-2 seconds of delay. Opening calendar in outlook is 1-2 seconds of delay. Everything is so laggy and 90% of the time all you want to see is text. Ctrl-F search through Teams defaults to non-exact search.
I've recently switched to the browser based client https://teams.microsoft.com and ditched their desktop application as I grew frustrated with its extremely slow UI. The browser client is more responsive, consumes less CPU and RAM, and uBlock some of the tracking javascript.
I can live with some of the missing features:
No noise cancellation
Audio devices are configured via windows sound settings
Can only share full screens and not individual windows
Standard Windows notification sounds and not the Teams sounds.
Maybe missing more otherwise its more or less the same app.
I've installed it as a Chrome App and it has its own window, task bar icon / shortcut and generates notifications.
Thanks for this! Looks to be a game changer for my productivity and sanity!
I was about to get a second device for teams. Performance has degraded so badly that it's now impossible to pretend to be in a meeting and run an IDE / office apps / factorio at the same time.
> Can only share full screens and not individual windows
At least on Chrome, the Teams screen sharing option summons the Chrome screen sharing dialog, which allows you to select either the whole desktop, individual windows or specific tabs inside the browser. Maybe the limitation is from the browser you are using? (Although I would be very surprised)
In fact I once timed getting into a Teams meeting from turning the computer on and it took pretty much exactly 5 minutes. FIVE MINUTES. The laptop has an SSD how is it five minutes?
The delays in Teams kill me inside. I press the up arrow to fix an error, wait for editor to initialize, then wait for the cursor to move to the end of the text, then edit the typo and re-send. The waiting part is 500-1500 ms. The overall responsiveness is abysmal.
FWIW, I'm currently finishing up an ActiveX wrapper for WebView2 so that it can be consumed in a way similar to the old IE WebBrowser control and so far I'm pretty impressed.
To give you a basic idea. I'm running the control embedded and the WebView2 control consumes about 60MB after navigating to my own -mostly text- website. Browsing within that control to the page of the hacker news topic makes the RAM usage go up to 130MB. Navigating back to this hacker news comment page and the memory usage drops down to about 75MB.
So yes, I'm impressed by how well it works.
edit: Another huge advantage. Last week I upgraded MS Edge and WebView2 is also upgraded. So the control is kept up to date and not depending on an external dependency that might end up being a security nightmare.
> : Another huge advantage. Last week I upgraded MS Edge and WebView2 is also upgraded. So the control is kept up to date and not depending on an external dependency that might end up being a security nightmare
Or disadvantage if you look at it from the developer's point of view - they have zero control over the browser version, so if there's a bug, or lacking feature, or something deprecated, you're screwed.
It's a COM interface they can't deprecate without changing the interface.
re. "zero control".. you can set a minimum version that you require for your application. If Microsoft creates a bug then yes, you might have an issue. But that counts for the whole stack anyways.
> I'm currently finishing up an ActiveX wrapper for WebView2 so that it can be consumed in a way similar to the old IE WebBrowser control and so far I'm pretty impressed.
To what extent are you maintaining compatibility? The old mshtml provides com bindings for pretty much everything. I'd be interested to see what you have if you end up releasing the code. I would love for the old Trident / mshtml / edgehtml engines to be made open.
Not very compatible with the old IE WebBrowser control I'm afraid. That was on my list of things to try, but it just isn't feasible.
With mshtml you could directly access the DOM and do pretty much anything in there via its interface.
With WebView2 there is no direct DOM access. You have access to what is running in the browser, but it is all via javascript. I'm building a bit on top now to get some basics to the developer without getting their hands dirty in javascript, but for Microsoft clearly the idea is to use javascript to manage the DOM.
re. releasing the code. Sorry, it will be a commercial undertaking. I will release the control, but it won't be free.
I'd like to see an independent check of this claim, like 50% memory reduction, but under what circumstances?
If that's at startup when the app doesn't consume a huge amount of memory that's not a particularly interesting claim.
If that's after hours of app usage when the previous Electron app used to consume let's say 1GB that's really impressive, but if the app is consuming 1GB of memory it's because the app itself is allocating a huge amount of stuff in the heap, you can't just swap browser engine under the hood and cut that in half with no downsides, otherwise every browser maker would do just that.
> I'd like to see an independent check of this claim, like 50% memory reduction, but under what circumstances?
You have 32 GB RAM ? Teams will use only 16 GB.
> If that's at startup when the app doesn't consume a huge amount of memory that's not a particularly interesting claim.
Of course it's at startup. Then the app needs to draw its ugly black window and it needs more RAM. It uses HW acceleration, you know. And it's slow like hell.
> If that's after hours of app usage when the previous Electron app used to consume let's say 1GB that's really impressive, but if the app is consuming 1GB of memory it's because the app itself is allocating a huge amount of stuff in the heap, you can't just swap browser engine under the hood and cut that in half with no downsides, otherwise every browser maker would do just that.
Every respectable browser will use the whole available memory. From time to time they will have a patch to halve the memory usage but they will recover quickly.
The fact that they market Xamarin/MAUI as cross platform and Blazer for web, and not use any of their tech to build a cross platform native/web app is laughable.
TypeScript is also there thing. They've been pushing React as well in SharePoint & other areas for quite a few years.
Blazor is very new & was considered experimental until recently. It's still fairly bleeding edge.
Microsoft started Teams in 2016 & bought Xamarin in 2016.
JavaScript developers are also more plentiful than Xamarin I assume.
They should choose the best tools for the job, even if it's not there own.
- Edit - It looks like WebView2 is a Microsoft thing based on their Chromium browser version. Super common for Microsoft to make multiple competing products that do similar things.
Word/Excel run natively on Windows and MacOS. Also have a web client for them. How does that justify using web technologies for cross platform development?
I believe Word/Excel have a really old code base. The web tech versions of them are very different applications with different feature sets. They're about as similar as VS Code is to Visual Studio.
I think Microsoft is trying to move towards a cross platform for everything from what I've seen. They have a ton of legacy stuff though.
As far as I can tell, WebView2 only runs on Windows right now; the current version of Teams runs on Mac and Linux as well, though. I wonder if that means WebView2 will also be coming to those platforms, or if it'll remain an Electron app on those platforms, or if they're just dropping support for those platforms entirely.
This could also have interesting implications for VS Code. I wonder if Electron has a future at all, or if it's going to go the way of Atom, which was another thing MS picked up from GitHub and then walked away from in favor of a quackalike with a stronger Microsoft pedigree.
I'm wondering how swapping Electron for another Chromium backend will allow them to halve the memory usage. Is Node the main reason that Electron uses so much memory? Or is the Chromium renderer poorly optimized to the extent that it's using double the memory needed?
You must remember that each Electron instance will have its own gpu and browser process.
If you do just like Chrome, one host process + one gpu process and all the rest are renderer process as it was meant to, you will use less memory.
Im working on something that are meant to enable native applications with a Chrome-based platform, and it was one of the first thing i've tried to achieve.
Electron was just being sloppy and stick with its first MVP.. because being able to centrally control things through a process like the Chrome browser process does, give you a lot more functionality to explore, compared to what Electron is doing where each host/browser process is isolated and don't know about the other players.
I have noticed that most people I see who have not had a good experience with Teams are coming from Slack. Could it be like if you have learnt Vim it is hard to move to Emacs and vice versa? My company love Teams and don't struggle with it. For me the killer feature is the deep integration with Office. In many businesses Word, Outlook PowerPoint and most of all Excel are where people spend their days. SSO, deep integration, that is what enterprise IT wants.
Everyone is talking about memory usage. But for me it's nuts how much CPU Teams is using when doing a video chat. Facetime video calls are barely measurable, CPU-wise, whereas a 1-1 call with Teams can easily occupy more than a full core. Quality and latency are much better with Facetime too.
A few years back my company put out reqs for Qt devs because we were pushing hard to do some POCs with Qt frameworks. We had a hard time finding those people. I don’t know if it was location or compensation or what.
Unless you need to make a really complicated UI, do you really need Qt devs?
I did a custom widget for editing petri-nets in Qt (no QML), you just need competent devs, whether you have Qt, GTK, or winforms experience doesn't matter.
Please, no! They would fuck it up somehow, and then abandon it after a few years. Qt has been very stable and dependable for.. ages. MS has created and forgot then forgot too many frameworks during the same time.
I had this issue with Teams where if I pasted code from VSCode (even just a 1 liner) it'd add a NUL character to the end and when pasted back into VSCode by the recipient it would mess up the JS file (no longer able to load properly in a web-browser).
Just don't understand how MS can mess up simple copy+paste so badly.
We've got Win10 tablets at work with 8gb. Having teams open makes everything else slow to a standstill.
I find myself literally confirming that yes I have already scrolled down in excel during a screenshare...lets just give it a couple secs to actually scroll. You'd think we're back in dial-up era
How does a Microsoft app, on a Microsoft OS on Microsoft hardware perform so incredibly badly?
No way Microsoft is dogfooding this. If they did they'd have nuked it from orbit years ago.
Teams 2...sure. I hope they carry over zero lines of code.
Client dropped Slack for Teams. I hate it, and information exchange has dropped precipitously since everyone switched. So slow, half the time text markup doesn't work, and the UI is inconsistent depending on if you're typing in a chat, meeting, or channel.
Oh and none of the Slack logs were kept, losing years of information. (But that's not the fault of the Teams software)
I agree with this. Also how can they forget an option to “paste without formatting”? Copying stuff from other sources is extremely painful. At this point, I leave it as is. I don’t have time to micromanage each copy and paste.
Also teams has this arbitrary message character limit that makes it terrible for sharing large chunks of text (partial logs for example).
While the integrations with outlook (mail/scheduling) + teams works “well enough”, the experience of the app itself leaves something to be desired.
Can somebody explain why "paste with formatting" is so widely the default option? I have literally never wanted to paste with formatting and neither have multiple family members who have needed help with preventing it from happening.
IMO if paste with formatting was assigned another shortcut like Ctrl+Shift+V and the default Ctrl+V was without formatting, that would be less frustrating.
If you sit someone who doesn't know How Links Work in front of some text with an inline hyperlink in it, then try to get them to copy it over to another place, you end up wanting to get to this default pretty quickly. "Right click copy link address" is real unintuitive. I've never wanted the text formatting itself to come over, bold text and headings and whatnot, but since that lives in about the same conceptual space, it's a casualty of design.
It would be pretty trivial to paste without formatting but still auto-parse links. Many apps do the link parsing on the client side, so it's not a formatting concern at all.
That's fine if the text you're copying spells out the URL, but often it will be just a word(s) that are hyperlinked, so if pasted as plain text the software you paste into has no idea there was a URL linked at all.
(But I too wish plain text pasting was the default more often.)
How would that work in the case where the link display text is not the address? Normally pasting without formatting discards the fact that some text like “download other file” is a link.
History. The Mac didn’t have “paste without formatting”, and assigned ⌘-V to “paste with formatting”.
Even if it had, they might have made it the default, either to show of that styles copied over, or for consistency. If you paste a picture, you don’t lose formatting, either (of the picture, whatever that means, or any text in the image)
If you copied some text in MacWrite, for example, exited MacWrote, launched MacPaint, and ⌘V-ed into MacPaint, you likely wanted to keep the font, size and style.
Last time I built something on MacOS, this was basically just a feature of the clipboard API that each app could use independently. When copying to the clipboard, you could declare numerous formats for what was copied, and any app receiving clipboard input could state that they only accepted one format.
e.g. copy a jpeg file and you can paste it into Slack, and it will automatically add the image to the post. Paste it into the terminal and you'll get the absolute path to the file. Those sound like sensible defaults that are essentially 'context sensitive paste'.
You could copy a link from a webpage and store both the HTML version and a raw-text version in the clipboard, probably a version that used an annotated string, too.
For the same reason, yeah... this isn't as intuitive when it comes to software like Excel.
That has been around on the Mac since 1984 and applications were always encouraged to put plain text on the clipboard alongside formatted text, but we’re talking UI here, not technology. This kind of UI allows you to choose which of these you want because it turns out the application cannot always make the best choice.
And yet macOS now has paste without formatting in almost every app I can think of (it’s enough that I’d guess it’s a standard thing apps get if they use native frameworks) AND it’s trivial to remap a menu item to another keyboard shortcut across the entire OS.
Most of those are very specific versions of formatting or specialty features.
The only ones that would qualify as "paste without formatting" are "formulas" and "values" modes, and of those two I'd probably say "formulas" is a better default.
The normal case is when you’re cut/copy/pasting intra-app. Imagine if you formatted some text and then cut/paste to move it around and by default you lost your formatting.
Yep, this would be a good reason to keep it. You could probably get around this by using a separate MIME type for your app's content. If that type is present, use it, otherwise default to no formatting.
I'm not sure how intuitive that would be for users, though, having different defaults depending on where the data is coming from.
All I can figure is that research/observation showed that:
- Normal users often prefer to paste with formatting.
- Normal users will never figure out how to do that if it's not the default.
- Normal users will usually reluctantly accept paste-with-formatting even if it's not what they wanted—that is, it's only rarely entirely unacceptable for them.
- Power users will figure out how to paste without formatting.
You think Microsoft, of Ribbon and Clippy and full-screen start menu ads, and 20 different control panels for the same settings, does UX testing...? The same Microsoft that can't decide whether normal users prefer Windows, Windows Phone, Zune, or Xbox interfaces, so they just go ahead and add a little of each to all of them?
More likely they were just worried Slack was attacking their enterprise segment and killing Skype so they rushed a shitty product to market ASAP. "Embrace, extend, extinguish" has turned into "panic, copycat, repeat".
I imagine it stems from Powerpoint or Word. If I move bolded header text from the bottom of the page to the top of the page, it would be irritating to re-apply formatting. Once you have established this precedent, easy for it to infect the rest of the ecosystem.
I do actually use it all the time. We share some slack channels with external partners but email is the main mode for some others and I have to send code, interfaces, etc on occasion and copy pasting from VS Code maintains the formatting in Apple mail which I’ve found useful. No hitting the space at a hundred times to indent a nested line. And it’s easy enough to escape.
But that behaviour everywhere would drive me nuts.
I think they mean formatting as in slightly different font, color, background or goddamn underline and the like. I have never found it useful, and would be much much better with a non-default right click past as formatted option.
Your use case will not suffer since whitespace is text.
Formatting can hugely change the way text is read. It's quite common for the spacing between sections to be derived from the formatting. So removing the formatting can result in section headings with zero space from the preceeding paragraph but a manual newline between it and the next paragraph. Thus the headings essentially disappear into the preceeding text.
I've had countless other examples over the years where "paste without formatting" involved lots of manual editing of white space. Bullet and numbered lists sometimes vanish which rather matters if the text says "see point 3 above"
For the cases were software or OS doesn’t support native plain text paste I create a similar shortcut in Keyboard Maestro (macOS) or AutoHotKey (Windows).
As an extra measure I configure the macro to automatically type the text and not use the direct clipboard paste. This takes care of the situations were the app prohibited pasting.
Ctrl+shift V... How about where's reply to a specific message on a desktop/web app? Isn't that like the basest of the basics? Audio and video quality is great however, millions of times ahead of Slack and a bit better than Zoom, but ever so slightly, from my experience.
>Also how can they forget an option to “paste without formatting”
That's just Microsoft.
I can probably count on one hand the amount of times I've wanted to actually retain source formatting. But, it's the default option on almost any microsoft product out there. And, apparently, on Teams it's not an option at all.
FYI, Ctrl+Shift+V works as a paste without formatting shortcut in Teams. But for some reason I can't work out, they chose not to put it in the right-click UI.
Nothing is more painful than to watch others copy and paste complex linux commands from Teams into the terminal, and watch the shell get corrupted. Windows copy and paste has always been a mess for me. macOS seems to do it much better, but X11 middle click is the best.
While Slack displays all your organizations in a single tabbed UI, presenting you with the number of unread messages on the tab icons in Teams you need to hard switch and you never know what happens in the others. This makes Teams worse than nothing in communications because one half of the communication expects you to communicate and you are not even aware of this. You literally must jump organizations constantly , possibly needing to log in too, just to see who is pinging you.
Right! My company switched from Slack to Teams and even though we recreated all our original channels, public discussion has all but died. Having to context switch between private messaging and public channels, even though it's just another tab, is apparently just too much friction.
Also opening docs and excel sheets inside the main window by default and blocking chat while doing it is absolutely atrocious.
Swtiching windows in teams is slow, 20 years ago Microsoft knew the research on this and minimum viable response time. They ignore it and the predictable result is people don't take advantage of teams. It possibly could be good, but I want Skype back, it didn't do as much, but what it did it did well.
You can't even read stuff from other tenants if you are in a video call. Teams came for free at a lot companies I worked with and all of them have moved back to Slack and many of them are also paying for it.
My favorite about video calls is at one of my organizations I am access denied to recordings even when I participated in it. I can't attach images either.
Someone built these features. Why are you building a feature on who can attach images?? The entire mindset is completely wrong and comes from an overcontrolling enterprise mindset completely incompatible with what we expect from a chat tool.
Oh and every time I log in Teams asks whether it can control my entire device. No.
Good it asks though. So many stupid apps like Instagram and so on that assumes that the logged on user owns the device. In Europe it is very common that you are provided with a device from your work place that you also use in private. I did a password reset on Instagram with such a device. Totally unexceptable.
It's an asinine primitive mapping, that could only come from a project manager who spent their entire career optimizing SharePoint access controls to meet HR product requests.
The entire point of modern chat solutions is persistence and searchability. So the only real differentiation should be public or private channels.
My team started off piloting a self hosted Mattermost instance used by our developers and quality assurance testers. Tons of information exchange as well a team bonding.
Then they rolled out Teams for the whole company. We lost a ton of features that made Mattermost a delight to use. The way channels worked felt less intuitive, and it was just harder to care about group messages. And the worst part? A 30 day deletion policy.
Even without the deletion policy, searching only brings up matching messages without the context and scrolling back takes ages (and jumps to the present from time to time).
My last job used Teams after I had years of experience with Slack and I’m right there with you. I actually enjoy being on Slack and feel like it adds something to the workplace culture (although yes, as many have pointed out before on HN, not everything Slack/real-time team software adds is good). Custom emojis in particular, such a simple thing and yet they really build a channel’s culture. Slack feels fun. Contrast that with Teams, which just feels soulless and corporate and… “angular” is the word that comes to mind. Obviously they are both run for profit, by corporations, for work, but the feel is indescribably different to me. Super grateful my current job uses Slack.
On the contrary, I find that the total suckage of Teams means that there is no random chatter in Teams like we had in Slack because people hate using it. No memes or other random stuff. I like it.
Same for us. Our channels went from vibrant to dead in a week because notifications are somehow broken there in ways I can't explain.
The solution for us was to create multi-user chats in the "Chat" section and let the "Teams" section die the horrible death it deserves.
The notifications are more consistent in "Chat". But god forbid someone talks too much, because then you get those horrible non-native notifications that are completely broken in itself too.
It's probably the worst app I've used in years, and that's saying a lot because app quality is incredibly bad these days.
> If not even Microsoft itself writes native code for their own bloody OS then we're just doomed
I agree a native client would be great, although I assume this choice is more because Microsoft wanted it to be multi-platform across iOS, Android, Web, Mac, Linux, Windows, Chromebook e.t.c. and that would either require building it multiple times, or building it in html/js as the lowest common denominator (web).
“Microsoft Silverlight will reach the end of support on October 12, 2021. Silverlight development framework is currently only supported on Internet Explorer 10 and Internet Explorer 11, with support for Internet Explorer 10 ending on January 31, 2020. There is no longer support for Chrome, Firefox, or any browser using the Mac operating system.”
We were using Skype for Business before and Teams was a big improvement over that. It does video conferencing and file sharing well, with even collaborative editing of Office files working well. The chat features seem like an afterthought so if you're comparing it based on that I'm not surprised it's that bad.
As one "for example", that's the product team that couldn't figure out how to stop repeating AD logins with invalid saved passwords for 5+ years. Which invariably led to a system you were signed into somewhere locking your account every password rotation.
An extremely low bar, it was incredibly poor software. The Teams migration was great compared to that, even for messaging.
For VC and file collaboration Teams seems good in absolute, for messaging it seems good only relative to that. Messaging feels like a third-priority feature in Teams. If you're coming from a good messaging experience and that's what you mostly use Teams for then it's no doubt a really poor experience.
I worked at a game company that was moving from google enterprise (gmail, docs, etc) to office be use our owner organization used office. Everyone fought hard to keep slack because teams is so bad. We got to keep slack but had to adopt office and it was a disaster. Outlook web and app act completely different, the mail web and app act completely different. the way to edit and share files was very confusing and always had permission issues. We were told we’d keep our email history, then the last 2 years of our history, and then finally they were unable to migrate the history and we lost years of emails. It messed the company up so much, I’m sure it’s one of the contributing factors for why the company was closed 6 months later. Like we were at the end of a 2 year development process going into soft launch, but this migration crippled production and the parent company never took responsibility.
My 2cts with teams. Multiple clients use teams and sent me invites with team links.
There seems to be no way to open or see the meetings directly within team. I always have to open my mail, click the link, go to the website, click on open in teams and only then will it open the meeting.
We use Teams at my University. Generally if something University-sponsored outside of the college of engineering wants to make a chat about something, they use Teams. CoE uses Discord, fortunately.
Easily my least favorite chat app, save for those that break basic functionality as their core product (Snapchat). Teams doesn't seem to understand that organization admins might want to see user names in a different format than users. Everyone's name is Last, F., which makes sense from an administrative standpoint but needing to click into someone's profile to figure out who they are gets old _very_ fast.
The only selling point that Teams seems to have is "we're already paying for it."
Our company (we'll call it Monsarno) was bought by a certain German aspirin company, and our Bavarian overlords are slowly forcing us from Slack over to Teams. It's a nightmare, and very few groups have made the transition willingly.
Not sure what everyone issues are. I use Teams (in the browser) on Linux and it works fine under both X11 and Wayland (with some work). A bit less polished than Slack but it also has a lot more features.
The worse thing about the desktop/Electron version is that they are really bad about keeping the electron version updated so the browser version will support screen sharing on Wayland while the desktop app doesn't.
In my experience, most people in engineering orgs default to hating Teams far more than it deserves. and loving Slack far more than it deserves. This has roots in Microsoft's history as computing Bad Guy and Slack's pre-Salesforce history as Scrappy Indie.
Teams is more complex than Slack but also does more, but it's also not a complete superset of Slack, so unplanned/unguided transitions from Slack to Teams tend not to go well. Like any sort of knowledge management change, it can go well with empathy, planning, and care.
> Teams is more complex than Slack but also does more
Perhaps that's the problem. I generally prefer the right tool for the right job, and once I have a tool that works, the effort to switch needs a compelling reason.
Adding a "hammer" function to a screwdriver makes the screwdriver worse, it doesn't provide that compelling reason.
Adding multi client access, stored chats, and even some formatting, were compelling reasons to switch to slack over irc.
In reality the Linux and web versions are not similar to the actual Windows client. For instance the Linux version is stuck to 2×2 video streams at best, doesn't support background blurring, audio/video quality is inferior, doesn't support sharing a single window, no breakout rooms etc [0]. None of these are of any considerable importance to me but Linux or the web has never been priority for Teams nor will ever be. In fact I will not be surprised if/when Linux is dropped completely when transitioning to Webview2. Judging by the "PR-speak" [1] this is what probably will happen anyway.
It's user interface is unintuitive and messy. I find it difficult to find the context I want.
Search doesn't seem to work.
It takes a long time to load.
When it eventually loads, it pops itself up in front of whatever I've opened and started working on (whilst Teams is busy loading) to take all my keystrokes until I notice the keystrokes aren't showing up in the program I was already using - I've seen at least one person's password entered into a chat session because of Teams "grabbing the front".
And, finally, Teams has taken the initiative to redefine "full screen" such that even that unambiguous terminology is now meaningless. Full screen now means "zoom in, just a little bit". Fuck you Teams.
Screen sharing / video conferencing works fine, however. Except the full screen thing, so even the decent bit has a large caveat.
My apologies for the outburst, but I had to get it off my chest. Teams fucking sucks.
Audio mixing is poor compared with Zoom, any background noise on an active microphone will cut out another person speaking.
The controls menu keeps changing. Click on the "raise hand" icon and it disappears, you can't "lower your hand" until it reappears some random time later.
Why is it that in every one of these meeting apps, speaking causes them to totally garble any other person speaking simultaneously? It's like they go "oh you are speaking lets downgrade all others to 1kbit/s". Stop with the byte pinching and just give us the full fidelity sound like I'm using TeamSpeak, it's fricking audio.
I think it's because of echo cancelling technology. In software like discord you can disable it and it's way better when people are talking simultaneously.
I started writing a long-winded thing to enumerate the problems with Teams that no product person at Microsoft will ever see, so why bother? It's a terrible product. The purported sticker price for enterprises disguises the costly loss of productivity due to this mess. It's just a godawful mess.
I haven't worked on a search product, but I've worked at small shops with bad search products (one's business was even that product).
Search is hard when you don't have lots of training data, data is poorly organized, you have mostly tail queries, and people aren't used to you search engine's quirks. Search results are also bad when you're balancing quality with yield (as in revenue).
Google mostly doesn't have these problems. It has loads of people searching for head queries, so results are continuously being tested to death. Website owners put some effort into making their content accessible to Google with SEO, and people are used to searching with Google, so they've learned a few tricks for less popular queries.
Local search and corporate intranet search have none of that. You're basically whatever Lucene does out-of-the-box.
Teams has worked great for me. It's comparably fast to Slack. Calls and screen sharing work perfectly. I am not sure what is different about my situation versus the other users here. I use the native app on Windows, and my org currently has channels and most integrations disabled (Outlook, OneDrive).
Tools like Slack and Teams are focus-killers and should be banned from all companies that want to work efficiently. The synchronous nature of these tools and the chatty blather they encourage should be avoided by all serious knowledge workers.
The "chatty blather" is a culture 'problem' (assuming you see it as a problem), not a tools problem. Where I'm working now we only have channels directly connected to specific projects and only people working on those projects are on those channels, and there is no project irrelevant chatter happening. There are no company wide channels and no 'off topic' channels so very little social banter takes place on Slack or Teams.
Personally I think the problem is over-rated and wouldn't mind if there was a bit more off topic chat going on in our Slack/Teams.
What is the purpose of the tool then? What improvement does it have over email?
The main problem that I have with these tools is the increased number of distractions. There is an expectation when using a chat tool that someone will respond promptly, but this rarely is useful for the person that’s receiving the question.
For most knowledge workers, frequent distractions come at a very high cost. Notions that we are good at multitasking are completely false. Encouraging the use of these tools is contrary to the goals of deep intelligent work And in fact can encourage poor planning and time management.
One is that everything gets sorted under the right project subheading. Discussions about Project FooBar end up in a different channel than discussions about Project Blork. The second is that I can just post on the Blork channel and know that everybody currently connected to project Blork will see it. Equally if I'm not actively working on FooBar I can easily ignore everything connected to FooBar, and just scan through what's happening every other day or so. I personally feel it's useful keep an eye on what is happening in projects tangentially related to what I'm working on without being CC:d on every project related email sent, and Slack makes that easy.
Of course all this can be replicated with mailing lists, email filtering, and decent threading support in your mail client, and perhaps that might even be better, but for whatever reason the tools for easily doing this aren't really being pushed. I'm sure you could build some sort of tools on top of email that gives you most of the benefits of Slack but with a slightly less synchronous feel.
There were tools called bulletin boards or wikis created decades ago that can accomplish what is described above. All of these chatty tools require discipline by those making posts to not refer to other projects within the silo of the channel. I’ve found this to almost never happen. Email allows for normal conversational encompassing communication method that does not rely upon siloing information about projects into their respective channels.
For example, if Blork and FooBar Projects are related In a comment that is made in one of the project channels, it is not easy to navigate their relationships in these tools Without explicitly adding tags to refer to the other channels. All these tags then create a spiderweb of useless links for the most part, and the information flow is weird and difficult to follow in many cases. This model can be advantageous for example when referencing checkins or other tickets within comments of a bug/story reporting system. However, bug reporting systems typically have fewer parties involved in the comments, so things don’t get quite as out of hand.
There were tools called bulletin boards or wikis created decades ago that can accomplish what is described above.
Far be it for me to defend Teams, but one thing it does kind of right is to automatically create a wiki, a project tracking and a file share page in addition to the chat space for each project so that you can, if you want, use the right tool for the job.
That being said I worked at places a decade ago that tried to do the internal bulletin and wiki thing for their projects, and for whatever reason, it never worked anywhere near as well as I've seen Slack work. So while I agree in theory with many of the complaint levied against Slack as a productivity tool, in practice I've yet to see anything work better. But it is also clear that, for whatever reason, I haven't experience many of the time wasting antics that other people seem to be describing.
Simple … email … I choose when/if I will respond on a schedule that I define and My response can be more complete therefore avoiding many of the roundtrips that these tools support and encourage. If someone needs a meeting, they can schedule a meeting from open time that I have provided in my schedule that is shared to my team.
I guess the challenge for MS wasn't to make native app on multiple platforms but to beat the competition i.e Slack as fast as they can.
They operated like a startup. Used electron, reached to market fast, gained traction. Now they can thing for performance improvements.
Note: Most of the users using MS Teams are not startups but listed companies. That's a constant source of revenue. Tapping that segment with not so shitty electron app has worked wonders for MS
My 2015 MacBook, despite being old, is generally just fine for my web development work -- the one notable exception is Teams, it is almost unusably slow for me. I hadn't yet investigated whether it was a RAM/swap issue or other. But it's the only thing I have to regularly use (per employer) that gives me trouble.
I have a top of the line Thinkpad with Windows 10 Pro, 64 GB of RAM and a 6 core Xeon CPU. If it makes you feel any better, Teams is slow and annoying on my machine as well.
It had better use less memory. Currently it runs at about a gig on my machine, without any meetings in progress.
This is about 8-10 times heavier than the Skype for Business client was.
WebView2 looks to be a great choice instead of Electron, now that they're shipping Edgeium everywhere. The old IE WebBrowser control has been a non-starter for a while.
Blaming a poor user experience on “being terribly written” seems to be nearly a tautology except that I’m sure there’s been beautifully written software that was otherwise as bad as Vogon poetry.
Teams tries to do a lot of functions. Maybe too much?
On the offchance that someone from Microsoft is reading, I’ll take this opportunity to again express my disbelief that it’s impossible to print a chat or export it in any way from Teams. Even copy & paste is broken if you try to get more than a screenful.
Here is why this functionality is important:
* When a colleague leaves the organisation, you can’t search for a chat with them any more, so the chats are effectively lost.
* When people chat in a meeting, that meeting becomes the only place the chat exists, and do you really want to have to keep years worth of old meeting items in your calendar just to avoid losing that chat? And how are you supposed to organize calendar items as a store of conversations anyway?
* Its the most basic level of interoperability. How can you take a product seriously when it traps your data like this?
Electron and Edge Webview2 are basically the same: they both wrap Chromium in the end, possibly with some downstream changes. So this is primarily a branding exercise, and maybe and admission that Microsoft isn't upstreaming some improvements to Chromium.
Random complaint but Microsoft apps on Android are the only ones I use that simply do not behave as they should. Teams captures the audio channel and I have to manually close the app before anything else can play audio. Notifications don't work when you tap them, instead just opening an empty shell when I then have to close manually (Teams and Outlook do this).
It's very frustrating that a company of that size and tech 'prestige' can't make native apps and instead rely on these crutches like Electron. The difference is very noticeable in the user experience.
Hopefully they'll make it easy to be signed into multiple Teams accounts at the same time. Currently, you have to use a script in order to launch multiple Teams instances [1].
With all the hate here, where's the web-only, WASM zoom/live/meet killer?
Although it wouldn't be easy, it doesn't seem that hard either! It almost feels like a summer project for interns could do a better job than the current batch of video conferencing services at the moment.
Requirements:
- No install, from the web
- No login
- There is no 3rd requirement
Is that actually hard to build? What am I missing?
Teams is a compliance product for some CIO to check a box and get their kickbacks and bonuses. Its features center around corporate control of conversations.
So whoever has a negative comment about usability has absolutely missed the target customer for Teams: it's not the end user and certainly not software people.
The teams UI is so fragile that I often end up reacting an embarrassing emoji on random messages.
A single meeting usually drains the entire battery.
I can't imagine how this kind of application gets passed QA and shipped.
I sometimes wonder if one of the issues is all the testing being done on very powerful machines. "It's plenty fast on my machine!" is the new "It works on my machine!"
Well if it’s prebundled, I guess it will be properly audited and hopefully less evil than Zoom.. which has been known to install services on your PC that are easily exploitable.
Native apps area always for the most part going to be better than web app, electron is a poor choice of technology. JavaFX would have been better for cross platform development if not C++.
I completely and utterly think it's MS abusing their monopoly position (again). Slack, Zoom, etc, all cost actual hard money.
Microsoft released Teams for effectively for free, paid for by existing (extortionate) subscriptions (that are never in the public domain). Now, despite the product being almost _universally_ hated by its users, it's number one.
I think so, yes.
I could also imagine that business people:
1. see effort in integrating Slack/Matrix/..
. into their landscape
2. think MS is a big name and thus will build a proper product
3. see no big difference in terms of functionality.
That's what I mean by sending JSON messages, but I'm asking if there is a way of directly calling native code from the JavaScript interpreter, synchronously passing pointers to JavaScript data structures back and forth, not just copying strings back and forth between separate processes through an asynchronous message queue.
Like Microsoft's deprecated COM/OLE/ActiveX, or Apple's Objective C / JavaScript bridge, or what SWIG does for JavaScriptCore, for example:
For example, how can I get direct read/write access to the pixels of an html canvas or the memory of a JavaScript byte or float array, instead of serializing images as png files or base 64 encoded strings, or buffers of numbers as decimal text json arrays?
So far I have not yet investigated what can be done with that. It looks a bit promising (and complicated).
Microsoft's deprecated control had the mshtml document interface and that was indeed very powerful.
The Async script capabilities give you a lot of power, but I agree that the asynchronous part of it is a huge pain and is causing me extra headaches as it is basically preventing me from creating the API I want to create.
Of all the things to fix with Teams, Electron isn’t it. Our company forced us to switch from Slack to Teams. We have it the benefit of the doubt but are regretting it every day. Collaboration is down vs Slack and we’re all less happy. Sounds small but little things effect morale.
Native apps or die. I won't use anything based on Atom or Electron.
The reason is that these "cross-platform" applications on top of web browsers are basically complete operating systems emulated on top of the underlying OS. It's worse than turtles all the way down; they're sea urchins: fragile, prickly, and lethargic. And these memory-hogging leviathans multiply faster than rabbits so developers don't have to get their "hands dirty with details" like fast, efficient, proper software.
Just because someone can write a ray-tracer in BrainFuck doesn't mean NVIDIA/AMD/Intel should steer the whole industry to using something impractical because developers get excited about all of the "possibilities."
