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

71–80 of 227 posts

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

#71

Post by cyberax »

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.

Yeah, but you HATE how the system behaves because some great spark at Apple thought that corners must always be _this_ rounded.

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

#72

Post by sgjohnson »

wk_end wrote: post #36
pavlov wrote: post #25

Earlier quoted context omitted.

That’s the principle that prevented Windows from making any meaningful progress for the past three decades.

What? Windows made tons of progress while maintaining this principle and became the most popular operating system in the world. Are you trying to tell me that you believe the evolution of Windows from 1.0 all the way to 7 - the entire time trying to operate according to this principle - doesn't constitute meaningful progress? The recent stagnation of the OS has nothing to do with attempting to maintain backwards comp…

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 2 major macOS releases, macOS won’t be able to run 32 bit apps. It cuts down bloat, and it cuts down on the potential attack surfaces for malicious actors.

Obviously just about everyone would agree that Windows 1 -> 7 was progress. I don’t think you’ll find too many people who’ll say the same about Windows 7 -> 11.

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

#73

Post by stalfosknight »

cyberax wrote: post #62
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…

Abuse of private APIs means that your public API is incomplete. And that people dislike how your system behaves so much, that they're willing to muck with its internals.

No, it means some people are doing it wrong either because:

1. They don't know how to do it the right way

or

2. They can't be bothered to do it the right way

#1 I can understand. We all make mistakes as we learn and grow as developers. #2 is just arrogance / laziness on the part of the developer. Compounding it by blaming the platform owner that clearly and explicitly told you not to go that route is gross.

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

#74

Post by cyberax »

acdha wrote: post #50
wk_end wrote: post #36

Earlier quoted context omitted.

What? Windows made tons of progress while maintaining this principle and became the most popular operating system in the world. Are you trying to tell me that you believe the evolution of Windows from 1.0 all the way to 7 - the entire time trying to operate according to this principle - doesn't constitute meaningful progress? The recent stagnation of the OS has nothing to do with attempting to maintain backwards comp…

It’s true that they’ve made some progress but my work laptop running Windows 11 still has UI elements from Windows 95/NT 4. The file system hasn’t improved since then and the keyboard responsiveness is actually worse. BeOS on 90s hardware absolutely torches Windows 11 on things like UI responsiveness, ability to multitask without degrading UI performance, and the file system (not networking, of course, it wasn’t perf…

You can actually tell the old controls from the Win NT by how fast and responsive they are. They also properly follow the best practices by showing keyboard accelerators when you press "alt".

It's the new stuff that is slow and unusable.

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

#75

Post by cyberax »

stalfosknight wrote: post #73
cyberax wrote: post #62

Earlier quoted context omitted.

Abuse of private APIs means that your public API is incomplete. And that people dislike how your system behaves so much, that they're willing to muck with its internals.

No, it means some people are doing it wrong either because: 1. They don't know how to do it the right way or 2. They can't be bothered to do it the right way #1 I can understand. We all make mistakes as we learn and grow as developers. #2 is just arrogance / laziness on the part of the developer. Compounding it by blaming the platform owner that clearly and explicitly told you not to go that route is gross.

[flagged]

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

#76

Post by altairprime »

ThePowerOfFuet wrote: post #65
altairprime wrote: post #14

Notes from the Google bug tracker linked by the GitHub issue: applying this command to each Chrome/Chromium app impacting your system will workaround the underlying macOS resource leak (EDIT: which only occurs when Electron mucks with private APIs to fake having native UI): defaults write com.google.Chrome NSAutoFillHeuristicControllerEnabled -bool false https://issues.chromium.org/issues/446481994#comment17 That com…

>hxxps://x.com/ian_mcdowell/status/1967326413830472191 (apologies for the Twitter link, but it’s an Apple employee) https://xcancel.com/ian_mcdowell/status/1967326413830472191 FTFY :)

“And yet”, she persisted, “my apology remains necessary.”

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

#77

Post by wk_end »

acdha wrote: post #50
wk_end wrote: post #36

Earlier quoted context omitted.

What? Windows made tons of progress while maintaining this principle and became the most popular operating system in the world. Are you trying to tell me that you believe the evolution of Windows from 1.0 all the way to 7 - the entire time trying to operate according to this principle - doesn't constitute meaningful progress? The recent stagnation of the OS has nothing to do with attempting to maintain backwards comp…

It’s true that they’ve made some progress but my work laptop running Windows 11 still has UI elements from Windows 95/NT 4. The file system hasn’t improved since then and the keyboard responsiveness is actually worse. BeOS on 90s hardware absolutely torches Windows 11 on things like UI responsiveness, ability to multitask without degrading UI performance, and the file system (not networking, of course, it wasn’t perf…

> The file system hasn’t improved since then

The file system is a great example of how Windows has evolved, actually. Windows 95 was (initially) still using FAT16! NT4 was using NTFS 1.2, we're now on NTFS 3.1. To the file system itself MS added (per Wikipedia): disk quotas, file-level encryption, sparse files, "reparse points" (dunno), journaling, "distributed link tracking" (also dunno), "the $Extend folder and its files" (ditto), and better MFT recovery. Also, apparently not part of the file system itself: symbolic links, transactions, partition shrinking, and self-healing. And that's just what I gleaned from the History section on Wikipedia's NTFS article; I'm sure there's more.

Apple specifically was much slower catching its file system up with Microsoft, despite their disinterest in backwards compatibility. And if Apple jumped ahead a little with APFS, well, NTFS holds its own just fine against APFS for 99% of users. And for when it doesn't, there's also ReFS, an entirely new next gen file system used on Windows Server, and is now slowly making its way onto the desktop.

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

#78

Post by ttoinou »

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.

   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

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

#79

Post by wk_end »

sgjohnson wrote: post #72
wk_end wrote: post #36

Earlier quoted context omitted.

What? Windows made tons of progress while maintaining this principle and became the most popular operating system in the world. Are you trying to tell me that you believe the evolution of Windows from 1.0 all the way to 7 - the entire time trying to operate according to this principle - doesn't constitute meaningful progress? The recent stagnation of the OS has nothing to do with attempting to maintain backwards comp…

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?

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

#80

Post by torben-friis »

wswope wrote: post #23
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.

> Performance issues, ui inconsistencies and garish design everywhere. Hasn't that been Apple's norm for a few years now? Not trying to land a cheap dunk here; I've honestly been running into rough edges and bad design with every major release for a long time.

>Hasn't that been Apple's norm for a few years now?

Not to this degree.

I’ve had 3 memory leaks in native apps, including the calculator. There’s basic alignment errors pretty much everywhere. In many places text can become fully unreadable (black on black, white on white, text over a transparent background with overlapping text below…).

It’s not slightly lowered quality, it’s the kind of inconsistency you expect mixing custom launchers and icon packs.

Post reply on HN