Comment by dive | Hacker News Reader

Comment by dive | Hacker News Reader

Parent Full thread

Yeah, this is actually my current in-progress solution: render the final Markdown & the streaming through WebKit.

And yes, I agree: on macOS, WebKit is a native OS framework. In that sense, it is "native". 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. I am not saying that using WebKit for a Markdown view is wrong. Quite the opposite, it is probably the most reasonable option available. The problem is that the "native" solution here is still effectively a web-rendering solution. There is a cost. Each `WKWebView` brings a WebKit engine with its own performance & memory overhead. So you cannot just sprinkle `WKWebView` everywhere & pretend it is free native macOS component as any other. My frustration is mostly that this is the answer. For this kind of UI, SwiftUI / AppKit / TextKit still do not give you a clean, modern, composable path that feels better than "just use WebKit".

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

I am with you here.

But I think my opinionated point from the article still stands: if you need rich text & good typography without fighting the platform, then web technologies quickly become the pragmatic choice.

For my app, I will probably continue with WebKit. It is the most reasonable middle ground for now. But in this situation, it is tempting to jump to something with a stronger rendering engine, like Chromium instead of WebKit, and start using the huge ecosystem of tools that already work. For example, https://diffs.com is one of the most tempting parts for me. The awkward thing is that embedding WebKit & calling it a day does not feel like a clean native solution either. You lose many of the native things you get when rendering through SwiftUI primitives, but you also do not get the full power & ecosystem of a proper web stack. And that makes it much easier to understand why so many companies (good & bad) choose Electron.

From an engineering perspective, even the fact that you can avoid this controversial middle ground entirely & build the app around web technologies from the start makes sense. It is not just laziness or ignorance of native platforms. Sometimes it is simply the more consistent & logical architecture.

Reply on news.ycombinator.com