Native all the way, until you need text
dive
410 points
274 comments
May 17, 2026
Related Discussions
Found 5 related stories in 85.8ms across 8,303 title embeddings via pgvector HNSW
- "Plain text has been around for decades and it's here to stay." – Unsung rbanffy · 38 pts · April 25, 2026 · 51% similar
- Zero-native – Build native desktop apps with web UI gedy · 21 pts · May 13, 2026 · 46% similar
- Principles for agent-native CLIs blumpy22 · 81 pts · May 07, 2026 · 45% similar
- The text mode lie: why modern TUIs are a nightmare for accessibility HotGarbage · 13 pts · May 03, 2026 · 44% similar
- The text mode lie: why modern TUIs are a nightmare for accessibility SpyCoder77 · 165 pts · May 03, 2026 · 44% similar
Discussion Highlights (20 comments)
PaulHoule
Yep. Electron is the worst way to make a desktop app… except for all the others!
cyber_kinetist
I just wish there was a native Markdown renderer / editor library in C that I can use cross-platform - in the style of something like IMGUI (where the library outputs a list of primitives for you to render yourself in any graphics API). Or well... since we now have Claude I might have a jab at this someday in my free time.
elch
How is "performance" defined? Does it take into account the amount of memory required in each case?
inatreecrown2
Not just text. Try to build a ui where you need non-trivial and non-standard behavior and SwiftUI will fail. AppKit is still better in this regard.
splittydev
I've had pretty much the same experience with my AI chat app. Nothing works well. Markdown rendering is slow and laggy, streaming is slow and laggy, everything locks up the UI. I've tried at least 5 of the most popular text editor components for UIKit and SwiftUI on GitHub, and all were broken in one way or another, buggy, and slow as well. It's ridiculous.
rTX5CMRXIfFG
Show your code, or show you the door. There are so many native Mac and iOS apps out there right now perfectly capable of rendering Markdown and streaming text. You just gotta wonder what is this guy’s excuse.
danielvaughn
I remember being a junior engineer in 2015, and being asked to render a clickable link within a paragraph in an iOS app. Swift had just been released so we were still entirely on the ObjC/UIKit stack. It was an absolute nightmare. I _barely_ managed to make it work. I haven't really touched iOS since about 2016, so I assumed the new SwiftUI stuff would have this stuff built in. Obviously. Kind of insane that it wasn't.
chromadon
This is where QT/JUCE can help. Although you are limited to c++.
ryandrake
I don’t recall ever struggling with NSTextView. I never really got into Swift, but I’ve never found Cocoa / Objective C to have any of the problems the author mentioned. Not exactly sure what “streaming” text is, but serial terminal software has been handling incremental text rendering and updating for decades, without performance struggles.
usernametaken29
Kotlin MP is also pretty decent on Mac
saagarjha
You can just embed a web view in your app, though?
camgunz
I thought models were so good we could vibecode a text renderer for $50. What's the problem here? /s
Wowfunhappy
If you're on macOS, WebKit is a native OS framework. Using WebKit to render Markdown seems completely appropriate. Now, if you're rendering everything with WebKit, that's ridiculous, in the same way rendering everything with PDFKit would be ridiculous. But for a Markdown view, WebKit seems like a logical choice. There's no need to subsequently flip the table and replace everything with a Chromium web app.
diego_moita
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).
vasco
I once tried mobile development in semi early days android. At the time I made a free Hackaday reader app because I was a daily reader and loved it. I remember spending 4 hours to make a scrollable element that wasn't jumpy or buggy. There were several stackoverflow answers full of gotchas explaining all you had to do. I finished and published the app but never again. Native stuff has terrible developer experience.
sirwhinesalot
If you need to display HTML content (what Markdown usually translates to) then WKWebView is the control to use! Or use something like litehtml which should be more than enough for Markdown unless you want to support "Animated Gifs" (that are actually H.264 movies these days) or whatever else. You can still use native controls for the rest of the UI and have 0 Javascript running. I'm not sure I understand what the problem with NSTextView was though. It's pretty performant as far as I can tell?
pjmlp
I was using Markdown text editors with WPF back in 2012.... And yes WPF is a framework native to the Windows platform ecosystem.
skeledrew
> 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 even more. Cycle repeats. Hardly anyone wants to put in the effort to improve native when things already "just work" for the browser.
dist-epoch
the only place where native UI is still better is for ultra-complex UIs - image/video/3d/audio editors. and only because it's easier to create custom UI widgets/renderers than on web stack. that's it, for everything else native UIs are complete garbage compared to HTML/CSS/reactive frameworks.
pornel
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 checkboxes, and yet switching between sections can lag worse than loading web pages from us-east-1.