alt.hn

5/17/2026 at 11:49:46 AM

Native all the way, until you need text

 https://justsitandgrin.im/posts/native-all-the-way-until-you-need-text/

by dive

5/17/2026 at 2:42:46 PM

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

https://www.gingerbeardman.com/apps/papertrail/

by msephton

5/17/2026 at 6:37:07 PM

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

by dive

5/17/2026 at 8:37:19 PM

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

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

by mananaysiempre

5/17/2026 at 9:02:34 PM

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.

by msephton

5/18/2026 at 12:41:58 AM

Nothing comes for free, but OP’s entire point is that the price to pay for even halfway decent native markdown rendering is too high - and thus a reason why people often give up and go to Electron.

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.

by Klonoar

5/17/2026 at 8:52:13 PM

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.

by bensyverson

5/17/2026 at 9:06:06 PM

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

by msephton

5/17/2026 at 11:01:53 PM

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

by dataflow

5/17/2026 at 11:11:53 PM

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.

by msephton

5/18/2026 at 3:38:38 AM

I definitely need to edit files that are hundreds of thousands of lines once in a while. Nothing wrong with it, I think you're just assuming it's source code or such when it isn't. It's often data manipulation (CSV, JSON, etc.) and it feels like torture when the editor can't handle it. I've even opened multi-gigabyte text files in my editor and needed to edit them sometimes.

by dataflow

5/18/2026 at 3:46:53 AM

That's cool, understood. Whilst I don't think you would be using my app to edit those files, it could do it. Though I haven't tested the multi gigabyte size on iOS.

by msephton

5/17/2026 at 2:51:31 PM

Having worked on an interactive novel in 2012 (NSString and attributes), low level glyphs (API deprecated) on a rogue-like, two chat apps (with markdown support for formatting) in SwiftUI, and an idle game using a mix of iOS tricks but all wrapped in SwiftUI.. I’m going to agree with how I summarized this response: skill issue.

by sandoze

5/17/2026 at 4:13:21 PM

[flagged]

by itsthecourier

5/17/2026 at 9:27:22 PM

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.

by hombre_fatal

5/17/2026 at 5:36:58 PM

It's likely the SwiftUI Mac implementation is subpar. SwiftUI-on-Catalyst might be a better choice for these applications, but it probably has other problems.

by KerrAvon

5/17/2026 at 4:58:33 PM

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

by virgil_disgr4ce

5/17/2026 at 11:15:01 PM

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

by msephton

5/17/2026 at 3:02:17 PM

[flagged]

by satvikpendem

5/17/2026 at 12:59:57 PM

Usually performance was the reason for using native APIs rather than web views, but this doesn't seem to be true any more.

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.

by pornel

5/17/2026 at 1:48:04 PM

It's SwiftUI that is at fault here[1][2], not native apps in general. I wrote my native app in Qt C++ and QML and showed that it is *significantly* faster and uses significantly less RAM than similar web apps[3]. So, no, web apps, in general, are slower and uses more resources than well-engineered native apps.

[1] https://notes.alinpanaitiu.com/SwiftUI%20is%20convenient,%20...

[2] https://x.com/daniel_nguyenx/status/1734495508746702936

[3] https://rubymamistvalove.com/block-editor#8-performance

by rubymamis

5/17/2026 at 2:18:28 PM

> It's SwiftUI that is at fault here, not native apps in general.

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.

by CharlesW

5/17/2026 at 9:44:20 PM

> Claims like "It's hard to build a performant SwiftUI app" get into skill-issue territory

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.

by vor_

5/17/2026 at 10:34:58 PM

All I have is my own experience. In my current app, my views are 100% SwiftUI. One of them uses a SwiftUI List which typically has hundreds of thousands of items, each with title, subtitle, duration, cover art, etc. I expect it would still be butter-smooth at 1M items.

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.

by CharlesW

5/18/2026 at 3:52:20 AM

If you've used UIKit to any large degree, how bad SwiftUI is, almost a decade later, continuously punches you in the face. About 20% more time to write initially, for 90% less bugs and potholes, and I've tested this with iOS devs who never used UIKit before too. Now with AI, there is even less of an excuse IMO.

Leave SwiftUI to the settings pages. The gulf between AppKit and SwiftUI in macos desktop I'm not as sure about.

by novok

5/17/2026 at 3:59:11 PM

iOS 26 is very late to have acceptable performance in the framework that Apple promotes as what you should use. It should have had good performance from the day it was introduced.

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.

by silvestrov

5/17/2026 at 5:39:26 PM

Can you point to a single performant, high-quality SwiftUI-first app with a messages-like chronological transcript and correct scrolling behavior on macOS? The problems with AppKit integration are real and should not be dismissed out of hand.

by KerrAvon

5/17/2026 at 1:57:28 PM

Qt is the opposite of native. It's just reimplementing the look and feel of a native app, but the seams are extremely visible.

by StilesCrisis

5/17/2026 at 2:19:58 PM

They even used the distinction “native-like” in the block editor article - which is really good, by the way and explains this distinction in more depth - but edited their comment now and that article is the third link and its anchored to the performance section so you won’t see that unless you scroll to the top.

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.

by jeremyjh

5/17/2026 at 3:13:17 PM

At this point on Win32 Qt might as well be the native UI. They did a better job of maintaining a coherent visual theme that says "Windows" and fits the design patterns than the actual owners of the platform.

by tux3

5/17/2026 at 6:27:49 PM

I disagree. I use P4V (Qt-based) regularly. Its lists are quirky and sometimes don't scale property with the OS DPI settings.

by StilesCrisis

5/17/2026 at 8:50:19 PM

I'd be more curious about that specific app. Niche bespoke commercial apps have this habit of being permanently stuck on old versions of Qt that don't handle these things as well as the newer versions. And until they are totally broken on Windows, the developers will never be motivated to lift a finger to fix this.

I have no idea if this is the case with P4V, but it absolutely is the case with a few other things I use.

by octorian

5/18/2026 at 2:04:46 AM

