8 ms·

Native all the way, until you need text

• pjmlp 5mo ago
  I was using Markdown text editors with WPF back in 2012.... And yes WPF is a framework native to the Windows platform ecosystem.
• PaulHoule 5mo ago
  Yep. Electron is the worst way to make a desktop app… except for all the others!
• elch 5mo ago
  How is "performance" defined? Does it take into account the amount of memory required in each case?
  • Filligree 5mo ago
    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?
    • elch 5mo ago
      How about running many tasks on the machine at the same time?
      • skeledrew 5mo ago
        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.
        • elch 5mo ago
          I am sure that they use MacBook Neo for development. /s
    • dive 5mo ago
      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.
    • desdenova 5mo ago
      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?
  • dist-epoch 5mo ago
    first you make it correct, than you make it fast a fast performant incomplete solution will lose to a slow correct complete one
    • xigoi 5mo ago
      You can’t make a lightweight airplane by making a heavy airplane and cutting off some parts.
      • deleted 5mo ago
        [deleted]
• cyber_kinetist 5mo ago
  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.
  • nicoburns 5mo ago
    For just rendering (no editing) you could use https://github.com/litehtml/litehtml https://github.com/litehtml/litehtml (C) or https://github.com/DioxusLabs/blitz 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.
    • cyber_kinetist 5mo ago
      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).
      • nicoburns 5mo ago
        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.
    • bobajeff 5mo ago
      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.
• inatreecrown2 5mo ago
  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.
  • CharlesW 5mo ago
    > 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 https://blog.jacobstechtavern.com/p/swiftui-game-engine
    • vor_ 5mo ago
      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.
• splittydev 5mo ago
  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.
• rTX5CMRXIfFG 5mo ago
  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.
  • rafaelmn 5mo ago
    Without web view ? Share the code ?
    • deleted 5mo ago
      [deleted]
  • replygirl 5mo ago
    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
    • jeroenhd 5mo ago
      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.
• danielvaughn 5mo ago
  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.
  • nly 5mo ago
    Qt made this pretty easy 10 years ago
    • LtWorf 5mo ago
      Why pay a license fee when you can make a bloated and slow electron app instead?
      • cybercatgurrl 5mo ago
        exactly! paying a licence takes away valuable money that could be better served by buying the shareholders a new yacht!
      • ethanc8 5mo ago
        Both Qt and Electron are LGPL.
        • LtWorf 5mo ago
          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."
  • jagged-chisel 5mo ago
    I thought attributed text handled this fine since forever. Did it not?
• chromadon 5mo ago
  This is where QT/JUCE can help. Although you are limited to c++.
  • bluGill 5mo ago
    It is tricky, but it is not unheard of to write Qt applications as something other than C++.
    • rubymamis 5mo ago
      These days you write the logic in C++ and UI in QML which is a very pleasent experience.
      • bluGill 5mo ago
        Rust bindings exist if you don't like c++
  • ogoffart 5mo ago
    If you are looking for something similar but not limited to C++, you can check Slint out: https://github.com/slint-ui/slint/ https://github.com/slint-ui/slint/
    • RustSupremacist 5mo ago
      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.
      • bobajeff 5mo ago
        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.
