Live data from Hacker News

Native all the way, until you need text

justsitandgrin.im

241–250 of 328 posts

Re: Native all the way, until you need text

#241
post #39

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.

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

Using an HTML renderer to render arbitrarily formatted text with full HTML formatting capabilities makes perfect sense. If that's your problem statement, then you kinda need an HTML renderer.

Re: Native all the way, until you need text

#242
post #217

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

Not to turn this into an AI debate, but it will only take 8 months if you insist on coding manually.

I'm doing little video utility apps that I never would have attempted a year ago, because I know the challenges of AVFoundation all too well. But if I don't have to actually write that plumbing? Sure.

Re: Native all the way, until you need text

#243
post #217

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

You're assuming the text editor component alone took 8 months, but of course it did not! That would be crazy. There's a whole app built around the text component, which is what took my time, and the reason people are buying the app.

Development is ongoing for the features around the text component. I added folding lists which took a while, and because I offer outliner features I added focus/hoist which was also quite complicated.

Performance profiling and adjustments were measured and solved when I was almost done, because premature optimisation is a bad idea.

I don't consider what I did fighting any sort of limitations, so I guess it's a point-of-view thing. I wanted to use system components, and the only way to do that whilst maintaining performance is to do it with due care and attention. Nothing comes for free.

Re: Native all the way, until you need text

#244
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…

Not to turn this into an AI debate, but it will only take 8 months if you insist on coding manually. I'm doing little video utility apps that I never would have attempted a year ago, because I know the challenges of AVFoundation all too well. But if I don't have to actually write that plumbing? Sure.

It took me "8 months" because I had another job for part of that time, so I wasn't working on my apps for all that time. At the start of this year, I decided to tidy up the app for release...along with 20 others. https://news.ycombinator.com/item?id=47809151

Re: Native all the way, until you need text

#245

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…

Apple’s Journal app on macOS is a good example of falling standards for software over the years. There’s lag on every keystroke that grows the more you write. Eventually I will save the entry and start a new one because even cmd-a to select all will lag so much it seems like the app will crash soon. And nobody cares.

Re: Native all the way, until you need text

#246
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".

Using an HTML renderer to render arbitrarily formatted text with full HTML formatting capabilities makes perfect sense. If that's your problem statement, then you kinda need an HTML renderer.

The author wasn't trying to render HTML. Everyone is focusing on the word "Markdown", I wish the author had just said "rich text" instead so we could actually have a fruitful conversation.

Re: Native all the way, until you need text

#248
> Swift / SwiftUI

I basically don't take SwiftUI too seriously for shipping apps. It's great for test harnesses and admin dashboards, but the apps I make for general end-users are [usually -There's one exception] done with UIKit (I don't do much Mac programming, these days, but AppKit works great, as long as you are willing to roll up your sleeves).

Re: Native all the way, until you need text

#249
post #229

Earlier quoted context omitted.

My experience too, and that's not even touching the disproportionately high RAM usage of frameworks like Electron. Sure, "unused RAM is wasted RAM", until the system starts swapping heavily because of the high RAM usage. It doesn't even have to be old devices, there are still laptops being sold with 8GB of RAM in 2026.

This is so true. It even happens to me in my 16GB work laptop when I have to use multiple Electron apps at work. My personal 8GB Air is way faster. On the other hand, WebViews can be really fast without the baggage of Electron and Javascript frameworks/libraries.

JavaScript frameworks/libraries are very rarely the problem, Electron just has to bundle Node, V8 and Chromium (granted, V8 is deduplicated).

Electron apps are hungry for RAM, but in practice it is close to having a heavy tab active. The thing about browsers is that they are pretty aggressive at offloading inactive tabs but Electron apps never do that.

Re: Native all the way, until you need text

#250

Earlier quoted context omitted.

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

More importantly all HTML is valid markdown.

Also, there is no such thing as valid markdown.
Post reply on HN