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

Re: Native all the way, until you need text

#91

Post by tom1337 » Sun, May 17, 2026, 1:57 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…

System Preferences also sometimes just render a WebView - most notably in the Apple Account settings

Re: Native all the way, until you need text

#92

Post by the_gipsy » Sun, May 17, 2026, 1:57 PM UTC

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.

Re: Native all the way, until you need text

#93

Post by StilesCrisis » Sun, May 17, 2026, 1:57 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/…

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

Re: Native all the way, until you need text

#94

Post by rubymamis » Sun, May 17, 2026, 1:57 PM UTC

bluGill wrote: post #26

chromadon wrote: post #11

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

It is tricky, but it is not unheard of to write Qt applications as something other than C++.

These days you write the logic in C++ and UI in QML which is a very pleasent experience.

Re: Native all the way, until you need text

#95

Post by PaulDavisThe1st » Sun, May 17, 2026, 1:58 PM UTC

danielvaughn wrote: post #63

joenot443 wrote: post #52

Earlier quoted context omitted.

It's quite literally called Link https://developer.apple.com/documentation/swiftui/link I'm not sure how much easier they can make it at this point.

When I say "this stuff" I'm not talking about a link, I'm talking about the overall markdown/text capabilities that the post is talking about. I meant that I expected more parity with what you'd encounter on the web.

You expected highly capable, generic GUI toolkits to show parity with a development environment that has specifically targetted text above all else (though with lots of other stuff and great depth too) for decades?

Even in an era of PWAs and highly reactive UIs, the web is still fundamentally a document presentation mechanism. No generic GUI toolkit fits that description (even if they can be coerced into being one).

Re: Native all the way, until you need text

#96

Post by krzyzanowskim » Sun, May 17, 2026, 1:58 PM UTC

dive wrote: post #78

krzyzanowskim wrote: post #69

"skills issue" but also "native" frameworks are lacking polished API. On macOS TextKit2 is unfortunately kinda broken, how do I know? I reimplemented TextView with it https://blog.krzyzanowskim.com/2025/08/14/textkit-2-the-prom...

Hey Marcin, Skill issue, I guess. I even tried your SSTextView (which is a very nice piece of software, by the way), though it does fit here, but I tried to understand how wrong my TextKit2 implementation is. In my tests, the SSTextView performed a bit worse with p95 on the static markdown scroll test (70.20 ms vs 16.7 ms for per frame rendering). But it is clear from the traces that SSTextView just does too many thi…

totally. the there's a lot complexity that adds up to the overall performance issues. and TextKit 2 IS pretty bad at things. especially public API is pretty bad - that result in my case need to workaround things that I should've not. I agree with the general sentiment et all. I also still believe there is a place without bringing the whole browser machine to render text, and have text under control - but without relying on the "TextKit" level. That's the next thing I'm researching right now.

Re: Native all the way, until you need text

#97

Post by jeremyjh » Sun, May 17, 2026, 1:58 PM UTC

teddyh wrote: post #71

I know nothing about any of these APIs, but the claim of the article seems weird. If naitive APIs are insufficient, or slow, or unsuitable, and implementing your own is too hard, then how does Electron even do what it does? One would assume that Electron has its own library to accomplish the task, in which case this code could either be separated, or re-created once and for all, into its own re-usable library.

> I know nothing about any of these APIs

Agreed. In Chromium all the content from HTML is rendered inside a single object from the point of view of the host UI; much like a game engine’s UI rendering. Chromium draws everything itself. Host events like mouse and keyboard events are sent to that top level object (although there are some shenanigans involved to make it look more native to accessibility tools).

Re: Native all the way, until you need text

#98

Post by StilesCrisis » Sun, May 17, 2026, 1:58 PM UTC

iTokio wrote: post #82

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…

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.

Re: Native all the way, until you need text

#99

Post by lewisjoe » Sun, May 17, 2026, 2:01 PM UTC

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?

Re: Native all the way, until you need text

#100

Post by StilesCrisis » Sun, May 17, 2026, 2:02 PM UTC

Klonoar wrote: post #74

replygirl wrote: post #37

Earlier quoted context omitted.

OP says "you want to select a whole Markdown document built from SwiftUI primitives", but who wants that? what sort of product thinking tells us we want that? that sounds like a document editor, which has been hard to build for decades and sounds out of scope for an llm chat ui. everyone has landed on only supporting selection within each contiguous block, with a copy button for the entire message

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.