• ryandrake 5mo ago
  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.
  • dive 5mo ago
    `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.
• usernametaken29 5mo ago
  Kotlin MP is also pretty decent on Mac
• saagarjha 5mo ago
  You can just embed a web view in your app, though?
  • cybercatgurrl 5mo ago
    the point is to avoid that
    • saagarjha 5mo ago
      Sure but if you are willing to jump to Electron that quickly maybe you can take a stop along the way.
• camgunz 5mo ago
  I thought models were so good we could vibecode a text renderer for $50. What's the problem here? /s
• Wowfunhappy 5mo ago
  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.
  • stavros 5mo ago
    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".
    • joenot443 5mo ago
      > 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.
      • stavros 5mo ago
        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.
    • Wowfunhappy 5mo ago
      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.
      • 5mo ago
• diego_moita 5mo ago
  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).
  • sgt 5mo ago
    > 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.
    • argee 5mo ago
      > the native Turing test What does this mean?
      • sgt 5mo ago
        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.
• vasco 5mo ago
  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.
  • MrDresden 5mo ago
    > "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.
• sirwhinesalot 5mo ago
  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?
• skeledrew 5mo ago
  > 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.
  • alcazar 5mo ago
    And why should they, individually? It's a tragedy of the commons.
  • DrewADesign 5mo ago
    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.
  • sgt 5mo ago
    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.
    • stephbook 5mo ago
      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?
      • sgt 5mo ago
        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).
• dist-epoch 5mo ago
  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.
• pornel 5mo ago
  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.
  • embedding-shape 5mo ago
    > 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.
    • trinix912 5mo ago
      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.
      • whstl 5mo ago
        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.
        • domga 5mo ago
          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.
• d12bb 5mo ago
  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.
  • longnguyen 5mo ago
    Yep. That is what I did for my AI chat app and it’s indeed the best of both worlds.
• lenkite 5mo ago
  > 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 https://github.com/gonzalezreal/swift-markdown-ui and its next gen replacement https://github.com/gonzalezreal/textual 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.
  • simonw 5mo ago
    Can those handle streaming in new text without flickering?
  • SoKamil 5mo ago
    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.
  • dive 5mo ago
    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.
    • deleted 5mo ago
      [deleted]
    • rtgfhyuj 5mo ago
      yeah /you/ should stick to electron
• reddysuyesh 5mo ago
  [dead]
• RyanJohn 5mo ago
  [dead]
• BoredPositron 5mo ago
  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.
• waynecochran 5mo ago
  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.
  • trinix912 5mo ago
    Those usually use Electron not the native controls.
  • nottorp 5mo ago
    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.
• rubymamis 5mo ago
  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 https://rubymamistvalove.com/block-editor [2] https://www.get-vox.com https://www.get-vox.com
• distantsounds 5mo ago
  do you miss Hypercard yet?
• krzyzanowskim 5mo ago
  "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-promised-land/ https://blog.krzyzanowskim.com/2025/08/14/textkit-2-the-prom...
  • dive 5mo ago
    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.
    • krzyzanowskim 5mo ago
      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.
• teddyh 5mo ago
  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.
  • tantalor 5mo ago
    Electron is just a thin shell around Chromium
  • jeremyjh 5mo ago
    > 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).
  • fassssst 5mo ago
    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.
  • L_Rahman 5mo ago
    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.
• mococa 5mo ago
  How bear solves this? It is looks native to me.
• tantalor 5mo ago
  No insight as to why this is happening? Where is the profile? Where is the bottleneck? Just complaining with nothing to contribute.
• Yokohiii 5mo ago
  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.
  • PaulDavisThe1st 5mo ago
    > 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.
• deleted 5mo ago
  [deleted]
• StilesCrisis 5mo ago
  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.
• ozgrakkurt 5mo ago
  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
  • appplication 5mo ago
    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.
    • ozgrakkurt 5mo ago
      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.
• zhxiaoliang 5mo ago
  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.
  • lewisjoe 5mo ago
    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?
    • cluckindan 5mo ago
      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.
      • zhxiaoliang 5mo ago
        Exactly!
    • zhxiaoliang 5mo ago
      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.
• lewisjoe 5mo ago
  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.
• titzer 5mo ago
  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.
• BillStrong 5mo ago
  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.
• pier25 5mo ago
  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-platform-email-client-with-nothing-but-html-aa12fc33bb02 https://medium.com/missive-app/our-dirty-little-secret-cross...
  • antiframe 5mo ago
    Powerful, perhaps. Slow, for sure.
    • stephbook 5mo ago
      I just use a fullscreen <canvas> and WebGPU. It's performant as hell. Skill issue, I guess. /s
      • antiframe 5mo ago
        Performance is relative. Every electron app I have used has been slower than their equivalent native app.
    • pier25 5mo ago
      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.
  • tpmoney 5mo ago
    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.
• deleted 5mo ago
  [deleted]
• msephton 5mo ago
  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/ https://www.gingerbeardman.com/apps/papertrail/
  • sandoze 5mo ago
    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.
    • itsthecourier 5mo ago
      [flagged]
  • satvikpendem 5mo ago
    [flagged]
  • virgil_disgr4ce 5mo ago
    > 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.
    • msephton 5mo ago
      I stand by the claim. But what do I know? ;)
• dzonga 5mo ago
  markdown to html. or markdown stays markdown. the browser never chokes on html.
• tedggh 5mo ago
  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.
• iamcalledrob 5mo ago
  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.
  • deleted 5mo ago
    [deleted]
  • iamcalledrob 5mo ago
    ...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).
  • kenferry 5mo ago
    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.
    • Klonoar 5mo ago
      Also NSAttributedString would invoke WebKit under the hood if you went to render an HTML string.
      • cybercatgurrl 5mo ago
        this is the correct answer
• tanlethanh 5mo ago
  [dead]
• arjie 5mo ago
  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.
• lokimedes 5mo ago
  We did https://markant.md 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.
  • f30e3dfed1c9 5mo ago
    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.
    • lokimedes 5mo ago
      Thank you, great spotted. I did make a CLI tool for it, but it was a bit too cumbersome to distributed it via the App Store for the first release, so I dropped it from the release but forgot to update the help.
• c-smile 5mo ago
  > 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-md.png 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.
• freequest 5mo ago
  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.)
• wwalexander 5mo ago
  Just use AttributedString
• andix 5mo ago
  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.
  • c-smile 5mo ago
    > 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.
  • cybercatgurrl 5mo ago
    i’m pretty sure you just justified ChromeOS’s existence
• userbinator 5mo ago
  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.
• ChrisMarshallNY 5mo ago
  > 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).
• TacticalCoder 5mo ago
  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?
• dmitrygr 5mo ago
  > You go to the dark side. And you are amazed. And your users hate you and look for alternatives.
• deleted 5mo ago
  [deleted]
• instagary 5mo ago
  I've been working on a MarkdownView library for iOS based on tree sitter: https://github.com/HumanInterfaceDesign/MarkdownView 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
• rtgfhyuj 5mo ago
  sounds like a skill issue.
• knlam 5mo ago
  Thanks for this post. This will be my bible for the "electron bad" crowd
• dchest 5mo ago
  Fun fact: the original iPhone's UITextField and UITextView were backed by WebKit (https://x.com/kocienda/status/1400484168199401477 https://x.com/kocienda/status/1400484168199401477)
• wek 5mo ago
  [flagged]
• cybercatgurrl 5mo ago
  as someone who has worked first hand with CoreText back in the objective-c days, yea what a nightmare. powerful but definitely not what you want to be using from SwiftUI it’s disappointing to find out things have not improved with SwiftUI