Okay, too late to edit, but I decided to take a look. The latest version of P4V actually is using Qt6, so I guess I have to stand somewhat corrected.

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.

by octorian

5/17/2026 at 3:26:42 PM

Unless you're on KDE where it's literally native?

by singpolyma3

5/17/2026 at 10:18:45 PM

Not unless you use their theme system and components from my understanding.

by Bolwin

5/17/2026 at 1:34:11 PM

> Browser rendering engines are pretty mature at this point, with significant GPU acceleration, and over a decade stress-testing by bloated web apps.

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.

by embedding-shape

5/17/2026 at 5:30:58 PM

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.

by trinix912

5/17/2026 at 7:43:58 PM

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.

by whstl

5/17/2026 at 9:30:56 PM

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.

by domga

5/17/2026 at 7:57:07 PM

Electron would be fine… if most of us were running just one electron app.

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.

by cosmic_cheese

5/17/2026 at 2:04:14 PM

> Browser rendering engines are pretty mature at this point, with significant GPU acceleration, and over a decade stress-testing by bloated web apps.

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.

by titzer

5/17/2026 at 2:54:01 PM

Web tech in general is responsible for a lot of unnecessary hardware turnover.

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.

by cosmic_cheese

5/17/2026 at 3:55:58 PM

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

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.

by Narishma

5/17/2026 at 9:40:50 PM

I was of this conviction as well. However, since I installed CachyOS on my old desktop (6800k+32gib DDR4, SSDs) I have comparison material with my AMD 5900X and the difference is night and day.

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.

by spockz

5/17/2026 at 10:47:21 PM

Of course there’s a speed difference, but boot times are only occasionally dealt with and only the tiny handful of people capable of developing software will ever need to compile anything.

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.

by cosmic_cheese

5/17/2026 at 5:20:43 PM

Agreed. I have a shitty laptop I bought at Micro Center a couple years ago for like $80. I bought it mostly out of curiosity since I wanted to see what an $80 laptop would be capable of.

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.

by tombert

5/17/2026 at 5:30:14 PM

> Chromebooks

Have you tried with stock ChromeOS?

by nolist_policy

5/17/2026 at 1:51:57 PM

Well, maybe for simple web apps, but for complex applications there is a noticeable slowdown, I am not even talking about monsters such as jira, but well optimized apps such as vs code, there is a performance ceiling which is lower than for native apps.

by iTokio

5/17/2026 at 2:55:59 PM

For Jira I think the limitation is buried all the backend execution and rendering. It's still fast if you go only by the frontend user-executed part.

by sznio

5/17/2026 at 1:58:45 PM

According to the article, native is slower though.

by StilesCrisis

5/17/2026 at 2:11:21 PM

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.

by CharlesW

5/17/2026 at 3:08:44 PM

Electron sits on native rendering primitives. Do you suggest that every developer who wants rich interactive text in their app should write a text rendering engine from the ground up?

by ryeights

5/17/2026 at 3:05:38 PM

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

by bonesss

5/17/2026 at 3:32:46 PM

> If you account for dev time, ‘giving up’ and just doing it in a web renderer is totally valid.

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.

by CharlesW

5/17/2026 at 3:46:25 PM

Agreed, but no such conclusion or framing was stated, supported, or suggested in my comment.

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.

by bonesss

5/17/2026 at 3:55:21 PM

I added the word "article" before the word "framing" to make it clearer in my comment supporting your comment that the last half of my comment wasn't commenting on your comment.

by CharlesW

5/17/2026 at 11:02:17 PM

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.

by bigstrat2003

5/17/2026 at 6:20:58 PM

Electron sits on top of Skia, which renders the text itself. It's designed to look like the host OS but it's not just asking the OS to draw text, because that's actually a lot slower than Skia.

by StilesCrisis

5/17/2026 at 4:16:09 PM

[dead]

by pornel

5/17/2026 at 5:24:03 PM

WebView is "native" too in the end.

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?

by raincole

5/17/2026 at 1:54:28 PM

SwiftUI, (but not specifically "SwiftUI", more of paradigm) is not the right tool to incremental changes of large portion of data, and SwiftUI specifically is very bad at it and offer no good API to make incremental changes more optimal. That's one of the reason behind why Apple to this day did not ship usable SwiftUI text view component.

by krzyzanowskim

5/17/2026 at 2:03:11 PM

They did last year. I can understand why you're confused, since it came in the form of the radically-improved `TextEditor`. https://wwdcnotes.com/documentation/wwdcnotes/wwdc25-280-cod...

by CharlesW

5/17/2026 at 3:54:53 PM

I don't know where's the improvements, give it has all the limitations, now scaled to rich text. That's not the direction that this component should get. It need radical new API that is not much compatible with SwiftUI API

by krzyzanowskim

5/17/2026 at 4:10:25 PM

You must know far more about this than me, but as of iOS 26, `TextEditor` evolved into a true rich text editor (`AttributedString` binding, `AttributedTextSelection` rich text selection, custom/app-specific text attributes, etc). https://developer.apple.com/videos/play/wwdc2025/280/ Do you really think people should use web views instead of, say, STTextView?

by CharlesW

5/17/2026 at 6:14:24 PM

I think people should use anything but SwiftUI.TextEditor is my current stance

by krzyzanowskim

5/17/2026 at 1:57:16 PM

System Preferences also sometimes just render a WebView - most notably in the Apple Account settings

by tom1337

5/17/2026 at 3:37:48 PM

Oh that hackjob explains some of the inconsistent, frustrating 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)

by Barbing

5/17/2026 at 3:16:21 PM

I assume because there’s no good “render a view hierarchy based on layout delivered from a server” option. Whereas this is what HTML is with caveats.

by nielsbot

5/17/2026 at 1:38:54 PM

Now RAM use is the main reason to prefer native APIs over web views.

by Dwedit

5/17/2026 at 5:16:43 PM

I am not sure WebViews are the actual problem, and fairly confident it is running the entire application + gargantuan frameworks as JavaScript is.

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.

by mpweiher

5/17/2026 at 9:37:08 PM

