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

61–70 of 328 posts

Re: Native all the way, until you need text

#61

Post by Wowfunhappy »

stavros wrote: post #58
Wowfunhappy wrote: post #55

Earlier quoted context omitted.

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.

HTML is basically analogous to RTF, no?

Re: Native all the way, until you need text

#62

Post by rubymamis »

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

Re: Native all the way, until you need text

#63

Post by danielvaughn »

joenot443 wrote: post #52
danielvaughn wrote: post #10

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.

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.

Re: Native all the way, until you need text

#65

Post by embedding-shape »

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…

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

Re: Native all the way, until you need text

#66

Post by bobajeff »

nicoburns wrote: post #14
cyber_kinetist wrote: post #3

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.

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.

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.

Re: Native all the way, until you need text

#67

Post by latexr »

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…

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

Re: Native all the way, until you need text

#68

Post by Dwedit »

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.

Re: Native all the way, until you need text

#70

Post by CharlesW »

inatreecrown2 wrote: post #7

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.

> 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

Post reply on HN