Hacker News Reader

Comment by manquer | Hacker News Reader

It is actually.

Software development can either focus on new features made possible by complex inefficient abstractions or can be focused on efficiency in limited hardware.

Focusing on efficiency will always come at cost of reduced features.

As long as hardware is not limiting developers are going to focus on new features giving them the edge, when hardware growth slows , performance will become a factor for competition.

Customers are today paying for features, when they for performance industry will also shift.

Electron has enabled a whole host of apps to become possible despite it's obvious performance limitations. I would rather have those poor performing apps rather than just few perfomant native apps.

View on HN

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?

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.

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.

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.

> Focusing on efficiency will always come at cost of reduced features.

This is probably sort of true, but it's way worse than it has to be. I feel like with just a little more effort, a little bit of a higher standard, we could get massive improvements.

Electron is great for the problem that it solved. But what if they'd started from day 1 thinking about performance? Maybe they would have taken a year longer, or whatever, but I'd imagine it could be 10x-100x faster/lighter. Perhaps not, but there's plenty of software where that is the case.

The problem then is that someone would release a garbage slow version sooner, and we'd all be using that - and imo this is the more serious issue. When something like electron comes out we need to push back wayyyy harder, the industry needs actual standards.

Things like maximum viable latency for UX - it is insane to me that software deployed on extremely powerful systems can have 10s of milliseconds spent on something like typing a character, or even longer! But we have no quality standards in this industry, so it's I guess hard for everyone to say "this is below our standard".

I like your comment, but I think Electron is only part of the problem. IMHO, the bigger part is that all these apps are built using JavaScript and all the SPA style frontend frameworks. Heavy Javascript-based UIs aren't slow because of Chromium or V8... I wouldn't blame it on them. It's the frontend frameworks and libraries, their design and abstractions, and then as a consequence, how they are used by developers.

Yeah, I agree fwiw. I think that most engineers have a very weak idea of "fast" vs "slow". I've met people who think JS is really fast, or that Go is like C++ level speed. And we wonder why software is so slow.

Rhetorical question: how much e-waste do you think Wirth's Law is responsible for?

I personally don't think that people should ever have to buy a new computer until their use-case changes. At most, they might need a battery replacement after a few years. The idea that people need to replace a machine every six years to keep doing the same tasks is backwards.

Hardware is, and should be, limiting.

100% this.

All my private computers are getting around 10 years by now.

VS, Windows 10, Netbeans, Eclipse all work just fine.

Naturally I am not using Docker to start a Python web server.

I am yet to see an Electron app do something that wasn't already done by some older app before it with less lag. All I've seen so far are various flavors of the same basic chat/conference features in slightly different pricing models. Or apps that exist just for the sake of claiming something has a native app( while being just a wrap around the website).

Reply on news.ycombinator.com