Comment by iamcalledrob | Hacker News Reader

Comment by iamcalledrob | Hacker News Reader

Fun fact: This is how Apple used to do it too.

Old versions of macOS / AppKit used to use WebKit to render rich text inside their native NSTextFields. Turns out text is hard :)

And besides, the native WebView is super fast and lightweight, and its not unreasonable to use it as a text layout engine. You could use separate webviews for every row in a table and you'd still get fantastic performance.

iMessage for mac used to use a webview too. Adium as well. HTML is absolutely the right tool for the job if you're rendering rich/marked-up text.

You’re confusing iOS and Mac OS here.

The Mac never used WebKit for NSTextField rendering. When iOS was first written, WebKit was used as the text renderer everywhere initially, including in UIKit controls (the “sweet solution”). This proved to be too heavyweight / cumbersome and the coretext/appkit text rendering approach was brought over.

Also NSAttributedString would invoke WebKit under the hood if you went to render an HTML string.

this is the correct answer

On what platform? It invoked WebKit always on iOS in the early days, html or not. On Mac, AppKit could import html to attributed strings before WebKit existed.

...although the logic in the article is slightly odd:

  1. Discover complex native text rendering is hard
  2. Render text in a low-level way, complain about having to (re)implement native interactions
  3. Try WebKit and it works great!
  4. Throw WebKit away??
  5. Have to re-implement native interactions??

Personally, I would have stopped at (3).

Reply on news.ycombinator.com