Live data from Hacker News

Native all the way, until you need text

justsitandgrin.im

51–60 of 328 posts

Re: Native all the way, until you need text

#51

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

And why should they, individually?

It's a tragedy of the commons.

Re: Native all the way, until you need text

#52

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

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.

Re: Native all the way, until you need text

#53
post #39

Earlier quoted context omitted.

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

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

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.

Re: Native all the way, until you need text

#54

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.

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

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.

Re: Native all the way, until you need text

#55
post #39

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.

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

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.

Re: Native all the way, until you need text

#57
post #39

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.

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

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

Re: Native all the way, until you need text

#58
post #39

Earlier quoted context omitted.

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

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.

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.

Re: Native all the way, until you need text

#59
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…

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.

Re: Native all the way, until you need text

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

Post reply on HN