The issue with JS is that each page gets its own execution context so they don’t share any memory. I am actually curious what does the WebView do to save on RAM here?

by domga

5/17/2026 at 2:40:24 PM

A decision to move native because of the crisis seems like an expensive populist move to please not very solvent users. Why bother with that if many predict the RAM crisis will last merely until 2027?

by enbugger

5/17/2026 at 3:16:52 PM

If you can predict the future so accurately, why aren't you the richest man on the planet?

by LtWorf

5/17/2026 at 5:31:15 PM

Because predicting the future roughly as well as everyone else doesn't make you rich.

Predicting a surge in RAM supply after a surge in RAM demand and a huge increase in RAM margins is economics 101.

by fauigerzigerk

5/17/2026 at 7:21:24 PM

We are still bound by natural resources, as much as economics 101 loves to ignore this simple fact.

by LtWorf

5/17/2026 at 8:46:45 PM

Supply of RAM isn't really limited by natural resources - silicon is literally one of the most abundant materials on the planet. It's limited by the construction of billion dollar factories.

by tardedmeme

5/17/2026 at 7:54:17 PM

Scarcity of natural resources is squarely within the realm of 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.

by fauigerzigerk

5/17/2026 at 3:55:46 PM

I can't. But I'm sure I will be happier and richer person if I don't opt out self from a working stack in favor of saving 100-200mb RAM

by enbugger

5/17/2026 at 4:09:48 PM

You're off by an order of magnitude there.

by LtWorf

5/17/2026 at 5:45:52 PM

super happier and super richer?

by mh-

5/18/2026 at 3:36:32 AM

And yet if I open Activity Monitor right now: "Emoji & Symbols" is using 1GB of memory, "Spotlight" using 749MB, "Control Center" using 727MB, despite not having used any of the features recently (and additionally restricting Spotlight to index basically nothing or else it'll drain my battery). Each one of those is larger than any of the Electron apps I always have running (Claude, Cursor, Signal, 1Password).

by ladberg

5/17/2026 at 1:38:47 PM

> Meanwhile SwiftUI doesn't feel particularly fast.

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.

by latexr

5/17/2026 at 5:25:34 PM

> Usually performance was the reason for using native APIs rather than web views, but this doesn't seem to be true any more.

It's still true. There's no way around it, web views will always be slower.

by hackermanai

5/17/2026 at 2:11:41 PM

This is the ActiveX/nacl/wasm/etc... argument recapitulated. For decades, people dithered about how to get fast code into browser environments such that it could be deployed safely.

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.

by ajross

5/17/2026 at 2:44:14 PM

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.

by mpweiher

5/17/2026 at 9:40:18 PM

The problem with Electron is not that people choose it over native tech like WPF or SwiftUI, they choose it over nothing. Without Electron tons of cross platform apps simply wouldn’t exist.

I think macOS suffers the most since it is not that hard to port an iOS app to Mac, and Linux benefits the most.

by domga

5/17/2026 at 10:22:05 PM

The author said the mean reason for the speedup was parallelization, not Go being particularly faster. The JS JIT is very good. In most benchmarks I've seen its not much slower than Go.

by Bolwin

5/17/2026 at 3:17:12 PM

I am going to miss being able to host TypeScript in a web view however.

by nielsbot

5/17/2026 at 8:47:43 PM

You still can. If you port the compiler to something that runs in a web view. WASM sounds easiest.

by tardedmeme

5/17/2026 at 3:17:34 PM

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

by ajross

5/17/2026 at 3:40:27 PM

> that's the typescript compiler, not typescript apps.

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.

by mpweiher

5/17/2026 at 4:17:57 PM

Again, meh. I'm just happy you've admitted that the idea that Go is 10x faster than V8 is bunk. Use what you like. But like I said everyone else is using Electron and winning. I don't make the rules, I'm just trying to explain them.

by ajross

5/17/2026 at 5:13:24 PM

> you've admitted that the idea that Go is 10x faster than V8 is bunk.

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

by mpweiher

5/17/2026 at 5:36:14 PM

The typescript compiler is a typescript app. Or was, I guess

by 3836293648

5/17/2026 at 11:04:48 PM

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.

by bigstrat2003

5/18/2026 at 12:04:11 AM

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

by ajross

5/17/2026 at 12:48:21 PM

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.

by Wowfunhappy

5/17/2026 at 2:31:54 PM

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.

by InsideOutSanta

5/17/2026 at 5:41:58 PM

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.

by kenferry

5/17/2026 at 11:06:12 PM

..where did you get that impression?

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

by Bolwin

5/18/2026 at 1:35:42 AM

Markdown can contain arbitrary HTML. It only makes sense to use an HTML viewer for what is essentially a dialect of HTML, aka a browser engine.

by array_key_first

5/17/2026 at 8:48:15 PM

[dead]

by andix

5/17/2026 at 1:57:22 PM

> Using WebKit to render Markdown seems completely appropriate.

It doesn't? Needs an explanation.

by the_gipsy

5/17/2026 at 2:05:21 PM

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

by throawayonthe

5/17/2026 at 3:02:36 PM

Still seems overkill. It's just headers, lists, block quotes, codeblocks, and a few inner emphasis and link formatters, basically. HTML is the whole jungle for a gorilla with a few bananas here.

by the_gipsy

5/17/2026 at 6:07:35 PM

> It's just headers, lists, block quotes, codeblocks, and a few inner emphasis and link formatters, basically

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.

by Someone

5/17/2026 at 5:41:20 PM

It's still going to be faster than creating and moving around a bunch of NSViews simply because the WebView (native WebView, not Electron) renders the entire content at once, directly on the graphics pipeline, skipping all layout and compositor steps that get done on normal NS(Text)Views.

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.

by trinix912

5/17/2026 at 2:30:12 PM

More importantly all HTML is valid markdown.

by TingPing

5/17/2026 at 9:32:51 PM

Also, there is no such thing as valid markdown.

by the_gipsy

5/17/2026 at 3:03:03 PM

Putting HTML in markdown defeats the purpose IMHO.

by the_gipsy

5/17/2026 at 4:50:09 PM

I don't think it does at all!

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

by Wowfunhappy

5/18/2026 at 4:37:34 AM

> without looking like it’s been marked up with tags or formatting instructions.

From your own quote. Embedding html absolutely violates the spirit.

by what

5/17/2026 at 4:44:55 PM

That doesn't make it not true though. Markdown generally supports HTML (though oftentimes only a subset), and is typically styled using CSS. Using a web view makes complete sense to me.

by nchie

5/17/2026 at 3:39:01 PM

That doesn’t track at all. Markdown was created as a simpler way to mark up text than HTML. They are both ways of encoding a document that provide ways to convey intention. HTML is no one’s end goal.

by tclancy

5/18/2026 at 5:03:05 AM

First sentence of the announcement / introduction of markdown:

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

by masklinn

5/17/2026 at 1:00:03 PM

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

by stavros

5/17/2026 at 2:33:05 PM

a bit of a roundabout way to answer this, but i think most native devs are okay with a self contained app element using webkit, that is what it is there for and generally stuff like rendering html, markdown, a one off static page, it is just a view from UI perspective. When things get more interactive, have a navigation hierarchy, animations etc are when things start to diverge from native feel and performance and you have gone too far.

by mrbombastic

5/17/2026 at 8:50:37 PM

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.

by tardedmeme

5/17/2026 at 9:28:16 PM

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.

by stavros

5/17/2026 at 1:23:41 PM

> But why would you expect to use WebKit to render rich text?

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.

by p-e-w

5/17/2026 at 1:20:19 PM

I mean, this is why I think PDFKit is a good comparison. Could you render your app's entire UI as a series of PDFs? Absolutely! Should you do that? Uh, probably not. You should use the native controls Apple gives you for buttons and dialogs and input fields and so on.

But WebKit is the native UI for HTML, and Markdown is intended to be transpiled to HTML.

by Wowfunhappy

5/17/2026 at 1:23:42 PM

It's irrelevant what Markdown was meant to be transpiled to. When people say "Markdown support" these days, they mean "rich text support", since Markdown is actually just ASCII. It is ridiculous to need a Web renderer to render rich text, on any platform. Even terminal emulators can do it.

by stavros

5/17/2026 at 1:27:56 PM

HTML is basically analogous to RTF, no?

by Wowfunhappy

5/17/2026 at 7:00:12 PM

maybe html 0.9 :)

