[Solar19]

The Teams client is built on Electron? Why?

Developers need to stop building slow applications. This is ridiculous. It's 2019 and software is slower than it was in the 90s.

It must take an enormous number of CPU cycles to execute simple tasks in an Election-based app. It's just incredibly inefficient. I heard similar things about Slack – that it was built on Node, maybe Electron, and was dog slow, especially to open. It's frustrating that developers are bringing the slowness of the web to the desktop. Just build proper desktop applications using native desktop APIs.

[toxican]

It's built on Electron and still no native Linux client. There's a web version, but you can't join meetings or screenshare. There are 3rd party wrappers for the web version that enable meetings, but you still can't screenshare.

At the very least their web version needs to have parity with the desktop application. It's 2019, browsers can handle voice chat and screensharing!

[swebs]

>It's built on Electron and still no native Linux client

Remember this next time their PR team tries to pull another round of "Microsoft has totally changed you guys, we swear! The new Microsoft loves Linux"

[bgdnyxbjx]

https://www.neowin.net/amp/microsoft-teams-might-be-coming-t...

[pacoverdi]

Well, there is an unofficial 'snap' package for Linux that enables all features including screen sharing. I don't remember the name but it must be easy to find.

Edit: probably https://snapcraft.io/teams-for-linux

[briffle]

you can view in a screen share, but not send your screen.

[dzhiurgis]

Can Slack do screenshare via Chrome? I know you can see others screen, but can't share mine.

[utopian3]

Wow, I’m pretty sure Hipchat is built on Electron and has had all these features for years! Microsoft must really be struggling

[youdontknowtho]

"Microsoft must really be struggling"

Not really. They are making more money than ever. They don't have customers asking for a Linux client in large enough numbers. That's all it is.

[rekoros]

What’s Hipchat?

[thethirdone]

What information are you expecting that wouldn't be easier to find by googling Hipchat? I can't understand why anyone would ask this.

[sebcat]

No one is asking ”What’s Microsoft?” though.

[cwyers]

Yeah, Hipchat is EOL and Teams has a market. Now, I _hate_ Teams, but it is nonobvious that Hipchat has a better notion of what features are necessary to be successful.

[grzm]

https://en.wikipedia.org/wiki/HipChat

[underwater]

It makes sense for Teams. The app is a chat client, sure, but it also contains the entirety of Office 365 and a third-party app platform. Chats can have tabs with Excel documents, wikis, polls, etc.

By leveraging browser technology they have a platform that is incredibly extensible. Building that from scratch across iOS, Android, Windows and macOS is not feasible. And the benefit of having people reach to the tools at hand and strengthen Office's position outweighs the performance penalty.

[Aaargh20318]

> Building that from scratch across iOS, Android, Windows and macOS is not feasible.

Building a few chat apps is not feasible for one of the largest software companies in the world ?

[dan-robertson]

This misses the point. The parent isn’t talking about just building a few chat apps. They are talking about building a chat app which can have basically any ms office thing embedded inside it.

[Aaargh20318]

Not real office, web-based office. Why not make a native chat app that opens Office files in the real full-featured Office ?

[WorldMaker]

Office is going the other direction and moving more of the "full-featured" Office components to React Native and sharing them with the web. Teams was built as a quick spike by the SharePoint team to prove they could slackingly build a chat client. It might not be a surprise if it moves to React Native in the future.

[baud147258]

Office 365 could just as easily be opened in the browser, instead of slowing down the app for all users. I mean it's a chat app, how many users are going to need to edit a document inside the app?

[icebraining]

Microsoft had something called OLE just for that kind of embedding, and it was already cross-platform, as part of Office.

[gitgud]

This has been discussed many times here... of course running a Chrome instance is inefficient but in some cases that's acceptable. Especially for the gains in cross-platform compatibility and reliable user interfaces.

Almost no other platform can guarantee that a UI elements will look pretty much exactly the same on all different operating systems.

Most people don't mind the extra RAM consumption for some applications... as long as the app works!

[naikrovek]

Who cares if an application's UI elements look the same across platforms? I want it to work on the platform I am using. I simply do not care what it looks like on someone else's platform, and I especially do not want to pay a performance penalty so some designer can have a virtual feather in their cap over it.

[dleslie]

I prefer native widgets to whatever application-enforced fad of the year is current.

Apps are lauded for providing "dark mode" now; when ten years ago I simply switched GTK themes.

To say nothing of accessibility.

We've gone way backwards in UX.

[mort96]

To be fair, dark GTK themes don't really work. I say this as someone who uses dark GTK themes. Far too many applications end up with dark text on a dark background, and Firefox applies your theme colors to websites so websites also end up with dark text on dark backgrounds. At least a dark mode created by the application's authors usually works.

[iforgotpassword]

