Native all the way, until you need text
justsitandgrin.im
justsitandgrin.im
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 in under 20ms. Visible-range rendering is 25x faster than full-document styling. 120Hz screen refresh supported.
App file size was 722 KB for 1.0, and 1.1 with more features is looking like ~950 KB.
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.
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 actually want to build?
Anyhow, my point is not that "it is impossible". My point in the article is that I understand why people choose web technologies over native for such things. They want to build products, not fight the system’s limitations.
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.
None of which is to say that you shouldn’t demand that a toolkit solve it for you, only that I understand why the RichEdit control reportedly had a separate team allocated to it in turn-of-the-millenium Microsoft. Working with a large amount of formatted text feels like it should be the most complicated feature of any UI toolkit and I shudder at the thought of even designing the API for it.
(A web browser is good at all this. It also has the API surface of a web browser.)
And some things will still be on you regardless. Did you know Android has two modes for text wrapping, one that won’t reflow the entire paragraph after a single-word change at the end and a different one whose results embarrass a typographer from half a millenium ago? That’s very much the correct way to do things, but if you’re streaming text in, it’s on you to decide whether you want subpar wrapping throughout or a layout jump whenever a paragraph break arrives. Most importantly, it’s on you to know the question exists; there are more, some more important than this one.
(Modern toolkits aren’t the only ones that can be bad at scaling to large amounts of data, either. Notably, Microsoft had to write an entire new “windowless” one to replace USER’s heavyweight window-based one so that Access wouldn’t collapse under its own weight. They then reused it for IE, for similar reasons. Raymond Chen’s response[1] to complaints about that toolkit staying private to Microsoft amounted to “fuck off”.)
[1] https://devblogs.microsoft.com/oldnewthing/20050211-00/?p=36...
whose results won’t embarrass (of course; sorry)
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.
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.
They could not have made their point more clearly but people like you are up and down the thread wanting to call “skill issue”. The reality is that nobody gives a shit and they want to ship interesting things fast; if OS makers won’t get the hell in line and offer APIs to do it, then these developers are going to just pick Electron.
Life is way too short to sit down and write half a damn text editor when all you wanted to do was shit out a basic application with blobs of markdown.
It's not personal, but yes, you're being intentionally obtuse to OP's point.
> and it's not an opinion or theory because I've proven it by shipping an app
You are once again downplaying the level of effort difference that OP is describing, thus missing the point entirely.
> if you bend it the wrong way you'll get bad results
OP did not bend it the wrong way, they tried several different approaches because it wasn't working as intended off the bat (i.e, without bending).
OP's point was never that things were "not possible", it's that it's a stupid amount of effort for table-stakes functionality. If you don't get that point by now then I don't think you'll get it at all.
So the reader is free to accept my story about my shipped app and my assurance that it didn't take unreasonable effort, or accept a blog post complaining how difficult things are that has no code or shipped app at the end of it.
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.
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.
Not trying to be unpleasant but these times are slow, right? 8ms is an entire frame at 120Hz, that’s an eternity
This feels instant on iOS, and scientifically it's faster than almost all keyboards, which have latency between 15ms and 60ms: https://news.ycombinator.com/item?id=33817626 and the best computer latency was the Apple IIe at 30ms https://news.ycombinator.com/item?id=16001407 a network packet takes 190ms to go round the world, that's certainly longer but still not quite an eternity.
Also, you are of course free to do better :)
> 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.
Browser rendering engines are pretty mature at this point, with significant GPU acceleration, and over a decade stress-testing by bloated web apps.
Meanwhile SwiftUI doesn't feel particularly fast. Apple's latest and greatest rewrite of System Preferences has dumbed down the UI to mostly rows of checkboxes, and yet switching between sections can lag worse than loading web pages from us-east-1.
Even so, there is a stark difference, even more so on low-powered devices, between native apps and even the lightest of browser apps. I'm traditionally a web developer, but started developing native cross-platform applications the last 6-12 months, and the performance gap is pretty big even for simple stuff, strangely enough.
It doesn't even have to be old devices, there are still laptops being sold with 8GB of RAM in 2026.
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.
In reality we’re stuck with 2-5 electron/CEF apps plus whatever is running in browser tabs as well as whatever webviews system stuff are running, which all quickly pushes into VM paging territory on low memory devices.
That’s because SwiftUI isn’t particularly good, not because web rendering is as good as native. AppKit still runs circles around both, in performance and resource consumption.
Predicting a surge in RAM supply after a surge in RAM demand and a huge increase in RAM margins is economics 101.
The open question in my mind is for how long semiconductor demand will continue to grow faster than we can increase production capacity.
I am currently working on something I call HTMXNative, which is what it sounds like: using HTMX in WebViews for hybrid apps.
I haven't really looked much at memory consumption, but when I've looked so far it's been very comparable to equivalent apps using native UI.
If you run gargantuan layers of JS frameworks in a WebView it will perform just as badly as a full browser. After all, a browser is (more or less) just a process wrapped around a WebView.
[1] https://notes.alinpanaitiu.com/SwiftUI%20is%20convenient,%20...
Their point is more that SwiftUI has generally poor performance. Lots of native Windows frameworks have poor performance as well.
Native UI development is a minefield. If you want to build an app today that will still run in 20 years without a complete rewrite in the UI layer you should probably use wxWidgets if you are committed to native - even if only targeting one OS. But that model is really only appropriate for building traditional desktop apps. I don’t think the market would accept a Slack or Notion built that way today.
I have no idea if this is the case with P4V, but it absolutely is the case with a few other things I use.
I'm just bitter about a couple of apps I use that are all permanently stuck on Qt4 where the vendor seems to have zero intention of caring to ever update them to a newer version of Qt. And ever since getting a HiDPI display, this has been continuously irritating me.
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 needed, typically for capabilties that aren't yet available via SwiftUI.
WebKit have had great performance for a very long time now.
Why would any startup dare to use tech that only now got fast? Why not go with the battle tested WebKit?
It is also much easier to develop and test html pages than Apple specific tech.
I don't know why SwiftUI evangelists are still doing this in 2026. How many examples of SwiftUI's poor performance have to be demonstrated over the years? Even basic things like List continue to lag behind NSTableView in the most recent releases.
Was my initial naive implementation as performant? No. My point is that optimization still matters in SwiftUI, and that optimization looks quite a bit different in SwiftUI than it does in AppKit/UIKit.
This guy run a benchmark vs. AppKit and SwiftUI is still slow in macOS26
https://github.com/lemonmojo/swiftui-hierarchical-list-perfo...
Leave SwiftUI to the settings pages. The gulf between AppKit and SwiftUI in macos desktop I'm not as sure about.
Electron ultimiately sits on native APIs, and has its own performance costs on top of them.
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 items with custom rendering… as a fat client dev you’re only in a little trouble, on the web googlers making google apps force pagination a whole lot.
As a point of comparison: WPF was Microsoft’s attempt to nail the ‘best of the desktop & best of the web’ [And I would argue they effectively nailed it, as a specification.]. But, as a brown belt WPF dev and a blue/orange belt with Win32/MFC, the extra overhead related to WPF broke common scenarios we’d never think twice about on the true native side. The web was made for sharing Robotech technical manuals, OS GUI’s to pump all the rectangles as fast as hardware allows. Apples and oranges.
For sure, all software is chock full of "best? no/works? yes" compromises. I object to the article framing of "I couldn't figure it out, therefore TextKit 2 does not play well with anything modern", which is a very silly conclusion.
I was agreeing and providing more context to the costs of building at a higher level, like Electron, and the limits even when applied by a unified vendor with incentives for high performance.
(I do give them credit for some terrible usability elements that would delay a scammer if they had our elderly relative on the phone.)
The AppleScript that has to be written and rewritten to flip a simple switch in settings… (it’s telling the system to move around and click in the UI by count, and the count gets thrown off by what I now suspect to be unpredictable web view UI loading)
They suck on older hardware. Old Chromebooks are a dime a dozen and are decently spec'd light use or purpose-use machines. Browsers run like crap on them.
If you dig up an 18 year old Core 2 Duo box, upgrade its storage to a cheap SSD, and install Linux on it, it’s shocking how snappy and usable it is for most tasks… up until you open a web browser or Electron app. Then it all falls apart.
Had it not been for resource creep driven overwhelmingly by heavy web apps and Electron/CEF, there’d be little reason for most people to use anything more powerful than a Sandy Bridge machine and we could have laptops and smartphones with week-long battery life thanks to efficiency gains not needing to be consumed by performance increases.
Can confirm. I'm typing this on such an old Core 2 Duo laptop running Debian and even with only 4GB of RAM and a mechanical HDD, it's still very fast for everything I do on it that doesn't involve Web browsers. Windows 10 is practically unusable on it however. The gazillion background things it insists on running bring it to a crawl, mostly stuck on disk I/O.
I installed NixOS minimal on there and a few apps to develop, and it was actually quite usable. Then I installed Skype on there and it was horrible and laggy.
Booting to the password prompt for the encrypted drive alone takes 10+s versus 1-2s. Then booting into desktop is also considerably slower (but oddly not 5x).
Then performance compiling is miles apart with 20x at minimum.
Yes, the “native” apps are still snappy but at any time you require compute you will feel the lack of power. Funnily enough it doesn’t seem to matter too much for the games that I play.
Also worth noting that if computers had been frozen at Skylake speeds for the past decade, it’s almost a certainty that more attention would’ve been paid to performance since that would’ve been the only way to make computers faster. Countless bits of low hanging fruit in optimization have been ignored because power increases have papered over them, and cumulatively their impact is significant.
Have you tried with stock ChromeOS?
Then the V8 team at Google just asked "well, what if we just made Javascript crazy fast instead?", and here we are. There's still room for native code in environments that don't map nicely to scalar scripting languages, but not a lot of room. Basically everyone is best served by ignoring that the problem ever existed.
It took the rendering side a little longer, but we're here nonetheless. There's still room for specialty apps with real need to exploit the hardware in ways not abstracted by the DOM (not 100% of it is games, but it's close to that). But for general "I need a GUI" problems? Yeah, just use Electron.
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.
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, hell no, you can't just transpile your code to Go and expect it to run faster. We all know it doesn't work like that.
But more broadly, landing with "Please don't use Electron" in the context of a comment about a MS product seems weird given the implementation framework of Microsoft's single most impactful new UI project of the last decade...
Just stop, basically. You lost. Use Electron. It works great and everyone else already does and proved you wrong.
Of course it's the typescript compiler. What else is an implementation of "Typescript" that you could actually make faster? And how would Microsoft go to all Typescript users and re-implement their code in Go? How would that work?
But that doesn't change the simple fact that the Typescript compiler written in Typescript was too slow:
"As your codebase grows, so does the value of TypeScript itself, but in many cases TypeScript has not been able to scale up to the very largest codebases."
And to fix that performance problem, they had to reimplement Typescript (aka "the Typescript compiler") in Go. And that made it 10x faster.
And I am not sure you got "just transpire your code to Go" from, because I sure as hell didn't write it. And if you know it doesn't work like that, and I sure as hell didn't claim it works like that, why did you introduce this straw man?
This is all plain facts.
So yes: please stop the flaming. And please stop using Electron. Dennard scaling hasn't been with us for some time now.
I admitted nothing of the sort. Where did you get that from?
On a comparable project, Microsoft determined that
(a) the performance of the existing JS solution was practically insufficient
(b) doing a rewrite while keeping JS would not be sufficient
(c) rewriting the TS/JS compiler in Go yielded an empirical speed boost of 10x.
And once again, I never claimed that "Go is 10x faster than V8". Please do refrain from these straw-men arguments, it is not conducive to a good discussion.
In general, however, it is true that JIT compilers perform far less well on real-world production code than they do on small synthetic benchmarks, and so the 10x performance penalty that Microsoft found empirically is well within the range of what is observed elsewhere.
Overview and links to research here:
https://blog.metaobject.com/2015/10/jitterdammerung.html
And remember: this was a response to this comment:
"well, what if we just made Javascript crazy fast instead?", and here we are."
JavaScript is not "crazy fast".
Whether it won or is otherwise just the bees knees is irrelevant. It ain't "crazy fast".
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?
I mean yeah its obvious that typescript had insufficient performance for the typescript compiler. They made a big public announcement about the rewrite to golang. It's pretty clear 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.
The typescript compiler uses v8 as a runtime to run itself and it used to be written in typescript. It was probably one of the biggest typescript apps there is.
Here are some reasons why they chose golang over v8:
* the memory allocation patterns of a compiler were a poor fit for the v8 JIT * the runtime is restricted to a single thread * JITs have to make a tradeoff between startup time and how much time they spend optimizing generated code, AOT compilation can spend more time optimizing while having a faster startup time which is critical for a CLI application, where the JIT cost is paid every time the program is started
You can even look at this blog post and see it for yourself: https://grokkingtechcareer.substack.com/p/the-real-reason-mi...
>Suffice it to say that, hell no, you can't just transpile your code to Go and expect it to run faster. We all know it doesn't work like that.
This is a straw man that nobody is proposing, but even a naive attempt would probably have some benefits, primarily relating to startup time and memory consumption.
>But more broadly, landing with "Please don't use Electron" in the context of a comment about a MS product seems weird given the implementation framework of Microsoft's single most impactful new UI project of the last decade...
>Just stop, basically. You lost. Use Electron. It works great and everyone else already does and proved you wrong.
Use Electron for the typescript compiler? Are you crazy? (note that ajross responded with this comment https://news.ycombinator.com/item?id=48170285)
I think macOS suffers the most since it is not that hard to port an iOS app to Mac, and Linux benefits the most.
It's crazy that people think it's a good idea to throw away thousands of manyears of optimization (and millions of manyears of field testing in real world) just to... Idk, write a lesser text render engine?
It's still true. There's no way around it, web views will always be slower.
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.
I don't understand how you go from "rendering text is completely appropriate" but then "rendering everything is ridiculous".
It'd be very silly to render a shader pipeline in WebKit. You could, but with Metal sitting right there, it would be silly.
But WebKit is the native UI for HTML, and Markdown is intended to be transpiled to HTML.
Quartz is a vector drawing engine whose output can be captured as a PDF and which is closely aligned with the PDF imaging model.
Window content was always stored as bitmaps.
AppKit used to generate the bitmap directly through CoreGraphics (PDF model). Now it uses Core Animation and Metal and no longer draws the bitmap directly.
Because rendering rich text correctly and consistently is one of the hardest problems in software. Bidirectional text, a million glyph shaping complexities, mixed content such as inline images and different text sizes, reflow that should take milliseconds, natural-feeling selection, etc etc.
No implementation comes even close to browser rendering engines in covering all of these.
And yes, I agree: on macOS, WebKit is a native OS framework. In that sense, it is "native". But I think it also supports the broader point I was making: if you want to work with rich text, Markdown, selection, typography, and long-form formatted content properly, web technologies quickly become the only viable option. I am not saying that using WebKit for a Markdown view is wrong. Quite the opposite, it is probably the most reasonable option available. The problem is that the "native" solution here is still effectively a web-rendering solution. There is a cost. Each `WKWebView` brings a WebKit engine with its own performance & memory overhead. So you cannot just sprinkle `WKWebView` everywhere & pretend it is free native macOS component as any other. My frustration is mostly that this is the answer. For this kind of UI, SwiftUI / AppKit / TextKit still do not give you a clean, modern, composable path that feels better than "just use WebKit".
But, like, of course they are. This is what HTML was built for. The other major standard would probably be RTF, but it's a bit less structured, and so less close to Markdown. HTML is the better pick.
If you subsequently want to style that HTML, so that every second-level heading uses a specific font, and every third-level heading uses some other font, and so on, CSS is the best way to do that.
So, yes, we're saying the same thing, but to me it's a bit like saying "If you want to find the answer to 2 + 2, addition is the only viable option." Well, yes!
I think the reason this feels kind of wrong is because that same HTML and CSS renderer you're using for Markdown also comes with an entire 3D graphics pipeline and audio synthesizer. Obviously, we should be able to answer 2 + 2 without opening Mathematica.
I guess the important technical question is whether simply creating a WKWebView also loads in all that other stuff. I would hope and expect the OS is smarter than that, and you can call WebKit for simple HTML without everything else coming along.
But I think my opinionated point from the article still stands: if you need rich text & good typography without fighting the platform, then web technologies quickly become the pragmatic choice.
For my app, I will probably continue with WebKit. It is the most reasonable middle ground for now. But in this situation, it is tempting to jump to something with a stronger rendering engine, like Chromium instead of WebKit, and start using the huge ecosystem of tools that already work. For example, https://diffs.com is one of the most tempting parts for me. The awkward thing is that embedding WebKit & calling it a day does not feel like a clean native solution either. You lose many of the native things you get when rendering through SwiftUI primitives, but you also do not get the full power & ecosystem of a proper web stack. And that makes it much easier to understand why so many companies (good & bad) choose Electron.
From an engineering perspective, even the fact that you can avoid this controversial middle ground entirely & build the app around web technologies from the start makes sense. It is not just laziness or ignorance of native platforms. Sometimes it is simply the more consistent & logical architecture.
WebKit is cheating I guess? Because it exists on other platforms?
Might as well use Java
It doesn't? Needs an explanation.
> The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions.
https://daringfireball.net/projects/markdown/
Using some semantic HTML as an occasional escape hatch is perfectly in line with this overall goal.
From your own quote. Embedding html absolutely violates the spirit.
HTML embedding as an escape was built in Gruber’s markdown from the start, and is part of why markdown is simple bordering on simplistic: https://daringfireball.net/projects/markdown/syntax#html
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.
That, and in-line HTML. https://daringfireball.net/projects/markdown/syntax#html:
“For any markup that is not covered by Markdown’s syntax, you simply use HTML itself. There’s no need to preface it or delimit it to indicate that you’re switching from Markdown to HTML; you just use the tags.
The only restrictions are that block-level HTML elements — e.g. <div>, <table>, <pre>, <p>, etc. — must be separated from surrounding content by blank lines, and the start and end tags of the block should not be indented with tabs or spaces. Markdown is smart enough not to add extra (unwanted) <p> tags around HTML block-level tags.”
Because of that, I think I would use a html renderer to render markdown. Because people allowing arbitrary HTML opens a huge can of worms I might also whitelist a restricted set of HTML.
> Markdown is a text-to-HTML conversion tool for web writers.
HTML embedding was also integral to it: https://daringfireball.net/projects/markdown/syntax#html
> Markdown’s syntax is intended for one purpose: to be used as a format for writing for the web. […] For any markup that is not covered by Markdown’s syntax, you simply use HTML itself.
Also, OS X rendered its UI with DisplayPDF/Quartz for the longest time.
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.
The web also requires you to convert to html. I don't see how this is different
It would make sense, for example, if you wanted to allow editing of the rich text and have the markdown be directly accessible by the user. The conversion of markdown -> attributed strings -> markdown would not produce the same raw text, which is a problem if the user can directly edit or view the markdown. The user hitting cmd-B in the text view to make something bold might end up scrapping some explicit formatting they did to the raw markdown.
Sorry, sounds like bullsh_t. One can leverage mature markdown renderers in SwiftUI. See https://github.com/gonzalezreal/swift-markdown-ui and its next gen replacement https://github.com/gonzalezreal/textual .
Used these myself and had no issues. And I am a moron who doesn't like Swift or SwiftUI - preferred Objective-C, but still managed to do this, without any LLM help.
- Static completed Markdown scrolling fails the new focused probe. Result: p95 18.86 ms vs 16.7 ms budget, max 232.49 ms.
- Long live Markdown/code update path also fails. Result: p95 59.33 ms vs 16.7 ms, max 75.94 ms. This is a separate but related stress case around large rich text surfaces during updates.
- Long-history scaling technically passes, but the numbers are not smooth-frame healthy: - 120 turns: total p95 21.35 ms - 500 turns: total p95 23.11 ms - 1000 turns: total p95 36.77 ms
Technically, it is not bad. However, it is a bit slower than my own solution & has similar performance gaps, mostly related to SwiftUI rather than the Textual implementation.
I used to use swift-markdown-ui for my app but the performance is nowhere near using a wkwebview. When streaming large documents with tricky elements like large tables, code blocks, nested quotes, you may even get beached ball. It never happened when using a wkwebview.
> Sorry, sounds like bullsh_t.
No... As a user, one thing I notice is that older, non-HTML-based apps don't seem to follow "the rules." Text that I should be able to select and push "control/option C" just isn't selectable, or copy doesn't work.
Then I realized that browsers (and everything based on them) introduced some new paradigms to UI that native UI frameworks just haven't kept up with.
(And I say this as someone who prefers native apps over web-based apps.)
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 involves measuring the render space, which is often implemented by rendering to a dummy canvas and finding out the limits).
Document editors have it relatively easy because humans type at a relatively low speed and pasting is a single operation (although pasting large amounts of text does hit the render performance of the UI). They're also often provide relatively limited features on phones.
If you want to render something like ChatGPT with similar features in native UI, youre going to need to find a fully-fledged document component or build one yourself. And, as it turns out, we have document components that work quite well: web engines.
If you embed a webview rendering just HTML and CSS, you get better performance, features, and accessibility than any home-grown renderer will provide. And with every major OS coming with a browser built in, it won't even bloat your app.
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).
What? No. This is like building a Slack clone without the ability to copy a stream of messages. It is entirely reasonable to want to do this.
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 used to use a webview too. Adium as well. HTML is absolutely the right tool for the job if you're rendering rich/marked-up text.
1. Discover complex native text rendering is hard
2. Render text in a low-level way, complain about having to (re)implement native interactions
3. Try WebKit and it works great!
4. Throw WebKit away??
5. Have to re-implement native interactions??
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.
"Qt comes with Dual Licensing, which includes both commercial and open source options. To build a proprietary mobile application, you need the Commercial Qt license, within which Qt for Application Development is sufficient for pure mobile and desktop app development."
That said, I also had quite a lot of success on iOS 4 using HTML as the layout engine for the main screen of the app, though the place ran out of money before that went anywhere.
HTML can be really good, the blockers back then were it not being exactly the same as the Apple UI guidelines unless you put in a huge amount of extra work that nobody wanted to spend. I'm not sure when Apple's own guidelines stopped mattering exactly (iOS 7's invisible buttons necessarily had to be ignored, but there was already a decent level of custom UI before them and it was already essentially irrelevant even before Apple became extra-inconsistent with Liquid Glass), but I think we're now at the point where you only follow those guidelines if you (a) don't have your own UI team, and/or (b) want to try to aim for a shout-out from Apple.
https://developer.apple.com/documentation/swiftui/link
I'm not sure how much easier they can make it at this point.
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).
For text presentation, not so much.
The specific ask was already a bad idea.
Well yeah. If people don't invest sufficient effort in a thing why would there be an expectation for that thing to become mature? People are locked into web tech because that's where the greater majority of the effort has been going. Quite literally people look at native, say it isn't developed enough, and go develop for the web even more. Cycle repeats. Hardly anyone wants to put in the effort to improve native when things already "just work" for the browser.
It's a tragedy of the commons.
I think SwiftUI etc al don't work on Linux and Windoes and Android, right? While HTML works?
I'm using what I learned to create a native LLM client with a streaming Markdown parser[2].
You can still use native controls for the rest of the UI and have 0 Javascript running. I'm not sure I understand what the problem with NSTextView was though. It's pretty performant as far as I can tell?
Not exactly sure what “streaming” text is, but serial terminal software has been handling incremental text rendering and updating for decades, without performance struggles.
By "streaming" text, I mean a formatted text stream that has to be parsed, formatted, and appended on the fly - basically how every model/AI chat works now. And this is where `NSTextView` becomes tricky. It forces an interesting architectural choice: either go deeper into AppKit with `NSCollectionView`, custom cells, manual layout, etc., or fight the whole SwiftUI model by embedding something like `NSTextView` inside `LazyVStack` / SwiftUI views & then dealing with all the integration problems.
So I am not saying Cocoa / AppKit was always bad, or that `NSTextView` is useless. I am saying that for modern chat-style UI with incrementally rendered formatted text, it does not compose well with the rest of the modern Apple stack.
Or well... since we now have Claude I might have a jab at this someday in my free time.
Both are actually lightweight HTML rendering libraries, so you need to compile markdown to HTML to use them. But there are many libraries for that.
litehtml appears to have no built-in text input support so far as I can see.
Of course blitz doesn't expose a FFI either and also if you need anything interactive you have to use the dioxius framework or implement you own APIs for that as well as take care of animation yourself.
Not sure if my Sciter qualifies as a native solution.
Check this chat alike virtual list with MD items: https://sciter.com/wp-content/uploads/2026/05/virtual-list-m...
Yes, MD gets translated to DOM tree. But virtual list implementation in Sciter is a native thing. Load whole chat is not an option usually. Yes, JS is used in process but mostly as a configuration option: take output of one native function -> transform it -> pass as an input to other native function.
Essentially there is no so significant difference with any other SwiftUI/TextKit solution. It is just a difference in terms - SwiftUI uses tree of Views that is conceptually the same as DOM tree in terms of Sciter.
There’s really nothing else out there that competes with a similar performance and productivity.
This old article by the Missive team (the email client) convinced me.
https://medium.com/missive-app/our-dirty-little-secret-cross...
Skill issue, I guess. /s
So I think the text view is pretty low level so that it can support this.
Agreed. In Chromium all the content from HTML is rendered inside a single object from the point of view of the host UI; much like a game engine’s UI rendering. Chromium draws everything itself. Host events like mouse and keyboard events are sent to that top level object (although there are some shenanigans involved to make it look more native to accessibility tools).
Skill issue, I guess. I even tried your SSTextView (which is a very nice piece of software, by the way), though it does fit here, but I tried to understand how wrong my TextKit2 implementation is. In my tests, the SSTextView performed a bit worse with p95 on the static markdown scroll test (70.20 ms vs 16.7 ms for per frame rendering). But it is clear from the traces that SSTextView just does too many things I do not need. At least, I had my confirmation that I am not completely wrong about TextKit.
I remember spending 4 hours to make a scrollable element that wasn't jumpy or buggy. There were several stackoverflow answers full of gotchas explaining all you had to do. I finished and published the app but never again. Native stuff has terrible developer experience.
Yeah those early days ~2010ish were very painful. Things got much better as early as 2016 and they have improved each subsequent year since.
I'd say there has never been a better time than now, in terms of tooling, to pick up native Android.
Plenty of rough edges still around though.
There are even parts of both Windows and MacOS rendered through HTML. If I remember correctly, at least in Windows 10, File Explorer was rendered through Internet Explorer.
Web rendering doesn't need to be only through Electron/Node. There are other libraries much more performant and lean (Dioxus, etc).
Not in the world of macOS and iOS at least. Here native apps still rule, as there's literally no performant alternative (the OP's complaints about Markdown are misplaced - there's been no interest in MD and SwiftUI and that's why there's no good option. But in ObjC/Swift there is).
In fact, most of the apps I am using on a day to day is native. The Electron apps I use are okay (e.g. Slack) but they absolutely fail the native Turing test.
What does this mean?
Wayland is another product of this hardships, going wayland native seems only feasible when all stars align around it. But then you are stuck in that place.
That being said, without deeper knowledge about SwiftUI, I find it a bit odd to expect so much from a novel concept. Native desktop dev is already kind of niche, considering the dominance of web dev. Chrome (and it's artifacts) is probably the best funded software in the world and google's incentive to improve it is above all. It's not a miracle that it just works. It's effort and tons of cash.
This is a common misconception among programmers, and is actually the opposite of the truth. Drawing arbitrary geometric shapes is easy, rendering text correctly is insanely difficult because ... humans.
that's it, for everything else native UIs are complete garbage compared to HTML/CSS/reactive frameworks.
HTML/CSS/JavaScript looks fine for things where there's more style than substance but once we're talking about the desktop apps that engineers (no matter the discipline) are using, suddenly it's not so much HTML+CSS anymore or is it?
Basic text styles are ok, but things like authored pagination, page header/footer, mirrored margins, margin notes, footnotes and references are basically unsupported or need to be hacked together.
Why not Typst?
Typst is excellent for authored documents and produces beautiful output. It is also a Rust binary. You cannot import it into a Node process, run it in a browser, deploy it to a Cloudflare Worker, or call it as a library from a TypeScript application. If you need a layout engine embedded in a JS or TS runtime, Typst is not available to you.
My first experiment was to wrap it in a set of APIs called Layoutmaster. They work natively with the browser’s text systems to bypass DOM overflow. It was very fast... faster than the browser in many cases. This made me wonder if it would be faster in Rust so I made a port just for fun.
Turns out, the TS version was fast -- over a thousand pages per second, but the Rust version is quite a bit faster. It's still not fully optimized though. Still working on it.
I have no intention to use it for document generation unless there is a demand for it. For now I’m more interested in how this native engine can help with frontend jobs like creating a native live-editing surface without a browser.
But then, what’s the point in using an inherently laggy technique to save memory?
This is my pet project, a desktop app for working with xAI models & capabilities, so by "performance" I mostly mean "pleasant to use" (as it goes, simple & opinionated). Technically speaking, something like: stable FPS, no visible lags, and the ability to scroll smoothly while the model is streaming.
Regarding the parent comment: yes, memory is important, and I absolutely get the point. There should be a red line, for sure. But I will not sacrifice UX, productivity, and simple pleasure from using software just to save a few hundred megabytes of RAM (or even a few gigabytes) especially for an app I spend hours with behind the screen.
Memory consumption can & should be optimised with proper engineering for sure. As lags & inadequate performance in basic SDK-level primitives are much harder (impossible?) to fix from the outside.
What's the point of having 64-128GB of RAM if we're using apps that eat 10GB to do the same things we were doing 20 years ago using a few MB?
a fast performant incomplete solution will lose to a slow correct complete one
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 rendering on multiple places scattered over the native UI. Or if the native UI should interact with the HTML somehow (drop-downs, edit text, add native controls inside html).
Thats why everyone is building Electron/etc apps.
Citing other answer here "This is a common misconception among programmers, and is actually the opposite of the truth."
If platform is Windows then you need three different mechanisms for doing so, depends on OS version. And be ready to the fact that it can be no browser installed in standard way.
And if platform is Linux... Good luck with that in general... GTK may help here but be ready to GTK2/GTK3/GTK4 zoo. And sure you will not be happy with performance of the result.
Like the OP mentioned, it's still surprisingly difficult to build what feels like a trivial interface using SwiftUI. Once you get into rich text, selection, streaming updates, syntax highlighting, diffing, or just smooth scrolling, you very quickly end up fighting the framework instead of building the app
Not that I'd use either when I can just make a Web based UI most of the time and be done with it.
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).
You can do a couple days to a week of reading to understand the fundamentals once and then you will actually know what you are doing.
It is not proper to choose things on “battle tested” or other meaningless words
It’s easy to hand wave and say “this wouldn’t be an issue if you knew what you were doing”, but that indeed is the problem.
I was changing between them and searching for comparisons online. This ended up being a massive amount of lost time because all of those choices became crystal clear when I actually roughly understood what these libraries were doing.
And actually learning the thing didn’t take as much time as writing code for comparison and discarding it or doing dead-end web searches.
Recently had a similar experience trying to learn dwarf parsing from LLMs or searching for existing code. Then I just realised that reading the spec is by far the most efficient way to understand it.
I am guessing same principle applies to text rendering because I got the same vibe when watching Raph Levien talk about it on some video.
Searching online to read some “industry-standard” “tried and true” etc. Comments is a big sign that it might be better read some actual source about the topic imo. It doesn’t even take that much time to read a textbook even.
And yes WPF is a framework native to the Windows platform ecosystem.
And your users hate you and look for alternatives.
Fancy text rendering/editing is hard to implement when you leave the luxury of webviews.
I think this may be a misundertstanding of what SwiftUI is. SwiftUI makes it convenient to create apps that look and behave in a way that align with Apple's HIG using controls like `List`, `Form`, etc., but nothing makes you use any of those. For example, it's straightfoward to build a game engine on SwiftUI. https://blog.jacobstechtavern.com/p/swiftui-game-engine
Where is the profile? Where is the bottleneck?
Just complaining with nothing to contribute.
the browser never chokes on html.
The browser is faster because they went native, in particular, GPU.
Every issue described is text rendering related. Everyone.
And I would bet most of the SwiftUI issues could be solved with a text render cache.
Something like Casey Murati's refterm toy that showed what that can do with no other optimizations, or the work for GPU accelerated terminal emulators like alacritty or ghostty.
it’s disappointing to find out things have not improved with SwiftUI