by nottorp

5/17/2026 at 2:10:16 PM

If think that the MacOS GUI is actually entirely rendered as a series of PDFs, if I have understood things correctly.

by carlosjobim

5/17/2026 at 2:20:13 PM

That’s how it originally worked, but Apple has moved away from PDF to other native GPU frameworks for drawing. Now window content is stored as bitmaps instead of redrawing vector instructions.

by jonhohle

5/17/2026 at 3:46:00 PM

That's not how it ever worked.

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.

by mpweiher

5/17/2026 at 4:48:23 PM

You’re correct. I meant to say textures, but even that isn’t completely accurate.

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.

by jonhohle

5/17/2026 at 3:43:57 PM

You have understood things incorrectly.

by mpweiher

5/17/2026 at 1:12:59 PM

> what isn't appropriate for it?

It'd be very silly to render a shader pipeline in WebKit. You could, but with Metal sitting right there, it would be silly.

by joenot443

5/17/2026 at 1:16:24 PM

If we're all agreeing that all the native elements are useless, I can see how the question is "do I use Metal or do I use WebKit", but my question wasn't about WebKit vs metal, it was WebKit vs native elements.

by stavros

5/17/2026 at 1:02:53 PM

Yeah, this is actually my current in-progress solution: render the final Markdown & the streaming through WebKit.

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

by dive

5/17/2026 at 1:56:00 PM

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

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.

by Wowfunhappy

5/17/2026 at 2:27:10 PM

I am with you here.

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.

by dive

5/17/2026 at 1:50:44 PM

OP thinks "native" = only using Swift/ObjC primitives

WebKit is cheating I guess? Because it exists on other platforms?

Might as well use Java

by tantalor

5/17/2026 at 3:12:59 PM

So I can build my entire app in a WebKit wrapper and call it native? I think ‘native’ in this context is well-understood to mean eschewing web or cross-platform renderers

by ryeights

5/17/2026 at 1:03:01 PM

> But I still cannot make a simple thing work properly: a chat with Markdown & the ability to select a whole message.

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.

by lenkite

5/17/2026 at 1:27:17 PM

I tried Textual earlier today with some not-so-good results:

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

by dive

5/18/2026 at 2:12:36 AM

yeah /you/ should stick to electron

by rtgfhyuj

5/17/2026 at 1:09:55 PM

Can those handle streaming in new text without flickering?

by simonw

5/17/2026 at 1:27:03 PM

The first one is the Claude iOS app uses and it seems to perform okay and has the ability to select text and stream stuff.

by SoKamil

5/17/2026 at 5:32:56 PM

Either you render the markdown document just once (not streaming) or your document is simple and short.

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.

by longnguyen

5/17/2026 at 7:36:26 PM

> > But I still cannot make a simple thing work properly: a chat with Markdown & the ability to select a whole message.

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

by gwbas1c

5/17/2026 at 12:38:40 PM

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.

by rTX5CMRXIfFG

5/17/2026 at 12:59:48 PM

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

by replygirl

5/17/2026 at 1:19:23 PM

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

by jeroenhd

5/17/2026 at 5:48:27 PM

I build an AI chat app for a living (20k+ customers) and I can tell you, everyone has been asking for that.

by longnguyen

5/17/2026 at 11:23:37 PM

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

by Bolwin

5/17/2026 at 1:41:31 PM

sounds out of scope for an llm chat ui

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.

by Klonoar

5/17/2026 at 2:02:35 PM

Slack also basically fails at this. You end up getting a jumble of timestamps, names and messages.

by StilesCrisis

5/17/2026 at 2:07:49 PM

Yeah... people expect that when they copy chat messages. It's correct behavior.

by Klonoar

