Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Track which Electron apps slow down macOS 26 Tahoe

avarayr.github.io

Post reply on HN
Print view View original

71–80 of 144 posts

Re: Track which Electron apps slow down macOS 26 Tahoe

#71

Post by wiseowise »

Razengan wrote: post #64
Spunkie wrote: post #15

In general the Tahoe update has been awful for all my end users that decided to update. It's not just electron apps that are the issue btw, just yesterday we ran into an issue with Zoom. It was breaking prompts/popups and by extension the system settings, the Mac app store, iTouch, and a ton of other random stuff was broken in silent and inconsistent ways. Also all my 8gb users are noticing significantly higher memor…

> It's not just electron apps that are the issue btw Electron ""apps"" were are and will always be the issue. Don't bundle a whole freakin web browser and ravish my battery and RAM just to show me a damn text box. A text box that won't even have all the built-in OS features or accessibility. Downvote this to hell but Electron is a crutch for lazy Frankensteins looking for lightning to revive a monster that should hav…

Okay gramps, time to take the meds.

Re: Track which Electron apps slow down macOS 26 Tahoe

#72

Post by concinds »

Razengan wrote: post #68
concinds wrote: post #59

Earlier quoted context omitted.

SwiftUI is still broken for any non-simple apps, almost a decade after its introduction. Completely unacceptable for big apps. Look at OmniFocus, who inexplicably became early-adopters of it, and it's had a bunch of UI glitches and inconsistent behavior requiring app restart (like you select one list item, but the inspector shows you details for another list item) ever since. Apple only has itself to blame for Electr…

> almost a decade after its introduction . It was released in 2019, so 6 years ago at most. > Apple only has itself to blame for Electron's popularity. + Microsoft with their inability to decide on a single UI framework/API for more than 1.5 years.

My bad, I recalled 2017 for some reason.

And of course, same problem on Windows.

Re: Track which Electron apps slow down macOS 26 Tahoe

#74

Post by typpilol »

Razengan wrote: post #64
Spunkie wrote: post #15

In general the Tahoe update has been awful for all my end users that decided to update. It's not just electron apps that are the issue btw, just yesterday we ran into an issue with Zoom. It was breaking prompts/popups and by extension the system settings, the Mac app store, iTouch, and a ton of other random stuff was broken in silent and inconsistent ways. Also all my 8gb users are noticing significantly higher memor…

> It's not just electron apps that are the issue btw Electron ""apps"" were are and will always be the issue. Don't bundle a whole freakin web browser and ravish my battery and RAM just to show me a damn text box. A text box that won't even have all the built-in OS features or accessibility. Downvote this to hell but Electron is a crutch for lazy Frankensteins looking for lightning to revive a monster that should hav…

Do you even know how much a modern electron app with tree shaking actually uses?

Most of my electron apps fully packaged are less than 100mb.

Re: Track which Electron apps slow down macOS 26 Tahoe

#75

Post by gfehhffvvv »

ascorbic wrote: post #73
the_lucifer wrote: post #49

Seeing 1Password there hurts me. They used to be paragons of well designed native apps that they dumped with 8.

It just means they haven't updated Electron since last week.

They mean just being Electron at all, I imagine.

Re: Track which Electron apps slow down macOS 26 Tahoe

#76

Post by typpilol »

binaryturtle wrote: post #32
nikolay wrote: post #4

Earlier quoted context omitted.