This has been a problem since forever. Even on Windows 95 it was like that. Probably before that. Windows does have special values for system colors, like text, window background, text background etc. But for some reason, a lot of programs ended up setting the text color explicitly to black and leaving everything else at the system colors. So you better left the color scheme at default. Which is probably fine for the average user, but there were these high contrast schemes which were white on black. People who actually had to rely on this must have had a bad time. Just how these schemes also increased the font size. Doing that, or increasing the system's dpi setting guaranteed that all text in every application would be truncated.

[michaelmrose]

Firefox is a special case of stupid as far as themeing. Fortunately it's possible to both make Firefox's ui dark with css and make Firefox use a light gtk theme for websites with an env variable which is the logical choice.

[bdamm]

Absolutely. Developers can pick from many native-widget frameworks in pretty much any language, heck I bet there are even Qt bindings for node. But there are just so many people doing web development, it's probably a hiring/design issue in that hiring web developers and designers is just so much easier than hiring whatever people know the GUI framework that's driving much of the code.

[rtpg]

There's also the fact that the UI tools for web development are mostly way easier to use than Gtk or Qt.

Even "simple" stuff like Tcl/Tk is not trivial to get working easily or well.

HTML + CSS + something like React is miles simpler than writing something for Gtk. Qt has QML now but the C++ Qt bindings are _pretty hard_! And after all that work you don't (by default) get an app that resizes as nicely as the HTML/CSS box model does!

I think that WxWidgets has one of the better usability stories for cross-platform native, though.

If someone wrote a good feeling UI library that generated native UIs and had good JS and Python bindings, so many people would be happy to use it, I think. But right now, despite all the shortcomings, web tech is pretty easy to prototype in.

[scottlu2]

This is an important point. Being easier to create means faster to market, faster to create new features, easier cross platform, more value for users in less time. Not all apps can be web based but for those that can be, faster dev time has become a competitive requirement.

[calvinv]

have you tried using OneNote in dark mode, it actually feels dark, like you can't see anything

[gitgud]

My opinion is that the OS should not be responsible for providing native elements to the application. If this is true then the application is tightly coupled to the OS implementing these components.

In a perfect world, every application would have minimal dependencies required by the OS, and completely encapsulate their runtime and UI components, making them very portable... which is basically web apps, hence Electron's popularity...

[GhostVII]

I like the application to be tightly coupled to the OS, because then my applications have a consistent UI. All of my GTK apps look great, because I can change the theme for all of them with a single command. With one script, I can switch my entire system from dark mode to light mode, and have all applications have the exact same color scheme - can't do that if every application has their own implementation of the UI components.

And different systems have different UI requirements, so I don't think it makes sense in many cases to have the same UI between them. iOS and Android, for example, have very different standards surrounding what buttons mean, and how the navigation should work. The back button on Android, for example, completely removes the need to a back button in the application, while in iOS it is still required. And of course if you are making an application that runs on both touch screen devices, and devices with keyboards, the UI should definitely not be the same.

[cameronbrown]

And then we end up in GTK hell: https://stopthemingmy.app/

At least the web platform is open enough to do this and still function.

[michaelmrose]

>The problem we’re facing is the expectation that apps can be arbitrarily restyled without manual work, which is and has always been an illusion.

Except for working pretty well on most apps

>However, if you change things like stylesheets and icons, you should be aware that you’re in unsupported territory. Any issues you encounter should be reported to the theme developer, not the app developer.

Themes are rarely problematic and it would take 10 seconds to check if one supposed it to be problematic.

They could perhaps work on solving actual problems.

[GhostVII]

That's really not a hard problem to solve though, as an application developer you can just have a default theme for your app, and have some checkbox somewhere letting the user use their OS theme instead of the app default.

Or you can just accept that whenever you let someone configure the UI in an advanced way, it is possible for them to make the UI more confusing. Just because it is possible for someone to mess up your app with a bad config, doesn't mean it is best to remove any kind of configuration at all.

[gitgud]

Yes, there are benefits to having the OS supply the components; switching themes, familiar design and probably performance gains.

But, the trade off is simply unpredictability. The app is assuming that the OS has all the components it needs, at the correct version etc. Not all OS's have all components you think, which leads to unreliable user interfaces, which may work for small applications with only a few OS dependencies, but as the app grows the reliability decreases...

You're correct in saying the UI should not be the same on every platform (iOS, Android, Windows). But in my opinion the app should encapsulate it's UI and share as little as possible with the host OS.

[blub]

All major OSes have better, faster, more flexible UI components. These were invented for native apps.

If a component is not available, it means it's not appropriate for that platform or not part of the UX guidelines.

[GhostVII]

That's why you build on top of a layer which ensures the OS has the required components. If you build on top of GTK, you know your application will run on any OS with that GTK version installed. Or if you build on top of Android, you know they will make sure that the button component still works on different versions of the OS.

[blub]

That's the point of the OS, offering a standard runtime environment.

Your "perfect" world isn't. It leads to a fragmented landscape of competing runtimes and UIs, is inefficient and results in extra implementation effort.

The JS community can't even be trusted to be stewards of a left pad library, never mind UI environments.

[dillonmckay]