5/17/2026 at 6:24:13 PM

I don't mind the timestamps and names existing, but they're formatted all wrong.

by StilesCrisis

5/17/2026 at 12:46:51 PM

Without web view ? Share the code ?

by rafaelmn

5/17/2026 at 3:35:09 PM

Fun fact: This is how Apple used to do it too.

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.

by iamcalledrob

5/17/2026 at 5:46:16 PM

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.

by kenferry

5/18/2026 at 12:48:43 AM

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

by Klonoar

5/17/2026 at 3:46:21 PM

...although the logic in the article is slightly odd:

  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??
Personally, I would have stopped at (3).

by iamcalledrob

5/17/2026 at 12:39:21 PM

I remember being a junior engineer in 2015, and being asked to render a clickable link within a paragraph in an iOS app. Swift had just been released so we were still entirely on the ObjC/UIKit stack. It was an absolute nightmare. I _barely_ managed to make it work. I haven't really touched iOS since about 2016, so I assumed the new SwiftUI stuff would have this stuff built in. Obviously. Kind of insane that it wasn't.

by danielvaughn

5/17/2026 at 1:14:31 PM

It's quite literally called Link

https://developer.apple.com/documentation/swiftui/link

I'm not sure how much easier they can make it at this point.

by joenot443

5/17/2026 at 1:29:25 PM

When I say "this stuff" I'm not talking about a link, I'm talking about the overall markdown/text capabilities that the post is talking about. I meant that I expected more parity with what you'd encounter on the web.

by danielvaughn

5/17/2026 at 1:58:01 PM

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

by PaulDavisThe1st

5/17/2026 at 4:52:35 PM

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.

by danielvaughn

5/17/2026 at 12:49:42 PM

Qt made this pretty easy 10 years ago

by nly

5/17/2026 at 7:46:40 PM

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

by LtWorf

5/17/2026 at 11:43:56 PM

Both Qt and Electron are LGPL.

by ethanc8

5/18/2026 at 5:23:16 AM

From their website:

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

by LtWorf

5/17/2026 at 12:51:47 PM

NSLinkAttributeName?

by sirwhinesalot

5/17/2026 at 1:04:07 PM

My thought exactly. However, Apple’s developer documentation has never been particularly helpful, so I don’t blame very much for missing that.

by Y-bar

5/17/2026 at 12:51:32 PM

I thought attributed text handled this fine since forever. Did it not?

by jagged-chisel

5/17/2026 at 2:08:13 PM

I vaguely remember doing this with attributed text for iOS 4.

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.

by ben_w

5/17/2026 at 3:22:45 PM

>being asked to render a clickable link within a paragraph in an iOS app

The specific ask was already a bad idea.

by coldtea

5/17/2026 at 4:53:26 PM

the whole company was a shitshow; that was probably the least insane thing i was asked to do there.

by danielvaughn

5/17/2026 at 12:53:22 PM

> how immature all these “native” things still are when you step outside simple screens

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.

by skeledrew

5/17/2026 at 1:02:42 PM

Sure, but those the native UI dev kits are commercial products, right? Isn’t it their job to sell them to people — not people’s job to sell themselves on it? Part of the reason web stuff is so much more mature is the unwillingness of the big commercial OS manufacturers to keep up with the times. Windows UI kits are a hot fucking mess.

by DrewADesign

5/17/2026 at 2:14:35 PM

Agreed. He's basically complaining and moaning about Markdown not being fast to work with in Swift, when nobody has really put a lot of effort into that yet. yet despite this, he's not willing to contribute to that himself.

by sgt

5/17/2026 at 2:38:52 PM

Sounds like it would be Apple's job to develop their own platform.

I think SwiftUI etc al don't work on Linux and Windoes and Android, right? While HTML works?

by stephbook

5/17/2026 at 3:38:12 PM

