Hacker News Reader

Comment by herrkanin | Hacker News Reader

As a web dev, it’s been fun listening to Accidental Tech Podcast where Siracusa has been talking (or ranting) about the ins and outs of developing modern mac apps in Swift and SwiftUI.

View on HN

The part where he said making a large table in HTML and rendering it with a web view was orders of magnitude faster than using the SwiftUI native platform controls made me bash my head against my desk a couple times. What are we doing here, Apple.

Hacker News loves to hate Electron apps. In my experience ChatGPT on Mac (which I assume is fully native) is nearly impossible to use because I have a lot of large chats in my history but the website works much better and faster. ChatGPT website packed in Electron would've been much better. In fact, I am using a Chrome "PWA App" for ChatGPT now instead of the native app.

Someone more experienced that me could probably comment on this more, but theoretically is it possible for Electron production builds to become more efficient by having a much longer build process and stripping out all the unnecessary parts of Chromium?

It's possible to make bad apps with anything. The difference is that, as far as I can tell, it's not possible to make good apps with Electron.

> In my experience ChatGPT on Mac (which I assume is fully native)

If we are to believe ChatGPT itself: "The ChatGPT macOS desktop app is built using Electron, which means it is primarily written in JavaScript, HTML, and CSS"

As a web dev I must say that this segment made me happy and thankful for the browser team that really knows how to optimize.

I wish there were modern benchmarks against browser engines. A long time ago native apps were much faster at rendering UI than the browser, but that may performance rewrites ago, so I wonder how browsers perform now.

Shoutout to iced, my favorite GUI toolkit, which isn't even in 1.0 yet but can do that with ease and faster than anything I've ever seen: https://github.com/iced-rs/iced

https://github.com/tarkah/iced_table is a third-party widget for tables, but you can roll out your own or use other alternatives too

It's in Rust, not Swift, but I think switching from the latter to the former is easier than when moving away from many other popular languages.

It's easy to write a quick and clean UI toolkit, but it's when you add all the stuff for localization (like support for RTL languages - which also means swapping over where icons are) and accessibility (all the screen reader support) is where you really get bogged down and start wanting to add all these abstractions that slow things down.

RTL and accessibility are on the roadmap, the latter for this next version IIRC

I'd argue there's a lot more to iced than just being a quick toolkit. the Elm Architecture really shines for GUI apps

SwiftUI is a joke when it comes to performance. Even Marco's Overcast stutters when displaying a table of a dozen rows (of equal height).

That being said, it's not quite an apples to apples comparison, because SwiftUI or UIKit can work with basically an infinite number of rows, whereas HTML will eventually get to a point where it won't load.

I love the new Overcast's habit of mistaking my scroll gestures for taps when browsing the sections of a podcast.

Reply on news.ycombinator.com