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

261–270 of 328 posts

Re: Native all the way, until you need text

#261

Post by dataflow »

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…

> 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'm so confused by this comment. 5,000 lines is an absolutely minuscule size. Even the file you tested with is longer than that -- I'm seeing > 22,000 lines in [1]. Even Window's built-in Notepad doesn't flinch when opening something that small.

Text viewers need to handle files that are two orders of magnitude larger, at least. I easily have JSON files that are hundreds of thousands of lines long, and CSV & log files that are even longer.

Re: Native all the way, until you need text

#262

Post by bigstrat2003 »

bonesss wrote: post #140
CharlesW wrote: post #110

Earlier quoted context omitted.

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.

If you account for dev time, ‘giving up’ and just doing it in a web renderer is totally valid. Choppier, more memory, bad if the device is failing, but 98% of the time that can be acceptable. Native GUI dev, tho, can enable low-resource performant apps just by sticking the rudimentary OS is a way no higher app really can, and with capabilities that’d choke a web app. Load up a listbox with a few tens of thousands of…

Doing it in a web renderer is only valid if you don't care about the quality of the software. Software using a web renderer absolutely sucks to use for the user.

Re: Native all the way, until you need text

#263

Post by bigstrat2003 »

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

Electron does not, in fact, work great. Apps which use Electron are an absolute drag for the user because they are slow, use a ton of memory, or both. Any developer who cares one iota about the quality of his software will try to avoid Electron.

Re: Native all the way, until you need text

#264

Post by Bolwin »

kenferry wrote: post #206
InsideOutSanta wrote: post #123

Earlier quoted context omitted.

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.

..where did you get that impression?

The web also requires you to convert to html. I don't see how this is different

Re: Native all the way, until you need text

#265

Post by msephton »

dataflow wrote: post #261
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…

> 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'm so confused by this comment. 5,000 lines is an absolutely minuscule size. Even the file you tested with is longer than that -- I'm seeing > 22,000 lines in [1]. Even Window's built-in Notepad doesn't flinch when opening something that small. Text viewe…

I'm going from memory here, time marches on never-ending, so please forgive me. I conflated two things: my performance test results are from the first 5,000 lines of Moby Dick. Why 5,000? One user has a 5,000 line taskpaper note file. But the whole 22,000 line book loaded and scrolled and edited just fine (after I fixed some bad assumptions that resulted in bad code). On iOS, I think if you're working on a file of 5,000 lines then something might be wrong, and if you're working on a file of 22,000 lines well I don't know what to say.

Re: Native all the way, until you need text

#266

Post by msephton »

virgil_disgr4ce wrote: post #188
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…

> If I can do it on iOS then it's must be 10x easier on macOS. I strongly doubt this. I suspect it's the exact opposite situation. But I'd like to hear from someone who knows.

I stand by the claim. But what do I know? ;)

Re: Native all the way, until you need text

#267

Post by Bolwin »

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

This is the default on the web and most people expect it . I much prefer it

Re: Native all the way, until you need text

#269

Post by f30e3dfed1c9 »

lokimedes wrote: post #213

We did https://markant.md with TextKit 1, flies through multi-megabytes markdown files with latex rendering etc. took some scaffolding (like only rendering attachments when they are close to the viewport) to make it smooth, but it wasn’t really a big problem.

This app is a good idea but the help refers to a "Help > Install Command Line Tool" menu item that does not appear to exist.

Re: Native all the way, until you need text

#270

Post by ajross »

bigstrat2003 wrote: post #263
ajross wrote: post #149

Earlier quoted context omitted.

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

Electron does not, in fact, work great. Apps which use Electron are an absolute drag for the user because they are slow, use a ton of memory, or both. Any developer who cares one iota about the quality of his software will try to avoid Electron.

> Electron does not, in fact, work great.

People get so outrageously bent out of shape over the details here. But it's 100% just geek nattering. People who need to develop and ship general use UI code that isn't a game or an iOS app write to the web stack, every time, for very good reasons. And these solutions win every market they're in.

Basically: show me someone displacing VSCode (or any other large established Electron app) or GTFO. Won't happen. The reverse happens all the time, though. How's Eclipse doing these days?

Post reply on HN