Give them a break. Why doesn't the OP just help develop a highly efficient SwiftUI extension for Markdown if it's that important? Remember that there are many efficient MD libraries for Swift/ObjC which would in any case be the sensible approach here (and it also explains why he can't find a SwiftUI alternative to his liking).

by sgt

5/17/2026 at 1:13:48 PM

[dead]

by alcazar

5/17/2026 at 12:38:20 PM

I've had pretty much the same experience with my AI chat app. Nothing works well. Markdown rendering is slow and laggy, streaming is slow and laggy, everything locks up the UI. I've tried at least 5 of the most popular text editor components for UIKit and SwiftUI on GitHub, and all were broken in one way or another, buggy, and slow as well. It's ridiculous.

by splittydev

5/17/2026 at 1:28:19 PM

Yep, this is a difficult problem. I wrote extensively how I managed to solve this by creating my block editor from scratch using Qt C++ and QML[1]. I faced similar issues - selection between discrete blocks, showing the underlying Markdown under the cursor, varying delegate sizes, etc.

I'm using what I learned to create a native LLM client with a streaming Markdown parser[2].

[1] https://rubymamistvalove.com/block-editor

[2] https://www.get-vox.com

by rubymamis

5/17/2026 at 12:49:46 PM

If you need to display HTML content (what Markdown usually translates to) then WKWebView is the control to use! Or use something like litehtml which should be more than enough for Markdown unless you want to support "Animated Gifs" (that are actually H.264 movies these days) or whatever else.

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?

by sirwhinesalot

5/17/2026 at 12:40:40 PM

I don’t recall ever struggling with NSTextView. I never really got into Swift, but I’ve never found Cocoa / Objective C to have any of the problems the author mentioned.

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 ryandrake

5/17/2026 at 12:57:02 PM

`NSTextView` is good. My point is not that `NSTextView` itself is bad. The problem is that once you are working with all the "modern" Apple stack (Swift, SwiftUI, and the direction Apple is clearly pushing developers towards) `NSTextView` does not fit as naturally anymore. Some newer APIs are not even available for AppKit now, so you quickly end up in an awkward middle ground.

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.

by dive

5/17/2026 at 11:56:58 AM

Yep. Electron is the worst way to make a desktop app… except for all the others!

by PaulHoule

5/18/2026 at 1:38:07 AM

I've been working on a MarkdownView library for iOS based on tree sitter: https://github.com/HumanInterfaceDesign/MarkdownView

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

by instagary

5/17/2026 at 7:04:39 PM

> There is no real alternative.

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.

by c-smile

5/17/2026 at 12:28:33 PM

I just wish there was a native Markdown renderer / editor library in C that I can use cross-platform - in the style of something like IMGUI (where the library outputs a list of primitives for you to render yourself in any graphics API).

Or well... since we now have Claude I might have a jab at this someday in my free time.

by cyber_kinetist

5/17/2026 at 12:41:49 PM

For just rendering (no editing) you could use https://github.com/litehtml/litehtml (C) or https://github.com/DioxusLabs/blitz (Rust).

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.

by nicoburns

5/17/2026 at 1:34:54 PM

The link says litehtml is C++. I can't tell if it exposes an FFI (I bet not)

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.

by bobajeff

5/17/2026 at 12:49:19 PM

Does it mix well with text input? What I really want is a native WYSIWYG Markdown editor - in a similar fashion to Typora (Electron) or Milkdown (a JS library).

by cyber_kinetist

5/17/2026 at 12:58:16 PM

Blitz has good plaintext text input support. But there's no contenteditable (which is what you would need for rich text editing) yet.

litehtml appears to have no built-in text input support so far as I can see.

by nicoburns

5/17/2026 at 7:19:17 PM

I’ve been there too. Finally opted for Flutter (need cross-platform mobile and desktop). Apple needs to put a big effort into the development tools, or they will face the actual Windows situation: several GUI toolkits, none of them as mature as the ones they are designed to replace. (Try to beat Windows Forms Professional Control Libraries and the boost in development performance you get. You can’t because the tool makers need a clear path and commitment in order to justify developing a new version of the full control libraries. You need cross-platform; forget the native tools. That’s the same scenario Apple is facing right now.)

by freequest

5/17/2026 at 3:23:53 PM

One of the reasons I decided to stay in the shadows as an unglamorous, boring backend developer. Every single time I tried any frontend development, either web or mobile, the moment I started running into issues like this requiring witchcraft to accomplish an objectively trivial task, a bit of my soul left my body.

by tedggh

5/17/2026 at 5:21:03 PM

A thing I’ve always wanted was a visual JSON viewer that instantly opened on multi-hundred-meg files. So I used Claude Code to build one with native text views and it’s true it’s pretty raw. But for a thing that doesn’t need formatting, dictionary, and all that it’s great. The viewer opens fast enough that it’s dominated by the window rendering animation which is about what I wanted here.

So I think the text view is pretty low level so that it can support this.

by arjie

5/18/2026 at 3:24:04 AM

Thanks for this post. This will be my bible for the "electron bad" crowd

by knlam

5/17/2026 at 8:45:20 PM

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

by andix

5/18/2026 at 2:40:29 AM

> On most platforms it's quite easy to embed a browser in a frame

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.

by c-smile

5/17/2026 at 2:20:48 PM

Maybe controversial but I think HTML + CSS is truly the most powerful system to make GUIs.

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

by pier25

5/17/2026 at 3:53:30 PM

In a way it really is, in part because HTML + CSS is the back door "universal native GUI framework" that various projects have been chasing for years. Because browsers and GUI elements in them are so important to modern computer use, every OS vendor has a vested interest in ensuring the default look and behavior of elements in their browsers are native (or as native as possible). As a result, if you can render your UI in a browser (or in a browser frame/view) chances are you can get a native looking and native feeling UI for your application with a well understood and robust piece of technology that will retain that look and feel even as the underlying OS changes around it.

by tpmoney

5/17/2026 at 2:26:47 PM

Powerful, perhaps. Slow, for sure.

by antiframe

5/17/2026 at 3:57:42 PM

I don’t know. Resizing a window with complex ui in html tends to be faster than native guis for me. It haven’t tested this properly though.

by pier25

5/17/2026 at 2:43:30 PM

I just use a fullscreen <canvas> and WebGPU. It's performant as hell.

Skill issue, I guess. /s

by stephbook

5/17/2026 at 7:10:18 PM

Performance is relative. Every electron app I have used has been slower than their equivalent native app.

by antiframe

5/17/2026 at 1:39:36 PM

I know nothing about any of these APIs, but the claim of the article seems weird. If naitive APIs are insufficient, or slow, or unsuitable, and implementing your own is too hard, then how does Electron even do what it does? One would assume that Electron has its own library to accomplish the task, in which case this code could either be separated, or re-created once and for all, into its own re-usable library.

by teddyh

5/17/2026 at 7:09:30 PM

You can just implement Prosemirror from one of the greatest web teams on the planet and get pretty much every text editing nicety for free - markdown rendering, document version history, blocks, tables. If you choose to deal with prosemirror-collab-cmmit, yjs, or automerge you also get eventually consistent multiplayer. All the "I wish this was a native app" people don't understand the cathedrals that have been built on the web.

by L_Rahman

5/17/2026 at 3:14:40 PM

Chromium has had an insane amount of investment from many large companies. Way more than native UI frameworks have had over the last decade or so.

by fassssst

5/17/2026 at 1:58:44 PM

> I know nothing about any of these APIs

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

by jeremyjh

5/17/2026 at 1:53:40 PM

Electron is just a thin shell around Chromium

by tantalor

5/17/2026 at 1:39:08 PM

"skills issue" but also "native" frameworks are lacking polished API. On macOS TextKit2 is unfortunately kinda broken, how do I know? I reimplemented TextView with it https://blog.krzyzanowskim.com/2025/08/14/textkit-2-the-prom...

by krzyzanowskim

5/17/2026 at 1:49:34 PM

Hey Marcin,

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.

by dive

5/17/2026 at 1:58:17 PM

totally. the there's a lot complexity that adds up to the overall performance issues. and TextKit 2 IS pretty bad at things. especially public API is pretty bad - that result in my case need to workaround things that I should've not. I agree with the general sentiment et all. I also still believe there is a place without bringing the whole browser machine to render text, and have text under control - but without relying on the "TextKit" level. That's the next thing I'm researching right now.

by krzyzanowskim

5/17/2026 at 1:01:14 PM

Why not use native for UI frame (menu, toolbar, conversation list etc) and WebKit for the actual chat? I think that would combine the best of both worlds.

by d12bb

5/17/2026 at 5:41:19 PM

Yep. That is what I did for my AI chat app and it’s indeed the best of both worlds.

by longnguyen

5/17/2026 at 1:49:51 PM

I am currently experimenting with linux based GUIs. It was always something that felt clunky to me, but now with more insights, it's clunky for a reason. If you need more then a framebuffer, then rendering something sophisticated to the screen is insanely complex. Somehow it's easy to expect that rendering text on a screen should be easy, but when you go down the layers you find yourself with a club and a flint stone trying to build a castle with it.

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.

by Yokohiii

5/17/2026 at 1:54:52 PM

> Somehow it's easy to expect that rendering text on a screen should be easy

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.

by PaulDavisThe1st

5/17/2026 at 9:30:30 PM

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

by ChrisMarshallNY

5/17/2026 at 1:56:57 PM

I understand your pain. That’s why I’ve ported my VMPrint layout engine to Rust. It’s early, but it already shows promising performance improvements over the original TypeScript-based engine, which is already very fast. The Rust version can create fully paginated, publishing-grade layout at around 8,500 pages (or 2,000,000 words) per second on a M4 MacBook. It’s even faster at advanced tasks like mixing texts with irregular exclusion fields. The TS version can do it under 1ms, but I don’t have a measure yet for the Rust version. Unfortunately, people have shown little interest in this kind of components, so I’m no longer inspired to release it in its raw form like I did with VMPrint. My plan is to use it to build a native markdown editor first to test it more fully and just to have fun with it, LOL.

by zhxiaoliang

5/17/2026 at 6:53:16 PM

Your FAQ says:

    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.
So, wouldn't porting VMPrint to Rust make it such that Typst is the clear winner? Or is there something else missing?

by argee

5/18/2026 at 2:24:28 AM

VMPrint was a document pipeline and indeed somewhat crossed path with Typst, but I’ve since carved out its engine module, stripped away all dependencies so it's a pure math engine now that can be used anywhere.

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.

by zhxiaoliang

5/17/2026 at 2:01:14 PM

Just checked out VMPrint and it's crazy! Keep up the efforts. If you/someone could get a HTML/CSS input layer in front of VMPrint that would be a killer feature? Or is it possible already?

by lewisjoe

5/18/2026 at 2:33:58 AM

Thank you. The architecture to get an HTML/CSS input layer in front of VMPrint is already there via a component called Transmuter. I have made transmuters to allow markdown with custom syntax support as input, and they work extremely well. Full support of HTML/CSS will be still be difficult, but a well-defined subset should be easy. The sibling Layoutmaster project also demonstrates this -- you can hand it a DOM element and it automatically grabs the styles and contents, converts them into the JSON AST, then feeds them to the engine for instant layout.

by zhxiaoliang

5/17/2026 at 2:07:06 PM

HTML/CSS is notoriously bad for print.

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.

by cluckindan

5/18/2026 at 2:34:23 AM

Exactly!

by zhxiaoliang

5/17/2026 at 1:56:19 PM

Everyone loves to complain about the "bloat" in Chrome, but how many have actually taken the time to measure it against a native rewrite? Love this article. We take so much for granted in the modern WebKit/Blink stack. Modern multilingual text processing is a genuinely hard problem.

by StilesCrisis

5/17/2026 at 12:29:07 PM

How is "performance" defined? Does it take into account the amount of memory required in each case?

by elch

5/17/2026 at 12:30:16 PM

The purpose of limiting memory use is so your computer does not become laggy as you run out of memory. We don’t do it for its own sake.

But then, what’s the point in using an inherently laggy technique to save memory?

by Filligree

5/17/2026 at 12:48:53 PM

The purpose of not wasting memory is so we have free memory to use productively.

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?

by desdenova

5/17/2026 at 12:45:22 PM

Was going to answer almost the same.

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.

by dive

5/17/2026 at 12:32:55 PM

How about running many tasks on the machine at the same time?

by elch

5/17/2026 at 12:58:08 PM

Apparently devs forget that there are other apps running on the target machines. It's OK to just gobble as much of the resources as possible.

by skeledrew

5/17/2026 at 1:01:51 PM

I am sure that they use MacBook Neo for development. /s

by elch

5/17/2026 at 12:58:54 PM

first you make it correct, than you make it fast

a fast performant incomplete solution will lose to a slow correct complete one

by dist-epoch

5/17/2026 at 3:13:17 PM

You can’t make a lightweight airplane by making a heavy airplane and cutting off some parts.

by xigoi

5/17/2026 at 6:18:43 PM

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.

by lokimedes

5/18/2026 at 12:01:08 AM

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.

by f30e3dfed1c9

5/17/2026 at 9:28:42 PM

Never done anything with Macs in this area but Win32 has a RichEdit control that's definitely capable of rendering the same capabilities as markdown, and very efficient too.

by userbinator

5/17/2026 at 12:39:46 PM

This is where QT/JUCE can help. Although you are limited to c++.

by chromadon

5/17/2026 at 2:22:30 PM

If you are looking for something similar but not limited to C++, you can check Slint out: https://github.com/slint-ui/slint/

by ogoffart

5/17/2026 at 7:01:56 PM

This is not what the people want. Understand that. Give us Rust and Qt. Why be so focused on trying to sell something that doesn't measure up? Even beta Bridges is better than Slint. Take the advice and put the energy to better use for the good of Rust.

by RustSupremacist

5/17/2026 at 10:19:05 PM

Qt Bridges might be better if your project can use the `Qt Design Studio Enterprise license`. Otherwise Slint looks like the better option.

Not that I'd use either when I can just make a Web based UI most of the time and be done with it.

by bobajeff

5/17/2026 at 12:50:56 PM

It is tricky, but it is not unheard of to write Qt applications as something other than C++.

by bluGill

5/17/2026 at 1:57:52 PM

These days you write the logic in C++ and UI in QML which is a very pleasent experience.

by rubymamis

5/17/2026 at 5:10:02 PM

Rust bindings exist if you don't like c++

by bluGill

5/17/2026 at 1:56:41 PM

The problem here is that you are not choosing based on knowing how the render pipeline is implemented in these tools and how it would work with your usage of it.

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

by ozgrakkurt

5/17/2026 at 4:29:41 PM

I think in light of the fact that OP included exactly to what they are trying to do, this comment would be helpful to include a more concrete recommendation.

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.

by appplication

5/17/2026 at 5:29:40 PM

This is mainly from my experience developing storage engines using datafusion/polars or arrow2/arrow-rs or rocksdb-msbx.

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.

by ozgrakkurt

5/17/2026 at 1:41:26 PM

How bear solves this? It is looks native to me.

by delduca

5/17/2026 at 12:52:19 PM

I was using Markdown text editors with WPF back in 2012....

And yes WPF is a framework native to the Windows platform ecosystem.

by pjmlp

5/17/2026 at 1:57:00 PM

If you squint enough, you'll see the official Google doc app for Android/iOS is a webview (i.e the editor part)

Fancy text rendering/editing is hard to implement when you leave the luxury of webviews.

by lewisjoe

5/17/2026 at 1:21:21 PM

This explains why so many AI chat tools suck at text selection on MacOS / iOS. They got the streaming and markdown part right … flicker free, but at the cost of text selection.

by waynecochran

5/17/2026 at 7:08:03 PM

Just AI tools? Most "modern" chat apps suck at text selection because they're in Electron. I can't select parts of whatsapp messages for example.

by nottorp

5/17/2026 at 5:51:34 PM

Those usually use Electron not the native controls.

by trinix912

5/17/2026 at 12:37:26 PM

Not just text. Try to build a ui where you need non-trivial and non-standard behavior and SwiftUI will fail. AppKit is still better in this regard.

by inatreecrown2

5/17/2026 at 1:39:14 PM

> Try to build a ui where you need non-trivial and non-standard behavior and SwiftUI will fail.

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

by CharlesW

5/17/2026 at 9:50:49 PM

They're saying that if you try to step outside the box or achieve a complex design, SwiftUI falls short, which is also my experience with the framework after using it for many years, especially on macOS.

by vor_

5/17/2026 at 12:40:49 PM

Kotlin MP is also pretty decent on Mac

by usernametaken29

5/18/2026 at 2:12:02 AM

sounds like a skill issue.

by rtgfhyuj

5/17/2026 at 2:03:19 PM

Electron runs like crap on older hardware. It's sad that native UI frameworks never got their shit together, but I think if you want performant text rendering you just gotta reduce your expectations. If you're fine with less fancy fonts and "scripting" your UI in something else than JS, then native can work. But it very quickly reveal that you should avoid everything that uses JSON. JSON is just a disease vector for the JavaScript world to infect everything else.

by titzer

5/18/2026 at 1:13:32 AM

> You go to the dark side. And you are amazed.

And your users hate you and look for alternatives.

by dmitrygr

5/18/2026 at 1:02:22 AM

Lots of talk about Electron apps but as much as I like HTML+CSS for the view, where are the actual heavyweight Electron apps for: digital audio workstations, 3D modeling (is Blender an Electron app? I don't know, I'm asking), the complex brokerage apps (which typically pack and render a lot of information on screen), typesetting apps (like Adobe's InDesign or, on the other extreme, a document preparation system like LaTeX), video editing, GIS-related apps, engines for games (and tools to develop games), etc.

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?

by TacticalCoder

5/17/2026 at 8:29:39 PM

Just use AttributedString

by wwalexander

5/17/2026 at 12:43:32 PM

You can just embed a web view in your app, though?

by saagarjha

5/17/2026 at 1:46:48 PM

No insight as to why this is happening?

Where is the profile? Where is the bottleneck?

Just complaining with nothing to contribute.

by tantalor

5/17/2026 at 1:11:20 PM

Hu? We just switched from textual to native because native markdown rendering is finally good. If it was written a year or two ago ok... but now is odd.

by BoredPositron

5/17/2026 at 2:56:50 PM

markdown to html. or markdown stays markdown.

the browser never chokes on html.

by dzonga

5/17/2026 at 12:56:23 PM

the only place where native UI is still better is for ultra-complex UIs - image/video/3d/audio editors. and only because it's easier to create custom UI widgets/renderers than on web stack.

that's it, for everything else native UIs are complete garbage compared to HTML/CSS/reactive frameworks.

by dist-epoch

5/17/2026 at 12:49:25 PM

I once tried mobile development in semi early days android. At the time I made a free Hackaday reader app because I was a daily reader and loved it.

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.

by vasco

5/17/2026 at 7:55:22 PM

> "I once tried mobile development in semi early days android."

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.

by MrDresden

5/17/2026 at 12:48:56 PM

Outside of niche applications (e.g. virtual desktops, gamming, embedded systems) native UIs are dead.

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

by diego_moita

5/17/2026 at 2:20:19 PM

> native UIs are dead.

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.

by sgt

5/17/2026 at 3:52:53 PM

> the native Turing test

What does this mean?

by argee

5/17/2026 at 4:35:15 PM

Basically that it's easy - for a user - to determine that a particular app is definitely not built using native SDK. Slack is an example.

by sgt

5/17/2026 at 1:29:41 PM

do you miss Hypercard yet?

by distantsounds

5/17/2026 at 2:04:49 PM

I think the article misses the actual point?

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.

by BillStrong

5/17/2026 at 1:06:26 PM

[dead]

by reddysuyesh

5/17/2026 at 4:47:44 PM

[dead]

by tanlethanh

5/17/2026 at 1:08:15 PM

[dead]

by RyanJohn

5/17/2026 at 12:47:32 PM

I thought models were so good we could vibecode a text renderer for $50. What's the problem here? /s

by camgunz