Live data from Hacker News

Native all the way, until you need text

justsitandgrin.im

121–130 of 328 posts

Re: Native all the way, until you need text

#121
post #43

Earlier quoted context omitted.

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

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

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.

Re: Native all the way, until you need text

#122

Earlier quoted context omitted.

> Using WebKit to render Markdown seems completely appropriate. It doesn't? Needs an explanation.

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

More importantly all HTML is valid markdown.

Re: Native all the way, until you need text

#123

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.

If HTML engines are better than native UI libraries at rendering rich text, possibly the hardest thing UIs need to render, why would I not also use it to render easier things like buttons or text fields?

Also, OS X rendered its UI with DisplayPDF/Quartz for the longest time.

Re: Native all the way, until you need text

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

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.

Re: Native all the way, until you need text

#125
post #113

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

Agreed. He's basically complaining and moaning about Markdown not being fast to work with in Swift, when nobody has really put a lot of effort into that yet. yet despite this, he's not willing to contribute to that himself.

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?

Re: Native all the way, until you need text

#126
post #68
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.

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?

Re: Native all the way, until you need text

#127

Earlier quoted context omitted.

It's SwiftUI that is at fault here[1][2], not native apps in general. I wrote my native app in Qt C++ and QML and showed that it is *significantly* faster and uses significantly less RAM than similar web apps[3]. So, no, web apps, in general, are slower and uses more resources than well-engineered native apps. [1] https://notes.alinpanaitiu.com/SwiftUI%20is%20convenient,%20... [2] https://x.com/daniel_nguyenx/status/…

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

[deleted]

Re: Native all the way, until you need text

#129
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 made it between Aug 2025 and Apr 2026, development is ongoing.

Every keystroke is restyled in under 8ms: no debouncing, no delayed rendering. 20 rapid keystrokes are processed in 150ms with full restyling after each one.

Tag and boolean searches complete in under 20ms. Visible-range rendering is 25x faster than full-document styling. 120Hz screen refresh supported.

App file size was 722 KB for 1.0, and 1.1 with more features is looking like ~950 KB.

If I can do it on iOS then it's must be 10x easier on macOS.

https://www.gingerbeardman.com/apps/papertrail/

Re: Native all the way, until you need text

#130
post #118

Maybe controversial but I think HTML + CSS is truly the most powerful system to make GUIs. There’s really nothing else out there that competes with a similar performance and productivity. This old article by the Missive team (the email client) convinced me. https://medium.com/missive-app/our-dirty-little-secret-cross...

Powerful, perhaps. Slow, for sure.

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

Skill issue, I guess. /s

Post reply on HN