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

161–170 of 227 posts

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

#161

Post by boomlinde »

bigstrat2003 wrote: post #113
ttoinou wrote: post #78

Earlier quoted context omitted.

The most inefficient solution (in both space and time complexity) Those are not the only qualities / metrics to optimize for. Developer eXperience, cross platform, open standards, easy compatibility with websites, easiness to keep updated etc. can be far more important

Developer experience is never more important than the quality of the end product. The goal is to make good software, not to have the easiest time possible making mediocre to bad software.

For most commercial endeavors, the goal is to make money. If you're lucky, that goal is somewhat aligned with making good software, but in practice there's always a compromise between quality and development cost.

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

#162

Post by mvdtnz »

ryandrake wrote: post #61
marcosdumay wrote: post #34

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.

> Then, later when something breaks, it’s Shocked Pikachu all around

This isn't really true. When something breaks it's generally "darn, we knew it would happen eventually".

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

#163

Post by c-hendricks »

mikamika83 wrote: post #119
c-hendricks wrote: post #67

It's not limited to Electron applications: https://github.com/neovide/neovide/issues/3225 Other Tahoe issues with non-Electron apps: https://github.com/zed-industries/zed/issues/33182 https://github.com/wezterm/wezterm/issues/7255

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

Correct! That's why I listed them under "other". One seems to be their new SMS 2FA functionality causing high CPU usage, the other seems to be private window APIs causing high GPU usage.

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

#164

Post by tcfhgj »

IgorPartola wrote: post #41
rvz wrote: post #37

Well, that's...Electron for you. The most inefficient solution (in both space and time complexity) being suggested to build desktop apps is now shown to be causing widespread sluggishness. So much for interviewing developers for algorithms and data structures. Also Rust won't save you or make Electron faster either.

1. This is about a specific bug, not about Electron in general. 2. What better cross platform GUI alternative do you suggest?

anything which uses native code

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

#165

Post by piperswe »

ethmarks wrote: post #132
shawn-butler wrote: post #124

Earlier quoted context omitted.

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.

Presumably the setup file is compressed, and the installation on disk isn't

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

#166

Post by grishka »

ryandrake wrote: post #61
marcosdumay wrote: post #34

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.

Sometimes you just can't achieve something with public APIs. Especially on Apple OSes, they love making genuinely useful APIs private for no good reason while heavily using them in their own apps.

Of course, if you use a private API, you're on your own if your app breaks because of it. I myself have done my fair share of using private APIs on Android. Ideally, you should test your app on beta versions of every upcoming major OS release to make sure it doesn't break. Even more ideally, there's a public equivalent starting with some OS version and you only use the private one until that version, then nothing will ever break.

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

#168

Post by taroth »

mrtesthah wrote: post #116
c-hendricks wrote: post #67

It's not limited to Electron applications: https://github.com/neovide/neovide/issues/3225 Other Tahoe issues with non-Electron apps: https://github.com/zed-industries/zed/issues/33182 https://github.com/wezterm/wezterm/issues/7255

This might be the fix: https://github.com/ghostty-org/ghostty/pull/8625/commits/431...

One-liner for electron developers to fix the issue:

browserwindow.setHasShadow(false)

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

#169

Post by IgorPartola »

tcfhgj wrote: post #164
IgorPartola wrote: post #41

Earlier quoted context omitted.

1. This is about a specific bug, not about Electron in general. 2. What better cross platform GUI alternative do you suggest?

anything which uses native code

How would that be cross platform?

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

#170

Post by igregoryca »

tclancy wrote: post #108
ryandrake wrote: post #61

Earlier quoted context omitted.

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.

I get it but a lot of the war stories from Raymond Chen's blog https://devblogs.microsoft.com/oldnewthing/ were about helping major corporations unscrew something that had relied on a private Windows API because there hadn't been a good way to do it. I would guess most cases of people choosing to rely on a private method are laziness or lack of knowledge about "the right way" (or call it bad documentation), but not 1…

Discovering and using private APIs is not a walk in the park. I doubt "laziness" is a common motivation for doing so. Lack of knowledge or bad docs, perhaps. But there's often no officially sanctioned way to do something that people want (and perhaps will pay for) - most private API usage I've seen falls into this third bucket.
Post reply on HN