Some notable apps without fixes (which I have installed locally): * 1Password.app * Bruno.app * Claude.app (oh noes!) * Cursor.app * Docker.app * Dropbox Dash.app * Dropbox.app * Element.app * GitKraken.app * Graphite.app * HEY.app (shame on DHH!) * Keeper Password Manager.app (it's not just 1Password) * Keybase.app * Kiro.app (come on, AWS!) * Ledger Live.app (crypto seems to lag behind Web 2.0 still!) * Loom.app *…

What is that? Like 32x >100MB junk overhead per app? ~4GiB gone from the disk just to hold the same broken copy of some framework/library? It's quite the insanity, isn't it? If there was one copy of that electron (e.g. installed to /Library somewhere) which all apps would simply use then you only would need to update one copy. Less disk space wasted. All apps fixed in one go. Back in the old days on the Commodore Ami…

4gb seems quite small for all of those apps to be honest.

Re: Track which Electron apps slow down macOS 26 Tahoe

#77

Post by typpilol »

oefrha wrote: post #57
binaryturtle wrote: post #32

Earlier quoted context omitted.

What is that? Like 32x >100MB junk overhead per app? ~4GiB gone from the disk just to hold the same broken copy of some framework/library? It's quite the insanity, isn't it? If there was one copy of that electron (e.g. installed to /Library somewhere) which all apps would simply use then you only would need to update one copy. Less disk space wasted. All apps fixed in one go. Back in the old days on the Commodore Ami…

No shit. One major frigging selling point of Electron vs OS web view is the developer controls the browser version and has a stable target to develop and test against, rather than having many moving targets that shift after the app is shipped. And you really think the entire ecosystem has never heard of this honking great idea named shared libraries from the good old days? Being smug about obvious things like this us…

I find explaining browser defaults to non web-devs really eye opening for them.

Re: Track which Electron apps slow down macOS 26 Tahoe

#78

Post by gfehhffvvv »

WD-42 wrote: post #22
mikamika83 wrote: post #11

Earlier quoted context omitted.

Meh. VSCode is a fantastic piece of software, one I never had a problem with before Tahoe.

Compared to what? I find it telling that the original creators of electron are now writing a new editor with native code because even they can’t stand electron. It’s like they are trying to write a wrong they did to the world.

Xcode, Visual Studio (the original I mean), PyCharm et al., Eclipse, vim, emacs, Notepad++, Sublime… hmm that’s all the IDEs and text editors I can remember using significantly in a professional context. I prefer VSCode to those.

Re: Track which Electron apps slow down macOS 26 Tahoe

#79

Post by concinds »

Spunkie wrote: post #15

In general the Tahoe update has been awful for all my end users that decided to update. It's not just electron apps that are the issue btw, just yesterday we ran into an issue with Zoom. It was breaking prompts/popups and by extension the system settings, the Mac app store, iTouch, and a ton of other random stuff was broken in silent and inconsistent ways. Also all my 8gb users are noticing significantly higher memor…

I suggest that everyone here stop submitting Feedback Assistant/Radar reports. Let teenagers, college students, adults and old people buy a new Mac, experience the bugs and lack of polish and let it affect Apple's brand, consumer's preferences, and their market behavior. Apple is too big to care about anything other than market consequences. Apple is fully aware that no one likes the Radar system, that no one feels their reports count, they had an executive do a sort-of mea culpa years ago but nothing changed.

My AirPods keep going silent on my new Tahoe Mac and require a disconnect and reconnect. Will I report it? No. (Besides, if you report bugs like that, Apple collects a map of your entire filesystem, every path and filename). Apple shouldn't have fired their QA team. Let them deal with any brand damage, they've earned it. I mean, did Apple really not test their new OS with Slack, Zoom or VSCode? Really? Reckless.

Re: Track which Electron apps slow down macOS 26 Tahoe

#80

Post by gfehhffvvv »

Etheryte wrote: post #62
self_awareness wrote: post #54

The fact that an application can slow down the system doesn't sound like a problem with the application, but rather it's a problem with the OS. Tracking applications that "are not fixed" is not the solution. Fixing the OS is the solution.

Otherwise I would be inclined to agree with you, but in this specific case I'm torn. These apps (ab)used a private API and the OS update meant they suddenly used it incorrectly. That's not something that's really the OS fault as far as I'm concerned. But I do agree that better separation is always good.

Historically Windows was known for not causing this kind of breakage for even “(ab)users” of private APIs, common misusers, buggy users, etc. And even working around such issues on the OS side.
Post reply on HN