Hacker News new | past | comments | ask | show | jobs | submit login

The issue with this approach, is whether those "features" are real, actual features improving people's lives or just bs.

Slack is a usual target of derision around these parts, for example. I don't use Slack, but my client has me use Teams which seems just as bad, maybe worse.

I really wonder what those great features of Teams are that have a chat application lag on an 8th gen desktop i5? And I mean lag for basic UI things, like move the mouse around the list of contacts. When nothing else happens on the computer.

I remember when I was younger, at the beginning of the 2000s, I used to chat with friends on whatever IM clients we had at the time. On computers ridiculously slow by today's standards. I used to have a 1.4 GHz Athlon until the late 2000s. Single core. 256 MB RAM. The chat client would never ever lag. I guess we didn't have emojis at the time, but smileys were good enough. I'm not really sure that wasting all these resources on that is such a good investment.

There is a noticeable delay between my key press and the character showing up in Teams. Sometimes the characters don't show up in the right order (how's that even possible?! and yes, it only happens in Teams). That's just text. No 4K screen sharing of an AAA game. No live UHD camera with 32 people multiplexed in ultra quality on a 8k screen or whatever. Text. We used to have this down. What happened? What features do we have now that justify this terrible regression in UX?




You're looking at teams like a chat app, but teams is more like a platform that happens to offer a chat feature. Yes, it does chat, but it also does audio/video conferencing, and document sharing, and contact management, and meeting scheduling, and a bunch of other features. And those chats aren't your grandpappy's text-based IRC, they are rich text, with complete archival and full text search, and a graph API to access all of that. On top of that you have the first party add-ons, like Microsoft Viva, which turns it into a blend between a wiki and a social media platform and an e-learning platform. And then you have third party addons, literally hundreds upon hundreds of them, which integrate all kinds of SaaS products right into the teams UI. Frankly it's a miracle teams and slack work as well as they do, given how much they're asked to do.

The reason teams and slack are so much slower than the chat products of old is because they are not the same product category at all. It's like comparing microsoft word to notepad++. Yes, word is clearly an inferior way to quickly edit a plain text file, but obviously anyone complaining about that is missing the point of word.

A fair question to ask is whether we should have platforms like slack and teams. Why are we rebuilding a tiling OS inside of a webpage, and then wrapping that webpage in an electron container, and then complaining that it gobbles up RAM like crazy?


> A fair question to ask is whether we should have platforms like slack and teams. Why are we rebuilding a tiling OS inside of a webpage, and then wrapping that webpage in an electron container, and then complaining that it gobbles up RAM like crazy?

I agree with you. I think this is exactly the issue.

I get that Teams and the chat apps of old are not the same category, but I think it's a fair question to ask whether this new category is relevant. MS Outlook already had a calendar which, somehow, loaded much quicker than the one in Teams. Even the calendar in Outlook web loads so much quicker than Teams it's not even funny.

I also understand that there are much more functions in Teams (which people may or may not use), but those are all supported by the backend servers at Microsoft, they don't run locally. Teams is basically a web-browser. So I'm not sure that this functionality is an excuse for what are local UI issues.

When I type in the message box, I input text. Maybe some rich text or something, but still, nothing that Word 97 couldn't have handled while being blazing fast on a 486 (aside maybe from emojis, but they can't possibly be the reason why everything is so slow). The same can be said about the lagging animations in the contact list. These all happen locally, with nothing to ask from a complex web service or having to implement some complex function.


There’s also the latency issue: https://danluu.com/input-lag/

My normal desktop has a 240hz monitor and going between that and 60hz is an immediately noticeable downgrade in performance. Why did we accept 60hz as good enough for so long? Even CRTs commonly ran at faster refresh rates. IIRC 1600x1200@90 was what I ran back in the Pentium 3 days on a 21” Sony CRT. We still don’t have useable 4:4:4 4k@120hz on something like a 32-42” screen available.

Anyway, I agree that web tech is easy to develop (not that I thought Visual Basic was terribly difficult comparatively) but there are too many layers of abstraction these days. Can we not make sufficiently advanced compilers to make these really efficient? If not, do we need to go back to tinge drawing board with libuv and event loops? Maybe interrupts and manual memory management really were better. Java for GUI apps certainly hasn’t done much to show that it’s a better solution.

It’s funny but sad how these days, apt upgrade runs so fast, and compiling kernel modules happens extremely quickly, but it takes 10x as long as it did 20 years ago to schedule a calendar appointment with someone because GCal in a browser is so slow. Slack compared to curses-based IRC clients…woof.


Well, yes, there's the display latency issue, but I think that given the state of some programs, the display lag is really way, way down the list of problems.

I have a 60 Hz display, and an IPS one at that, which doesn't even try to pretend it's fast. Still, my terminal window doesn't lag behind when I type. Teams does, every time.

> Java for GUI apps certainly hasn’t done much to show that it’s a better solution.

Meh, I use a Jetbrains IDE almost everyday, sometimes even with Rust and pretty much everything turned on. Even on my almost eight-year-old MBP input never, ever lags like Teams does on a 6 core i7 with a "gaming" GPU. It's not as smooth as a Linux terminal, but it's never irritating.

> It’s funny but sad how these days, apt upgrade runs so fast, and compiling kernel modules happens extremely quickly, but it takes 10x as long as it did 20 years ago to schedule a calendar appointment with someone because GCal in a browser is so slow. Slack compared to curses-based IRC clients…woof.

Exactly. And what drives me up a wall is seeing people being resigned. Some act like they don't even notice this. I guess we may moan until we're blue in the face on HN &c, but if "regular people" don't care, no one's going to do anything about this.


IDE customers care about that latency lot more than slack/teams users do.

A lot of non technically focus look at keyboard while typing, they won't even notice the lag if they are not looking at the screen.

If there is enough customer demand/push latency is not that difficult to solve even on electron, browsers that they based on don't have this latency problem after all.

The market economics dictate features, well built apps are not what is necessarily selling.


Just because its a feature you don't use does not mean its a feature others don't use. I see this all the time in programming IDEs where I don't know about or like the function of a feature but the person next to me swears by it and uses it daily.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: