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

Re: Native all the way, until you need text

#101

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

krzyzanowskim wrote: post #84

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…

SwiftUI, (but not specifically "SwiftUI", more of paradigm) is not the right tool to incremental changes of large portion of data, and SwiftUI specifically is very bad at it and offer no good API to make incremental changes more optimal. That's one of the reason behind why Apple to this day did not ship usable SwiftUI text view component.

They did last year. I can understand why you're confused, since it came in the form of the radically-improved `TextEditor`. https://wwdcnotes.com/documentation/wwdcnotes/wwdc25-280-cod...

Re: Native all the way, until you need text

#102

Post by titzer » Sun, May 17, 2026, 2:03 PM UTC

Electron runs like crap on older hardware. It's sad that native UI frameworks never got their shit together, but I think if you want performant text rendering you just gotta reduce your expectations. If you're fine with less fancy fonts and "scripting" your UI in something else than JS, then native can work. But it very quickly reveal that you should avoid everything that uses JSON. JSON is just a disease vector for the JavaScript world to infect everything else.

Re: Native all the way, until you need text

#103

Post by titzer » Sun, May 17, 2026, 2:04 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…

> Browser rendering engines are pretty mature at this point, with significant GPU acceleration, and over a decade stress-testing by bloated web apps.

They suck on older hardware. Old Chromebooks are a dime a dozen and are decently spec'd light use or purpose-use machines. Browsers run like crap on them.

Re: Native all the way, until you need text

#104

Post by BillStrong » Sun, May 17, 2026, 2:04 PM UTC

I think the article misses the actual point?

The browser is faster because they went native, in particular, GPU.

Every issue described is text rendering related. Everyone.

And I would bet most of the SwiftUI issues could be solved with a text render cache.

Something like Casey Murati's refterm toy that showed what that can do with no other optimizations, or the work for GPU accelerated terminal emulators like alacritty or ghostty.

Re: Native all the way, until you need text

#105

Post by throawayonthe » Sun, May 17, 2026, 2:05 PM UTC

the_gipsy wrote: post #92

Wowfunhappy wrote: post #19

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.

> Using WebKit to render Markdown seems completely appropriate. It doesn't? Needs an explanation.

markdown is a markup language 'intended' to be rendered as HTML, WebKit seems appropriate to render HTML

Re: Native all the way, until you need text

#106

Post by cluckindan » Sun, May 17, 2026, 2:07 PM UTC

lewisjoe wrote: post #99

zhxiaoliang wrote: post #89

I understand your pain. That’s why I’ve ported my VMPrint layout engine to Rust. It’s early, but it already shows promising performance improvements over the original TypeScript-based engine, which is already very fast. The Rust version can create fully paginated, publishing-grade layout at around 8,500 pages (or 2,000,000 words) per second on a M4 MacBook. It’s even faster at advanced tasks like mixing texts with ir…

Just checked out VMPrint and it's crazy! Keep up the efforts. If you/someone could get a HTML/CSS input layer in front of VMPrint that would be a killer feature? Or is it possible already?

HTML/CSS is notoriously bad for print.

Basic text styles are ok, but things like authored pagination, page header/footer, mirrored margins, margin notes, footnotes and references are basically unsupported or need to be hacked together.

Re: Native all the way, until you need text

#107

Post by Klonoar » Sun, May 17, 2026, 2:07 PM UTC

StilesCrisis wrote: post #100

Klonoar wrote: post #74

Earlier quoted context omitted.

sounds out of scope for an llm chat ui What? No. This is like building a Slack clone without the ability to copy a stream of messages. It is entirely reasonable to want to do this.

Slack also basically fails at this. You end up getting a jumble of timestamps, names and messages.

Yeah... people expect that when they copy chat messages. It's correct behavior.

Re: Native all the way, until you need text

#108

Post by ben_w » Sun, May 17, 2026, 2:08 PM UTC

jagged-chisel wrote: post #27

danielvaughn wrote: post #10

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'…

I thought attributed text handled this fine since forever. Did it not?

I vaguely remember doing this with attributed text for iOS 4.

That said, I also had quite a lot of success on iOS 4 using HTML as the layout engine for the main screen of the app, though the place ran out of money before that went anywhere.

HTML can be really good, the blockers back then were it not being exactly the same as the Apple UI guidelines unless you put in a huge amount of extra work that nobody wanted to spend. I'm not sure when Apple's own guidelines stopped mattering exactly (iOS 7's invisible buttons necessarily had to be ignored, but there was already a decent level of custom UI before them and it was already essentially irrelevant even before Apple became extra-inconsistent with Liquid Glass), but I think we're now at the point where you only follow those guidelines if you (a) don't have your own UI team, and/or (b) want to try to aim for a shout-out from Apple.

Re: Native all the way, until you need text

#109

Post by carlosjobim » Sun, May 17, 2026, 2:10 PM UTC

Wowfunhappy wrote: post #55

stavros wrote: post #39

Earlier quoted context omitted.

But why would you expect to use WebKit to render rich text? If using an HTML/CSS/JS renderer to render text is "completely appropriate", what isn't appropriate for it? Why would you not render everything with it? I don't understand how you go from "rendering text is completely appropriate" but then "rendering everything is ridiculous".

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.

Re: Native all the way, until you need text

#110

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

StilesCrisis wrote: post #98

iTokio wrote: post #82

Earlier quoted context omitted.

Well, maybe for simple web apps, but for complex applications there is a noticeable slowdown, I am not even talking about monsters such as jira, but well optimized apps such as vs code, there is a performance ceiling which is lower than for native apps.

According to the article, native is slower though.

TFA actually says the developer couldn't figure out how to do this with native APIs, not that they're slower: "But I still cannot make a simple thing work properly: a chat with Markdown & the ability to select a whole message."

Electron ultimiately sits on native APIs, and has its own performance costs on top of them.