Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Native all the way, until you need text

justsitandgrin.im

Post reply on HN
Print view View original

201–210 of 328 posts

Re: Native all the way, until you need text

#201

Post by 3836293648 »

ajross wrote: post #149
mpweiher wrote: post #131

Earlier quoted context omitted.

Except JavaScript isn't "crazy fast". Not by a long shot. How did Microsoft just make Typescript 10x faster? Oh right, by reimplementing it in Go. https://devblogs.microsoft.com/typescript/typescript-native-... See also: https://blog.metaobject.com/2015/10/jitterdammerung.html Please don't use Electron.

Meh. Flaming about this is so exhausting given that the war was already fought and we know who the winner is. First, that's the typescript compiler , not typescript apps. And it was a ground-up rewrite effort (a very large one) with a specific eye toward improving the performance of the original, which was widely held to be sub-optimal for reasons entirely unrelated to implementation language. Suffice it to say that,…

The typescript compiler is a typescript app. Or was, I guess

Re: Native all the way, until you need text

#202

Post by KerrAvon »

msephton wrote: post #129

I recently launched a text editor for iOS that uses TextKit 2 and is highly performant with files of 5,000 lines (I tested with Moby Dick from Project Gutenberg). I made it between Aug 2025 and Apr 2026, development is ongoing. Every keystroke is restyled in under 8ms: no debouncing, no delayed rendering. 20 rapid keystrokes are processed in 150ms with full restyling after each one. Tag and boolean searches complete…

It's likely the SwiftUI Mac implementation is subpar. SwiftUI-on-Catalyst might be a better choice for these applications, but it probably has other problems.

Re: Native all the way, until you need text

#203

Post by KerrAvon »

CharlesW wrote: post #114
rubymamis wrote: post #77

Earlier quoted context omitted.

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

> It's SwiftUI that is at fault here, not native apps in general. The article you cited is from 2022 and so is irrelevant, since SwiftUI's performance profile completely changed as of xOS 26. Claims like "It's hard to build a performant SwiftUI app" get into skill-issue territory, but more importantly, the reality is there are only "SwiftUI-first apps". All non-trivial SwiftUI-first apps will also use UIKit/AppKit as…

Can you point to a single performant, high-quality SwiftUI-first app with a messages-like chronological transcript and correct scrolling behavior on macOS? The problems with AppKit integration are real and should not be dismissed out of hand.

Re: Native all the way, until you need text

#205

Post by trinix912 »

the_gipsy wrote: post #138
throawayonthe wrote: post #105

Earlier quoted context omitted.

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

Still seems overkill. It's just headers, lists, block quotes, codeblocks, and a few inner emphasis and link formatters, basically. HTML is the whole jungle for a gorilla with a few bananas here.

It's still going to be faster than creating and moving around a bunch of NSViews simply because the WebView (native WebView, not Electron) renders the entire content at once, directly on the graphics pipeline, skipping all layout and compositor steps that get done on normal NS(Text)Views.

The key point here is to use the WebView only for the text view. Where it goes wrong is when people start writing entire interactive UIs in the WebView.

The other option would be PDFKit, but most people aren't nearly as comfortable programming with PDF as they are with HTML.

Re: Native all the way, until you need text

#206

Post by kenferry »

InsideOutSanta wrote: post #123
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.

If HTML engines are better than native UI libraries at rendering rich text, possibly the hardest thing UIs need to render, why would I not also use it to render easier things like buttons or text fields? Also, OS X rendered its UI with DisplayPDF/Quartz for the longest time.

The native Apple libraries are terrific at rendering rich text, it’s one of their strongest assets.

The poster’s issues seem to be specifically because they want to use markdown as the backing. The native rich text backing for native Apple views is attributed strings. They could translate the markdown to attributed strings, but seems like they don’t want to.

Re: Native all the way, until you need text

#207

Post by mh- »

LtWorf wrote: post #174
enbugger wrote: post #170

Earlier quoted context omitted.

I can't. But I'm sure I will be happier and richer person if I don't opt out self from a working stack in favor of saving 100-200mb RAM

You're off by an order of magnitude there.

super happier and super richer?

Re: Native all the way, until you need text

#208

Post by kenferry »

iamcalledrob wrote: post #156

Fun fact: This is how Apple used to do it too. Old versions of macOS / AppKit used to use WebKit to render rich text inside their native NSTextFields. Turns out text is hard :) And besides, the native WebView is super fast and lightweight, and its not unreasonable to use it as a text layout engine. You could use separate webviews for every row in a table and you'd still get fantastic performance. iMessage for mac use…

You’re confusing iOS and Mac OS here.

The Mac never used WebKit for NSTextField rendering. When iOS was first written, WebKit was used as the text renderer everywhere initially, including in UIKit controls (the “sweet solution”). This proved to be too heavyweight / cumbersome and the coretext/appkit text rendering approach was brought over.

Re: Native all the way, until you need text

#209

Post by longnguyen »

replygirl wrote: post #37
rTX5CMRXIfFG wrote: post #9

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.

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

I build an AI chat app for a living (20k+ customers) and I can tell you, everyone has been asking for that.
Post reply on HN