{"id":47508,"date":"2025-04-25T13:49:18","date_gmt":"2025-04-25T17:49:18","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=47508"},"modified":"2025-06-05T13:45:44","modified_gmt":"2025-06-05T17:45:44","slug":"is-electron-really-that-bad","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2025\/04\/25\/is-electron-really-that-bad\/","title":{"rendered":"Is Electron Really That Bad?"},"content":{"rendered":"

Federico Viticci<\/a> (Mastodon<\/a>):<\/p>\n

I’ve been thinking about this video by Theo Browne<\/a> for the past few days, especially in the aftermath of my story about working on the iPad<\/a> and realizing its best apps are actually web apps.<\/p>

I think Theo did a great job contextualizing the history of Electron<\/a> and how we got to this point where the majority of desktop apps are built with it. There are two sections of the video that stood out to me and I want to highlight here. First, this observation – which I strongly agree with – regarding the desktop apps we ended up having thanks<\/em> to Electron and why we often consider them “buggy”[…]<\/p>\n

[…]<\/p>\n

As documented in the thread from late 2023, this is a common issue for the majority of AI clients built with SwiftUI, which is often less efficient than Electron when it comes to rendering real-time chat messages. Ironic.<\/p>\n<\/blockquote>\n\n

Isaiah Carew<\/a>:<\/p>\n

i think the weirdest part of this article is hearing that chromium is more efficient than SwiftUI.<\/p>

is that just for specific things or is it across the board?<\/p><\/blockquote>\n\n

Miguel Arroz<\/a>:<\/p>\n

[It] seems they’re talking about text rendering. SwiftUI is really bad at that, this is why I’m using UIKit for the document editor in PaperVault.<\/p><\/blockquote>\n\n

It’s not really surprising that Chromium is super optimized for rendering Web text. On the other hand, that’s a common thing that apps need to do, so it would be good to have a better native story.<\/p>\n\n

Christina Warren<\/a>:<\/p>\n

For years, I’ve wanted to write a post called “The web won” which is very similar to what @viticci wrote here -- my aim was desktop more than mobile, but this is also especially true on the iPad and to @isaiah’s point, what makes this worse on mobile\/iPad is the state of PWAs in Safari\/WebKit.<\/p><\/blockquote>\n\n

Peter Steinberger<\/a>:<\/p>\n

Man I’m so happy I am in JavaScript land. Debugging just works and compile times are instant.<\/p><\/blockquote>\n\n

When I started writing apps, the availability and quality of developer tools was considered to be an advantage for native development vs. the Web. These days, I still think native APIs usually lead to better apps—though there are some awful Catalyst<\/a> and SwiftUI apps that would have been better as Electron—but the Web tooling has really<\/em> improved. I think many would now consider it a strong advantage<\/em>.<\/p>\n\n

JavaScript got 25+ years of work from many different parties. Mac developers got<\/a> Swift<\/a>, which I generally like and much prefer to JavaScript. But, while JavaScript is gaining many of the benefits of other systems, while retaining its dynamism, Apple is forfeiting<\/a> former strengths. Swift made compilation<\/a> much slower. Debugging is still slow and arguably worse than before. There are more compiler and linking bugs. There’s no more Fix and Continue. SwiftUI<\/a> is more opaque<\/a> than Cocoa.<\/p>\n\n

Web technologies also seem to provide a more stable development target—do you hear about Web developers planning their year around seasonal<\/a> beta testing and breakage<\/a>?—and better documentation. An integrated development stack would seem to offer potential advantages, but offsetting that on the Web side are open source, cross-platform, distribution outside the App Store<\/a>, and legions of developers and companies, now getting multiplied by AI<\/a>.<\/p>\n\n

Previously:<\/p>\n