Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Electron-based apps cause system-wide lag on macOS 26 Tahoe

github.com

Post reply on HN
Print view View original

51–60 of 227 posts

Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe

#51

Post by snarfy »

kccqzy wrote: post #2

https://github.com/electron/electron/issues/48311#issuecomme... If this comment is to be believed, it's not Apple's fault. It's the apps mucking around with the internals of AppKit. This example just happens to illustrate two of my least favorite software engineering practices: (1) despite one piece of code making a method private, another piece of code still overrides it/modifies it/calls it, an affront to the idea…

It's all pretty terrible. For problem (1) why does the language allow it? And why are they doing it this way? Did Apple not provide an official way?

Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe

#52

Post by btown »

marcosdumay wrote: post #34
kccqzy wrote: post #2

https://github.com/electron/electron/issues/48311#issuecomme... If this comment is to be believed, it's not Apple's fault. It's the apps mucking around with the internals of AppKit. This example just happens to illustrate two of my least favorite software engineering practices: (1) despite one piece of code making a method private, another piece of code still overrides it/modifies it/calls it, an affront to the idea…

> despite one piece of code making a method private, another piece of code still overrides it/modifies it/calls it, an affront to the idea of encapsulation That's inherent on the way current computers manage the memory. And I don't know if the gains are enough to pay for the loses of guaranteeing encapsulation. One could reach for static analysis, but that would imply some restrictions on the machine's assembly. Thos…

There's also the good old use case of "am I dealing with a subclass that overrode the superclass's implementation of the method."

How do you distinguish between a superclass that always returns null/noop, vs. a subclass that happened to return null in this specific case?

Sometimes this is useful/vital for setting expectations to the user what functionality the instance is likely to have.

Now, you could refactor everything to have the superclass's implementation either throw a NotImplementedError, or return a sentinel value... but changing every call site might be a gargantuan task. Similarly, adding static metadata to every subclass might not be feasible. But checking whether the function's (pre-bound) identity is different is a very easy hack!

Ironically, this might indeed be exactly what Apple is doing here, and they're doing it in a tight loop.

Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe

#53

Post by OGEnthusiast »

Etheryte wrote: post #45
OGEnthusiast wrote: post #6

FWIW haven't experienced this at all on an M4 Max (with Slack and VSCode open).

To be fair, the M4 Max is such a beefy machine that you could do a lot of things wrong and still not notice it.

True, but looking at Activity Monitor I don't see any CPU or GPU spike when having an Electron app open and scrolling in Chrome (vs scrolling without any Electron apps open)

Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe

#54

Post by SkiFire13 »

kccqzy wrote: post #2

https://github.com/electron/electron/issues/48311#issuecomme... If this comment is to be believed, it's not Apple's fault. It's the apps mucking around with the internals of AppKit. This example just happens to illustrate two of my least favorite software engineering practices: (1) despite one piece of code making a method private, another piece of code still overrides it/modifies it/calls it, an affront to the idea…

> (2) a piece of code has different behavior depending on the identity of a function, contrary to the principle of extensionality.

Note that most definitions of extensionality don't consider the number of steps to achieve the result as an observable property, although in practice it is.

Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe

#55

Post by mcintyre1994 »

huijzer wrote: post #3

Don't Electron-based apps cause lag on basically any system?

I’ve never noticed anything before, though I’m sure their performance is worse than native apps. I think the M series has so much headroom at this point that you can get away with a lot.

Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe

#56

Post by pier25 »

torben-friis wrote: post #13

I’m surprised to see so little pushback in press to iOS/macOS 26. I’ve been part of the public beta and it’s been so weird going from “this sucks but it’s a first beta” through “it really isn’t improving much as time goes by” to “we’re a week from launch, there’s no way they release this after the Apple Intelligence fiasco”. And yet here we are. Performance issues, ui inconsistencies and garish design everywhere.

Tahoe is the worst macOS release I've ever experienced in 20 years. I think not even Yosemite was that bad.

Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe

#57

Post by jeffbee »

schmidtleonard wrote: post #4

Discord and VSCode work smoothly for me on an M4 MBP -- not sure if it's a compatibility difference or just performance hiding the problem, though. But Spotlight file search is completely broken, rebuilding the index doesn't help, and web results are the only thing it returns. After 20 years of intense research, Apple finally caught up to Microsoft in race to make search broken and useless.

The instructions for fixing a Mac's corrupted spotlight index are amazing. I was planning to do it earlier this year, but the number of manual actions was just too ridiculous. Then, after it was broken for months, it spontaneously started working again.

Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe

#58

Post by nottorp »

huijzer wrote: post #3

Don't Electron-based apps cause lag on basically any system?

It's in the runtime specifications, I think.

"Application should use all cores and all available memory."

In the past few years, the only applications i've seen run amok with memory usage at least were of course Electron based.

However, note that this problem is on Mac OS "users had too much contrast so we ruined it" 26 Tahoe. It's part of the early adopter experience.

Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe

#59

Post by cosmic_cheese »

wk_end wrote: post #47
cosmic_cheese wrote: post #27

Earlier quoted context omitted.

Apple’s attitude here is that it’s an inherent risk of using private APIs, because it’s not something they want devs doing. They don’t facilitate it like MS tends to. Don’t touch the stove if you don’t want to get burnt.

The person who's getting burnt is Random Officer Worker Joe, who just wants to run Slack and Spotify and who doesn't know a thing about Electron or private APIs, but knows that ever since upgrading their version of macOS things are running terribly. Apple's position is technically noble, but that doesn't help their users.

The Electron maintainers should've considered that possibility before reaching for a private API. It's on the Electron's team's shoulders and nobody else's.

If I were building a FOSS platform, I wouldn't give a second thought to third parties making use of my platform's private APIs. They're private for a reason, whether that be because they're not yet fully baked or because using them can have unintended consequences, they're not intended for public consumption. I especially wouldn't want somebody else's platform to depend on my private APIs, because I am then effectively locked into keeping that API frozen in time by the numerous others building on this other person's platform.

It's generally poor practice to build upon such brittle things as under-the-hood tinkering anyway.

Post reply on HN