Hacker News

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

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.

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.

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.

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

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

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

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.

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.

> Chromebooks

Have you tried with stock ChromeOS?

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.

According to the article, native is slower though.

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

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)

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.

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

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.

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?

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.

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.

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

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.

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.

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

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.

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

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

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

yeah /you/ should stick to electron

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.

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

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

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.

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

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.

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

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

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.

Do not know about "forever", at the moment it works okay, I guess. But for a long long time most of the iOS apps were using this https://github.com/TTTAttributedLabel/TTTAttributedLabel to have proper support for links & other basic attributes.

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

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?

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.

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

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.

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

Skill issue, I guess. /s

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.

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.

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.

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.

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?

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.

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

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

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.

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

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.

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.

> the native Turing test

What does this mean?