31–40 of 328 posts
that's it, for everything else native UIs are complete garbage compared to HTML/CSS/reactive frameworks.
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.
By "streaming" text, I mean a formatted text stream that has to be parsed, formatted, and appended on the fly - basically how every model/AI chat works now. And this is where `NSTextView` becomes tricky. It forces an interesting architectural choice: either go deeper into AppKit with `NSCollectionView`, custom cells, manual layout, etc., or fight the whole SwiftUI model by embedding something like `NSTextView` inside `LazyVStack` / SwiftUI views & then dealing with all the integration problems.
So I am not saying Cocoa / AppKit was always bad, or that `NSTextView` is useless. I am saying that for modern chat-style UI with incrementally rendered formatted text, it does not compose well with the rest of the modern Apple stack.
Earlier quoted context omitted.
The purpose of limiting memory use is so your computer does not become laggy as you run out of memory. We don’t do it for its own sake. But then, what’s the point in using an inherently laggy technique to save memory?
How about running many tasks on the machine at the same time?
Earlier quoted context omitted.
For just rendering (no editing) you could use https://github.com/litehtml/litehtml (C) or https://github.com/DioxusLabs/blitz (Rust). Both are actually lightweight HTML rendering libraries, so you need to compile markdown to HTML to use them. But there are many libraries for that.
Does it mix well with text input? What I really want is a native WYSIWYG Markdown editor - in a similar fashion to Typora (Electron) or Milkdown (a JS library).
litehtml appears to have no built-in text input support so far as I can see.
How is "performance" defined? Does it take into account the amount of memory required in each case?
a fast performant incomplete solution will lose to a slow correct complete one
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.
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.
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.
I don't understand how you go from "rendering text is completely appropriate" but then "rendering everything is ridiculous".