Live data from Hacker News

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

github.com

211–220 of 227 posts

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

#211
post #188
post #182

Earlier quoted context omitted.

Laziness comes in many forms. Arguably, discovering and using private APIs is a form of intellectual laziness — it requires you to refuse acknowledging that the whole system is telling not to do things that way.

If you defer to authority. That is, you accept that the people who made the API have the authority to dictate you what you can or can't do on your hardware (or for other people on their), that privating the parts of the API you need was a conscious decision (and not just laziness on their part) and that in general you listen to commands like that. Even with just a shroud of hacker thinking that is not something progr…

Oh wow, that is the opposite of Hacker Mentality to me. I may question lots of other people, but if some other coder put in the time to construct a well designed API that includes public and private methods, my first thought is never “I know better”. Took me a couple of decades to stop thinking that though, so what do I know?

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

#213

Earlier quoted context omitted.

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

Absolutely not. Apple has zero responsibility to anybody for changing a private API. That’s the whole point of it being marked private.

If one dude is using a private API, that's him being reckless. If thousands of applications are using a private API, that's poor API design.

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

#214

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.

In my decade of experience with laravel I've seen ordersof magnitude more public APIs randomly breaking than private ones.

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

#215

Earlier quoted context omitted.

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

Yes, I have told customers exactly that when there was no supported way to achieve what they wanted. I'm not putting my name on that.

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

#216

Earlier quoted context omitted.

Absolutely not. Apple has zero responsibility to anybody for changing a private API. That’s the whole point of it being marked private.

If one dude is using a private API, that's him being reckless. If thousands of applications are using a private API, that's poor API design.

The thousands of "apps" wouldn't all be using this private api if they weren't electron junk

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

#217
post #145

Earlier quoted context omitted.

It's a little heterodox, but not hard at all[1] and it takes literally less than a minute to trigger the rebuilding. [1] https://support.apple.com/en-us/102321

The ones I was reading involved recovery mode and editing inodes.

I’ve rebuilt my spotlight db several times over the years by adding root to the exceptions list and removing. Whatever you found was going way overboard.

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

#218

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

fixed in: https://github.com/electron/electron/pull/48376

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

#219
post #78
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 is not necessarily better with JS based stacks.

In fact it can be worse than many, including modern C++.

Of all the points you mention, compatibility with websites is probably the only one that can be considered exclusive to Electron codebases.

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

#220

Discord and VSCode work smoothly for me on an M4 MBP -- not sure if it's a compatibility difference or just performance hiding the problem, though. But Spotlight file search is completely broken, rebuilding the index doesn't help, and web results are the only thing it returns. After 20 years of intense research, Apple finally caught up to Microsoft in race to make search broken and useless.

Finda https://keminglabs.com/finda/> is the best file search I've seen for macOS. (Incidentally, it has an Electron UI.)

Doesn't seem to be updated for Tahoe yet, and even the Sequoia version isn't notarized, so it's not really clear if it has a future.

Post reply on HN