Live data from Hacker News

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

github.com

131–140 of 227 posts

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

#131
post #86

Earlier quoted context omitted.

> 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…

I have written my share of "inspect caller and do things" too. I still don't like that.

Personally, at this point I blame that universal assumption that every piece of code inside a program has the same reliability, trustworthiness and disclosure properties. At some point we'll have to burn down every bit of software infrastructure and build it new with some care about security.

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

#132
post #100

Earlier quoted context omitted.

Electron apps don't have to be 600 MB. VS Code is an entire fully-featured IDE and is a 90 MB download.

VS Code package in my applications folder is 600+ MB. The Electron Framework.framework it contains is 400+ MB alone. I don't understand where you come up with your 90 MB figure?

The VSCodeUserSetup file from https://code.visualstudio.com/download is in the 90MB range.

Perhaps this file is just the installer and the actual system files are much larger? Or maybe your 400MB figure comes from a bloated install? Just speculating here.

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

#133
post #68

This affects some of the most widely used applications on the platform, including "productivity" applications such as Slack that Apple uses internally. How did no-one at Apple notice this and do something about it prior to macOS 26 being released?

I stopped using the Slack Electron wrapper as soon as Safari added support for "installing" web apps (File > Add to Dock…). Wouldn't be surprised if people within Apple did similar.

I'd sorta hope they are testing widely-used applications in the way that typical end users will experience them before releasing a new OS version.

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

#134

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

Strangely the WindowServer issue is a constant issue on my personal MacBook Pro, but I've never seen it on my identical work MacBook Pro. It seems like there's some other factor that is necessary to trigger the problem.

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

#135

Earlier quoted context omitted.

> 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…

I don’t understand what goes through the developer’s mind. A method is marked as private. It’s documented as not to be used by developers. Further documentation says that using it may break your application in strange ways now or in the future. Despite all this, the developer concludes: “yea, I think it’s a good idea to use this API!” Then, later when something breaks, it’s Shocked Pikachu all around.

Apple has to take some of the blame from this, MacOS without Electron apps is a much less useful proposition. If they knew they were going to change this API in this release it would have made sense to reach out and offer a public way to Electron.

End of the day the needs of users running Electron apps outweighs whatever opinions the internal Apple team has about their APIs

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

#136
post #91

Earlier quoted context omitted.

The alternative to using private methods or reflectively mucking about with library/platform internals isn't always "do the same thing but with only public API"; it's sometimes "you can't possibly fix the bug or implement the feature that you want to". It sure does increase maintenance burden though.

> it's sometimes "you can't possibly fix the bug or implement the feature that you want to" Yes. It is, and that is what any responsible person should choose.

So you'd tell customers "No, I'm not fixing that bug because doing so would offend my aesthetic sensibilities. Yes, I know you have a support contract, but I simply refuse to address your problem even though I could"? Or maybe you'd phrase it a little differently in public.

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

#137

Earlier quoted context omitted.

GPU load bug and Autofill bug are two separate, completely unrelated issues.

I’m happy to refer to a better workaround if you have one?

1. workaround for high GPU load by Electron apps (what this HN thread is about) — see the command here: https://github.com/electron/electron/issues/48311#issuecomme...

2. unrelated workaround for scroll bug - defaults write com.google.Chrome NSAutoFillHeuristicControllerEnabled -bool false

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

#138
post #68

This affects some of the most widely used applications on the platform, including "productivity" applications such as Slack that Apple uses internally. How did no-one at Apple notice this and do something about it prior to macOS 26 being released?

I stopped using the Slack Electron wrapper as soon as Safari added support for "installing" web apps (File > Add to Dock…). Wouldn't be surprised if people within Apple did similar.

I actually did that as soon as Safari added a pinned tab feature. I remember doing this as early as 2016.

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

#140
post #32

Earlier quoted context omitted.

Nah, it's Apple's fault. Not regression testing against major apps is pure incompetence. Also, this in the comment: > [a user] Please try any way of getting in touch with Apple engineers you can. As a project, we don't have a better connection to Apple than you do. > > One approach might be the engineer who replied to the Bluesky post that someone linked to above about the input issue. Pure incompetence. Major projec…

This is downvoted, but it's true. It doesn't matter who's fault it is in some Aristotelean sense, what matters is the user upgraded to YOUR new OS, and now shit don't work. Raymond Chen and Microsoft got this, years ago. Joel talked about it. You make shit work , even if it's the software being a fuck.

No time to do that when you need to re-do the entire UI of 100 apps for no good reason other than to make an iMac indistinguishable from an iPad.
Post reply on HN