Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Native all the way, until you need text

justsitandgrin.im

Post reply on HN
Print view View original

281–290 of 328 posts

Re: Native all the way, until you need text

#281

Post by rtgfhyuj »

dive wrote: post #60
lenkite wrote: post #44

> 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 - pre…

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 th…

yeah /you/ should stick to electron

Re: Native all the way, until you need text

#282

Post by zhxiaoliang »

argee wrote: post #218
zhxiaoliang wrote: post #89

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 ir…

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 suc…

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.

Re: Native all the way, until you need text

#283

Post by zhxiaoliang »

lewisjoe wrote: post #99
zhxiaoliang wrote: post #89

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 ir…

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?

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.

Re: Native all the way, until you need text

#284

Post by zhxiaoliang »

cluckindan wrote: post #106
lewisjoe wrote: post #99

Earlier quoted context omitted.

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?

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.

Exactly!

Re: Native all the way, until you need text

#285

Post by c-smile »

andix wrote: post #236

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 renderin…

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

Re: Native all the way, until you need text

#287

Post by ladberg »

Dwedit wrote: post #68
pornel wrote: post #38

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…

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

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

Re: Native all the way, until you need text

#288

Post by dataflow »

msephton wrote: post #265
dataflow wrote: post #261

Earlier quoted context omitted.

> 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 viewe…

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

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.

Re: Native all the way, until you need text

#289

Post by msephton »

dataflow wrote: post #288
msephton wrote: post #265

Earlier quoted context omitted.

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

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.

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.

Re: Native all the way, until you need text

#290

Post by novok »

CharlesW wrote: post #259
vor_ wrote: post #254

Earlier quoted context omitted.

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

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…

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.

Post reply on HN