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

91–100 of 227 posts

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

#91

Post by thfuran »

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.

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.

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

#92

Post by masklinn »

OGEnthusiast wrote: post #53
Etheryte wrote: post #45

Earlier quoted context omitted.

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)

Apparently the issue has to do with transparencies (shadows and straight up transparency), so could be a question of capabilities not capacity e.g. older gens have less range and some non-default require falling back to software whereas newer gens can keep to hardware.

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

#93

Post by cosmic_cheese »

bdash wrote: 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.

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

#94

Post by SBArbeit »

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?

Avalonia. https://avaloniaui.net/platforms

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

#96

Post by toast0 »

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.

Ok, but

> // By overriding this built-in method the corners of the vibrant view (if set) will be smooth.

If you don't override the built-in method, the corners won't be smooth. Jagged corners cause thousands of eye injuries every day.

Using (or overriding) private APIs comes with risks, but sometimes it's the only way to get things done. Of course, it comes with consequences too. Sometimes vendors test their new releases with commonly use applications and reach out when they've changed things and breakage results, but testing releases isn't webscale.

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

#97

Post by jojobas »

wk_end wrote: post #79
sgjohnson wrote: post #72

Earlier quoted context omitted.

You can still find applications written for Windows 3.1 in the latest builds of Windows 11. Something regarding database drivers if I recall correctly. Now imagine if you could get rid of all that legacy crap to make it work in the first place. Microsoft CAN’T do that, because the entire premise of Windows is backwards compatability. Apple? They don’t care. Killing 32bit apps? Just make an announcement saying that in…

> Now imagine if you could get rid of all that legacy crap to make it work in the first place. What would be the consequence of this? What harm does this do? Would it be worth Spotify and Slack breaking when I upgrade my OS?

> Now imagine if you could get rid of all that legacy crap to make it work in the first place.

Yeah, and someone will wake from the dead and rewrite all the programs that run the world, written 20-40 years ago, that are to a large degree perfectly working under these compatibility layers.

You should be eternally grateful to MS for dedicating tons of money and some of its best people to maintaining backwards compatibility.

Apple can only afford it because pretty much nothing critical ever ran on macos.

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

#99

Post by runjake »

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.

> I don’t understand what goes through the developer’s mind.

I'm not defending anyone here, but sometimes it's to work around bugs in public APIs that never get fixed. And sometimes it's because some perceived needed functionality isn't exposed in public APIs.

They figure "It'd be a lot easier to use this private API. We can just fix it if it breaks.", not really realizing the ramifications, for example a lot of apps use older versions of Electron -- some even EOL.

Is the Electron team now going to backport this fix to several versions back? Sounds... involved.

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

#100

Post by paxys »

arcfour wrote: post #49
nkozyra wrote: post #8

Earlier quoted context omitted.

I know it's a defacto complaint to leverage against Electron apps, but memory usage notwithstanding, I've never run into much lag issue on any major Electron app.

Surely there is a more effective way to write an app than to bundle an entire end-of-life browser and Node.js runtime into a 600MB monstrosity.

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