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

101–110 of 227 posts

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

#101

Post by porridgeraisin »

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

Well. This is hardly the funniest example then. Check this one out: https://github.com/reactjs/react.dev/issues/3896

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

#102

Post by Aaargh20318 »

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.

> Apple's position is technically noble, but that doesn't help their users.

The alternative doesn’t help either. That’s the approach Microsoft has taken and look what a mess Windows is because of it.

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

#103

Post by IlikeMadison »

ttoinou wrote: post #78
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

>Developer eXperience

if all you can create are electron apps then you are not a developer.

>cross platform

many programs are cross platform, without the need of Electron.

>open standards

???

>easy compatibility with websites

Electron isn't necessary, e.g. Telegram.

>easiness to keep updated

not Electron exclusive

Electron exists for lazy "programmers" to make their products as fast as possible, without caring for code quality and their customers experience. This is why managers love it, it saves money: you don't need to hire proper software engineers nor allocate an appropriate amount of time to develop and maintain your product.

Electron is part of the enshitification of the web and the IT in general.

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

#104

Post by [deleted] »

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.

[deleted]

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

#105

Post by paxys »

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.

You are describing every single macOS release. I still remember their permissions disaster which broke the majority of critical apps in people's workflows at launch. It's always best to wait a few months to upgrade.

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

#106

Post by acdha »

wk_end wrote: post #77
acdha wrote: post #50

Earlier quoted context omitted.

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…

Okay, I’ll grant that links and mountpoints were good but NTFS is still missing integrity checks, fast queries, etc. For most users nothing had changed since the Clinton administration.

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

#107

Post by bigstrat2003 »

thfuran wrote: post #91
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.

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.

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

#108

Post by tclancy »

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 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 100%.

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

#109

Post by viraptor »

Aaargh20318 wrote: post #102
wk_end wrote: post #47

Earlier quoted context omitted.

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.

> Apple's position is technically noble, but that doesn't help their users. The alternative doesn’t help either. That’s the approach Microsoft has taken and look what a mess Windows is because of it.

> what a mess Windows is because of it.

Can you point at any part of windows being a mess specifically because of backwards compatibility?

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

#110

Post by bigstrat2003 »

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 that people think they know better than to listen to the warning.
Post reply on HN