Comment by Klonoar
7 days ago
Every Electron app is going to feel incredibly out of place.
And for the few that aren’t okay with feeling out of place, the devs of those apps will now have to contend with shipping more macOS specific styles and workarounds.
I’m not looking to discuss Electron performance/etc so please ditch that discussion before it starts. I just find it interesting how comparatively tricky this particular UI styling might end up being for cross-platform developers.
Electron apps are already out of place. In the space of Mac-apps-for-SaaS-products such as Linear, Slack, Notion, Asana, Figma, GitHub, and Spotify, they inflict the company's own design system on Apple's OS rather than try to ship Apple's design system applied to their product. Even the most popular IDE, VSCode, is just a wrapper around a web page.
And they're rational to do it this way. These companies shipping apps to millions of people all came to the conclusion that investing in native Mac software is not worthwhile to their business. Users don't avoid Electron-based products, and building native Mac apps slows you down. It's easier both technologically and organizationally to ship your web site as an Electron app. It costs less and you don't lose any users.
So I would be surprised to see _any_ popular Electron app get design updates to accommodate these changes.
As a user it makes me sad, but I find myself blaming Apple for losing this fight, not the hundreds of successful companies that all somehow make the same choice. If building native were an advantage, people would take it.
I certainly avoid Electron apps on macOS and konw I am not the only one who does.
Which apps do you avoid in particular which are associated with a service you are required by your job to use? Or, what purchasing decisions have you made on behalf of your company that took Electron-ness into account?
3 replies →
> Electron apps are already out of place.
You're taking the boring argument track here. Yes, they use their own design system language, but they still roughly fit in with an OS that's not random transparency/glass effects everywhere.
They clearly will not fit in with the new UI styling without significant thought and work.
Every Electron app is going to feel incredibly out of place.
It's not going to matter, most Electron apps look out of place on the Mac already. The developers are not going to care and probably most users are not going to care either (I used to be staunchly against Electron for this reason, but gave up, and now I choose just enjoy apps looking the same between platforms).
Apple neglected the desktop from ~2016-2020 and made two frameworks that are unpopular among developers (Catalyst and SwiftUI) after that. Outside some indie devs, the native Mac app ship has sailed. Even developers that had their roots in macOS (e.g. AgileBits) have given up and switched to Electron.
Even if you like the general direction of SwiftUI it's way less mature on the mac and being tied to the OS version means you have to deal with all the churn it's had in the last three years to ship with it on the mac. Very few devs are going to bother with this.
Ever since the death of WinForms and Cocoa we've moved away from apps having a unified visual experience on an OS to apps pushing their own consistent theme across platforms. A big contrast between app and OS theme in recent times was when apps offered Dark Mode before it became an OS wide setting.
> Every Electron app is going to feel incredibly out of place.
AFAIK, most people do most things on the Web. So, no, Electron Apps will feel like what most people use most of the time. It's native apps that will feel out of place.
Nah, native apps end up feeling nice and cozy by comparison. :)
The design language of native controls is usually much quieter and more subdued than the garishness that is allowed in the name of branding.
I won't be surprised if we see a CSS filter that attempts to model this in Safari. Then it'll just be a question of whether Chromium (and thus Electron) get it.
Can't you access rendered elements from JS? Then this will be a massive security issue, because anybody can read all the content from behind.
Elements have supported transparency for a couple decades now.
1 reply →
Yeah, for sure. That solves part of it.
> Every Electron app is going to feel incredibly out of place.
Consistency with native app/style had never been an issue, ever. It's stylistic choice. while I get that someone would like to have the same theme everywhere it does not prevent anything.
Every single webpage is different that the other and yet everybody browse the web.
I think differing app styles can work under this new macOS design, they’ll just need to have more physicality, dynamism, and overall more involvement from the design department. Devs just won't be able to drop a dumptruck of flat roundrects on the screen and call it a day if they don’t want their app looking bad.
I mentioned this elsewhere, but if LLMs are improving developer performance so drastically, why are none of these gains being used to get back towards native app development?
Because devs lack the will to build native apps. Even on HN, native app dev is seen as somewhat esoteric because it isn't cross-platform by default.
There's plenty of pragmatic reasons not to build a native app. The concerning thing IMO is the hegemony of opinion here. After all, nothing says "hacker" quite like following all the rules properly and always doing the sensible thing. :)
> if LLMs are improving developer performance so drastically
IMO the jury is out on how much they are.
> why are none of these gains being used to get back towards native app development?
because the different platforms are still radically different in a way an LLM can't easily and simply paper over. How do I specify a UI in a way that an LLM can competently implement it in HTML, SwiftUI and whatever Windows is using these days?
> why are none of these gains being used to get back towards native app development?
One argument might be that, like with any LLM output, you still do need to know it well enough to know if it's good or not implementation-wise. You still need that knowledge to understand if your performance for rendering in some scenarios is going to fall off a cliff.
Web (via browsers or Electron/etc) are mostly one train of thought. When you're doing native application development using host OS frameworks, you have to actually know the framework. LLMs don't really save you from that; i.e, I could have an LLM spit out whatever flavor of Windows-specific UI I need. I have zero way of knowing whether it's correct or not.