logoalt Hacker News

stavrostoday at 1:00 PM4 repliesview on HN

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


Replies

mrbombastictoday at 2:33 PM

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.

p-e-wtoday at 1:23 PM

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

Wowfunhappytoday at 1:20 PM

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.

show 2 replies
joenot443today at 1:12 PM

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

show 1 reply