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".
Native all the way, until you need text
241–250 of 328 posts
Re: Native all the way, until you need text
#242I 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…
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
#243I 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…
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
#244Earlier 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.
Re: Native all the way, until you need text
#245I 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…
Re: Native all the way, until you need text
#246Earlier 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.
Re: Native all the way, until you need text
#247Re: Native all the way, until you need text
#248I 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
#249Earlier 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.
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.