Native all the way, until you need text • Hacker News Board

Re: Native all the way, until you need text

#111

Post by ajross » Sun, May 17, 2026, 2:11 PM UTC

pornel wrote: post #38

Usually performance was the reason for using native APIs rather than web views, but this doesn't seem to be true any more. Browser rendering engines are pretty mature at this point, with significant GPU acceleration, and over a decade stress-testing by bloated web apps. Meanwhile SwiftUI doesn't feel particularly fast. Apple's latest and greatest rewrite of System Preferences has dumbed down the UI to mostly rows of…

This is the ActiveX/nacl/wasm/etc... argument recapitulated. For decades, people dithered about how to get fast code into browser environments such that it could be deployed safely.

Then the V8 team at Google just asked "well, what if we just made Javascript crazy fast instead?", and here we are. There's still room for native code in environments that don't map nicely to scalar scripting languages, but not a lot of room. Basically everyone is best served by ignoring that the problem ever existed.

It took the rendering side a little longer, but we're here nonetheless. There's still room for specialty apps with real need to exploit the hardware in ways not abstracted by the DOM (not 100% of it is games, but it's close to that). But for general "I need a GUI" problems? Yeah, just use Electron.

Re: Native all the way, until you need text

#112

Post by [deleted] » Sun, May 17, 2026, 2:11 PM UTC

StilesCrisis wrote: post #93

rubymamis wrote: post #77

Earlier quoted context omitted.

It's SwiftUI that is at fault here[1][2], not native apps in general. I wrote my native app in Qt C++ and QML and showed that it is *significantly* faster and uses significantly less RAM than similar web apps[3]. So, no, web apps, in general, are slower and uses more resources than well-engineered native apps. [1] https://notes.alinpanaitiu.com/SwiftUI%20is%20convenient,%20... [2] https://x.com/daniel_nguyenx/status/…

Qt is the opposite of native. It's just reimplementing the look and feel of a native app, but the seams are extremely visible.

[deleted]

Re: Native all the way, until you need text

#113

Post by sgt » Sun, May 17, 2026, 2:14 PM UTC

skeledrew wrote: post #30

> how immature all these “native” things still are when you step outside simple screens Well yeah. If people don't invest sufficient effort in a thing why would there be an expectation for that thing to become mature? People are locked into web tech because that's where the greater majority of the effort has been going. Quite literally people look at native, say it isn't developed enough, and go develop for the web e…

Agreed. He's basically complaining and moaning about Markdown not being fast to work with in Swift, when nobody has really put a lot of effort into that yet. yet despite this, he's not willing to contribute to that himself.

Re: Native all the way, until you need text

#114

Post by CharlesW » Sun, May 17, 2026, 2:18 PM UTC

rubymamis wrote: post #77

pornel wrote: post #38

Usually performance was the reason for using native APIs rather than web views, but this doesn't seem to be true any more. Browser rendering engines are pretty mature at this point, with significant GPU acceleration, and over a decade stress-testing by bloated web apps. Meanwhile SwiftUI doesn't feel particularly fast. Apple's latest and greatest rewrite of System Preferences has dumbed down the UI to mostly rows of…

It's SwiftUI that is at fault here[1][2], not native apps in general. I wrote my native app in Qt C++ and QML and showed that it is *significantly* faster and uses significantly less RAM than similar web apps[3]. So, no, web apps, in general, are slower and uses more resources than well-engineered native apps. [1] https://notes.alinpanaitiu.com/SwiftUI%20is%20convenient,%20... [2] https://x.com/daniel_nguyenx/status/…

> It's SwiftUI that is at fault here, not native apps in general.

The article you cited is from 2022 and so is irrelevant, since SwiftUI's performance profile completely changed as of xOS 26.

Claims like "It's hard to build a performant SwiftUI app" get into skill-issue territory, but more importantly, the reality is there are only "SwiftUI-first apps". All non-trivial SwiftUI-first apps will also use UIKit/AppKit as needed, typically for capabilties that aren't yet available via SwiftUI.

Re: Native all the way, until you need text

#115

Post by jeremyjh » Sun, May 17, 2026, 2:19 PM UTC

StilesCrisis wrote: post #93

rubymamis wrote: post #77

Earlier quoted context omitted.

It's SwiftUI that is at fault here[1][2], not native apps in general. I wrote my native app in Qt C++ and QML and showed that it is *significantly* faster and uses significantly less RAM than similar web apps[3]. So, no, web apps, in general, are slower and uses more resources than well-engineered native apps. [1] https://notes.alinpanaitiu.com/SwiftUI%20is%20convenient,%20... [2] https://x.com/daniel_nguyenx/status/…

Qt is the opposite of native. It's just reimplementing the look and feel of a native app, but the seams are extremely visible.

They even used the distinction “native-like” in the block editor article - which is really good, by the way and explains this distinction in more depth - but edited their comment now and that article is the third link and its anchored to the performance section so you won’t see that unless you scroll to the top.

Their point is more that SwiftUI has generally poor performance. Lots of native Windows frameworks have poor performance as well.

Native UI development is a minefield. If you want to build an app today that will still run in 20 years without a complete rewrite in the UI layer you should probably use wxWidgets if you are committed to native - even if only targeting one OS. But that model is really only appropriate for building traditional desktop apps. I don’t think the market would accept a Slack or Notion built that way today.

Re: Native all the way, until you need text

#116

Post by jonhohle » Sun, May 17, 2026, 2:20 PM UTC

carlosjobim wrote: post #109

Wowfunhappy wrote: post #55

Earlier quoted context omitted.

I mean, this is why I think PDFKit is a good comparison. Could you render your app's entire UI as a series of PDFs? Absolutely! Should you do that? Uh, probably not. You should use the native controls Apple gives you for buttons and dialogs and input fields and so on. But WebKit is the native UI for HTML, and Markdown is intended to be transpiled to HTML.

If think that the MacOS GUI is actually entirely rendered as a series of PDFs, if I have understood things correctly.

That’s how it originally worked, but Apple has moved away from PDF to other native GPU frameworks for drawing. Now window content is stored as bitmaps instead of redrawing vector instructions.

Re: Native all the way, until you need text

#117

Post by sgt » Sun, May 17, 2026, 2:20 PM UTC

diego_moita wrote: post #21

Outside of niche applications (e.g. virtual desktops, gamming, embedded systems) native UIs are dead. There are even parts of both Windows and MacOS rendered through HTML. If I remember correctly, at least in Windows 10, File Explorer was rendered through Internet Explorer. Web rendering doesn't need to be only through Electron/Node. There are other libraries much more performant and lean (Dioxus, etc).

> native UIs are dead.

Not in the world of macOS and iOS at least. Here native apps still rule, as there's literally no performant alternative (the OP's complaints about Markdown are misplaced - there's been no interest in MD and SwiftUI and that's why there's no good option. But in ObjC/Swift there is).

In fact, most of the apps I am using on a day to day is native. The Electron apps I use are okay (e.g. Slack) but they absolutely fail the native Turing test.

Re: Native all the way, until you need text

#118

Post by pier25 » Sun, May 17, 2026, 2:20 PM UTC

Maybe controversial but I think HTML + CSS is truly the most powerful system to make GUIs.

There’s really nothing else out there that competes with a similar performance and productivity.

This old article by the Missive team (the email client) convinced me.

https://medium.com/missive-app/our-dirty-little-secret-cross...

Re: Native all the way, until you need text

#119

Post by ogoffart » Sun, May 17, 2026, 2:22 PM UTC

chromadon wrote: post #11

This is where QT/JUCE can help. Although you are limited to c++.

If you are looking for something similar but not limited to C++, you can check Slint out: https://github.com/slint-ui/slint/

Re: Native all the way, until you need text

#120

Post by antiframe » Sun, May 17, 2026, 2:26 PM UTC

pier25 wrote: post #118

Maybe controversial but I think HTML + CSS is truly the most powerful system to make GUIs. There’s really nothing else out there that competes with a similar performance and productivity. This old article by the Missive team (the email client) convinced me. https://medium.com/missive-app/our-dirty-little-secret-cross...

Powerful, perhaps. Slow, for sure.