Yep. Electron is the worst way to make a desktop app… except for all the others!

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.

How is "performance" defined? Does it take into account the amount of memory required in each case?

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.

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.

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.

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.

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

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.

Kotlin MP is also pretty decent on Mac

You can just embed a web view in your app, though?

I thought models were so good we could vibecode a text renderer for $50. What's the problem here? /s

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.

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).

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.

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?

I was using Markdown text editors with WPF back in 2012....

And yes WPF is a framework native to the Windows platform ecosystem.

> 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.

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.

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.

Why not use native for UI frame (menu, toolbar, conversation list etc) and WebKit for the actual chat? I think that would combine the best of both worlds.

> But I still cannot make a simple thing work properly: a chat with Markdown & the ability to select a whole message.

Sorry, sounds like bullsh_t. One can leverage mature markdown renderers in SwiftUI. See https://github.com/gonzalezreal/swift-markdown-ui and its next gen replacement https://github.com/gonzalezreal/textual .

Used these myself and had no issues. And I am a moron who doesn't like Swift or SwiftUI - preferred Objective-C, but still managed to do this, without any LLM help.