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

311–320 of 328 posts

Re: Native all the way, until you need text

#311

Post by dormento »

dwroberts wrote: post #296
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…

> 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. Not trying to be unpleasant but these times are slow, right? 8ms is an entire frame at 120Hz, that’s an eternity

Congrats on shipping, OP!

> 8ms is an entire frame at 120Hz, that’s an eternity

While I agree in principle, do mind that this in on a mobile device. It may seem slow indeed, but I think this is somewhat mitigated by the fact that the performance of current Electron-based software lowered the bar a little bit, therefore it feels faster. If you spend your day using web-based stuff instead of native, it may certainly feel so.

Re: Native all the way, until you need text

#312

Post by PaulDavisThe1st »

danielvaughn wrote: post #186
PaulDavisThe1st wrote: post #95

Earlier quoted context omitted.

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).

Given how much shit the web gets from native developers, yeah kinda? They make it seem like it's light years ahead of the web, often arrogantly so.

For trees of interacting widgets, it is.

For text presentation, not so much.

Re: Native all the way, until you need text

#313

Post by tnorthcutt »

msephton wrote: post #265
dataflow wrote: post #261

Earlier quoted context omitted.

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

> 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.

Some people use an iPad as their main at-a-desk/stationary computing device, so that might not be as much of an edge case as you'd think. But maybe it still is; maybe those people aren't prone to editing large text files.

Re: Native all the way, until you need text

#314

Post by tmp10423288442 »

jeroenhd wrote: post #54
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

LLMs are often used to generate Markdown because they're quite good at it and unlike HTML it's very forgiving. Rendering text into things like chat bubbles or even just generic output panes as it comes in is a massive pain. Every new word requires redoing layout, detecting LTR versus RTL flows and overrides, figuring out word breaks and line breaks, possibly combined with resizing the containing UI element (which inv…

HTML is famously forgiving as well - that's the whole reason XHTML failed, because one typo in the latter will make your entire web page fail to render with an error. Markdown is probably a little more forgiving, which mattered more with previous-gen LLMs with small context windows. Any near-frontier model should have no problem generating valid HTML.

Also a lot of LLMs are trained specifically to expect Markdown in their instructions, OpenAI's models in particular (Anthropic expects more pseudo-HTML/XML, but that is different from real HTML/XML).

Re: Native all the way, until you need text

#315

Post by mananaysiempre »

mananaysiempre wrote: post #235
dive wrote: post #217

Earlier quoted context omitted.

It makes sense when the editor is a core feature of your paid product. I understand the sentiment. But is not it strange that I would need 8 months & a "development is ongoing" mindset just to render Markdown (which is very secondary to the main app features, and mostly just a user convenience people expect in 2026) with a custom low-level solution, effectively playing hardcore engineer instead of building what I act…

> just to render Markdown Rendering text beyond ASCII is famously difficult to do; rendering formatted text is sometimes difficult to even make sense of (e.g. what should a style change in the middle of an Arabic word do? how about a selection boundary being moved with arrow keys?); rendering honest-to-goodness Markdown, which can technically include arbitrary HTML tags, is nowhere in the vicinity of a small project.…

> a different one whose results embarrass a typographer

whose results won’t embarrass (of course; sorry)

Re: Native all the way, until you need text

#317

Post by cybercatgurrl »

Klonoar wrote: post #272
kenferry wrote: post #208

Earlier quoted context omitted.

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.

Also NSAttributedString would invoke WebKit under the hood if you went to render an HTML string.

this is the correct answer

Re: Native all the way, until you need text

#318

Post by cybercatgurrl »

LtWorf wrote: post #230
nly wrote: post #24

Earlier quoted context omitted.

Qt made this pretty easy 10 years ago

Why pay a license fee when you can make a bloated and slow electron app instead?

exactly! paying a licence takes away valuable money that could be better served by buying the shareholders a new yacht!

Re: Native all the way, until you need text

#319

Post by cybercatgurrl »

andix wrote: post #236

For rich text rendering HTML and browsers are simply the best. Highly optimized. For simple layouts (like rendered markdown) they are incredibly fast. On most platforms it's quite easy to embed a browser in a frame (show a changelog, an email, or a page of interactive charts). With a few tweaks this can feel completely seamless. It becomes really painful (or impossible) though, if you need those complex text renderin…

i’m pretty sure you just justified ChromeOS’s existence
Post reply on HN