This sounds like Java Swing.

[profalseidol]

Coupling is not bad in itself. Depends on what you want to achieve. There's likely always a trade-off.

[md5person]

> "Who cares if an application's UI elements look the same across platforms?"

Designers.

End users simply want a functional, working product. Polish on top is a nice added bonus, but these days it's been turned into the focal point of software development. A Teams/Slack-caliber project begins with product requirements, immediately followed by design and UI mocks - the software/tech always comes last.

[naikrovek]

Designers are given too much leeway. They care about a consistent UI across platforms; fantastic -- no one else really does.

A computer program is a tool to convert data from one form to another. FULL STOP. Unnecessary added complexity, on top of that data transformation, is wasted effort, wasted time, wasted energy.

Software development has caused so many problems for itself because of things like this. People forget so quickly that programming is not the job! Solving the data transformation problem is the job. Effort spent that does not solve the problem is wasted effort, and we've made a fucking industry that churns out far more waste than product.

[baroffoos]

The problem comes when you design a UI and then someone else goes to use it and the font in the selects is a different size and ends up cut off. Also windows users regularly complain at me that the ui looks ugly but its just the windows default ui elements they find ugly

[Karunamon]

The problem with regard to RAM consumption is the tragedy of the commons. One electron app is okay, but once you're running up to ten or more of them, the resource usage gets out of hand.

[lokedhs]

I remember back in the early 2000's when everybody was complaining about Java. That it was “slow”, and “used a lot of memory”, and that its UI “is not native”.

Now it's all JS and Electron and every single complaint people used against Java is an order of magnitude worse and everybody seems to be happy about it.

Progress have definitely been going backwards.

[hateful]

I know this doesn't speak to your comment, and is also a bit of a rant, but I would clarify that "tabs" in this respect are not like "tabs" in your browser, where you can have multiple "things" open at the same time. As soon as you leave the teams tab, that application/file is closed.

So if you have an excel file open in teams (which can take up at least 10 seconds - which does speak to your comment!), and want to go back to a channel or chat, you're actually closing that file.

Granted you can open the Excel file not in teams, but this is just an example of how being locked in one window where the tabs aren't your open items, but rather possibly open items, is counter-productive.

That brings me to something else that I find strange, that with every new piece of Windows software over the last 10 years, it seems like Microsoft forgot that it's called "Windows" for a reason. The big deal about Windows was having multiple WINDOWS. And every time you take that away, you stray further from productivity. Don't even get me started on multi-monitor support over the years! /rant

[untog]

You can make an efficient Electron app, just look at VS Code.

[blub]

Based on empirical evidence, it seems that humanity can make just one sort of efficient Electron app, and that slot's already filled by VS Code.

[andrewnc]

My VS code was using 10 GB of RAM today... It's better than other electron apps, but I would argue still not efficient

[aembleton]

Did you open a 10GB file in it? Mine is using 200MB right now with a PHP project open in it.

[executesorder66]

Is that project 200MB of PHP? Because 200MB of RAM seems obese at best for a text editor.

[dijit]

I agree with you. However I don’t think it’s fair to call VSCode just a text editor. It’s not quite an IDE, but it’s a weird middle ground.

The nearest IDE I can think of is kdevelop or jetbrains. kdevelop is disturbingly light, but jetbrains consumes considerably more resources than VSCode. (And for good reason. They tend to do more)

[paggle]

Clearly whatever people at MS made Teams do not talk to the people who made VS Code

[bla3]

I'm not a fan of electron, but it's possible to build fast apps with it. Teams who build slow apps with electron will likely build slow native apps as well. Slow software is usually not the tech stack, it's the team.

[ShinTakuya]

I don't think it's impossible to make efficient electron apps. Vscode and discord, for example, tend to be reasonable in my experience. I think it's just that the time saved by not having to maintain cross platform software isn't being reinvested into performance/memory optimisation.

Moreover the ease of developing electron apps has opened the desktop ecosystem to web developers who more often tend to have bad habits because of how forgiving most web dev is.

[youdontknowtho]

This is the one criticism that I actually agree with. Electron apps are pretty painful.

If they are going to keep doing this they need a way to compile the things to native binaries. I don't know...something.

I personally get really kind of weirded out when I see simple software load Node. Adobe, I'm looking at you.

I'm really hoping that the cross platform dotnet stuff becomes a viable option now that the XAML stack has been open sourced.

[pjc50]

It's a Slack clone. Slack is built on Electron so Teams must be.

[Ondoher]

I have a Karaoke project that runs in electron on a raspberry pi. Electron is not inherently slow. It runs on the Chrome V8 engine, which is blazingly fast.

[hnbroseph]

For one, nobody wants to use C++

[StreamBright]

Have you seen that picture with UI latency for code editors? I can't find the article but it is ridiculous that we have laggy software that uses insane amount of memory and CPU time. If we are serious about easing on the climate change we should start with bloatware that is the majority of the software industry nowadays.

[villain]

It's a shared code base with the web application.