7 ms·

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 Web

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.

stavros 5mo ago
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".
- joenot443 5mo ago
  > 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.
  - stavros 5mo ago
    If we're all agreeing that all the native elements are useless, I can see how the question is "do I use Metal or do I use WebKit", but my question wasn't about WebKit vs metal, it was WebKit vs native elements.
- Wowfunhappy 5mo ago
  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.
  - stavros 5mo ago
    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.
    - Wowfunhappy 5mo ago
      HTML is basically analogous to RTF, no?
      - nottorp 5mo ago
        maybe html 0.9 :)
    - deleted 5mo ago
      [deleted]
  - carlosjobim 5mo ago
    If think that the MacOS GUI is actually entirely rendered as a series of PDFs, if I have understood things correctly.
    - jonhohle 5mo ago
      That’s how it originally worked, but Apple has moved away from PDF to other native GPU frameworks for drawing. Now window content is stored as bitmaps instead of redrawing vector instructions.
      - mpweiher 5mo ago
        That's not how it ever worked. Quartz is a vector drawing engine whose output can be captured as a PDF and which is closely aligned with the PDF imaging model. Window content was always stored as bitmaps.
- p-e-w 5mo ago
  > 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.
- mrbombastic 5mo ago
  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.
- tardedmeme 5mo ago
  Using an HTML renderer to render arbitrarily formatted text with full HTML formatting capabilities makes perfect sense. If that's your problem statement, then you kinda need an HTML renderer.
  - stavros 5mo ago
    The author wasn't trying to render HTML. Everyone is focusing on the word "Markdown", I wish the author had just said "rich text" instead so we could actually have a fruitful conversation.
    - Wowfunhappy 5mo ago
      But if he'd said rich text the answer would be different! Markdown is designed to be converted to html, and in fact it can contain html.
      - stavros 5mo ago
        Right, but he clearly didn't mean HTML, otherwise he wouldn't be trying native elements in the first place.
        tardedmeme 5mo ago
        He means Markdown, but Markdown is mean to turn into HTML. Rendering it any other way than converting it to HTML gives a different result, and if anyone complains about it, it'll be your fault since you didn't render it the proper way. It turns out a lot of things are like this. Another commentator mentioned Slack messages.
        Wowfunhappy 5mo ago
        I feel like Typescript is a good analogy here. Typescript is its own language, but it is intended to be transpiled into Javascript. Yes, you could probably create a JIT that executes Typescript directly—but you would do so at your own peril. Reaching for an existing Javascript interpreter such as JavaScriptCore or V8 is the logical choice.
dive 5mo ago
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".
- Wowfunhappy 5mo ago
  > 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.
  - dive 5mo ago
tantalor 5mo ago
OP thinks "native" = only using Swift/ObjC primitives WebKit is cheating I guess? Because it exists on other platforms? Might as well use Java
- ryeights 5mo ago
  So I can build my entire app in a WebKit wrapper and call it native? I think ‘native’ in this context is well-understood to mean eschewing web or cross-platform renderers
the_gipsy 5mo ago
> Using WebKit to render Markdown seems completely appropriate. It doesn't? Needs an explanation.
- throawayonthe 5mo ago
  markdown is a markup language 'intended' to be rendered as HTML, WebKit seems appropriate to render HTML
  - TingPing 5mo ago
    More importantly all HTML is valid markdown.
    - the_gipsy 5mo ago
      Putting HTML in markdown defeats the purpose IMHO.
      - nchie 5mo ago
        That doesn't make it not true though. Markdown generally supports HTML (though oftentimes only a subset), and is typically styled using CSS. Using a web view makes complete sense to me.
      - Wowfunhappy 5mo ago
        I don't think it does at all! > The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. https://daringfireball.net/projects/markdown/ https://daringfireball.net/projects/markdown/ Using some semantic HTML as an occasional escape hatch is perfectly in line with this overall goal.
        what 5mo ago
        > without looking like it’s been marked up with tags or formatting instructions. From your own quote. Embedding html absolutely violates the spirit.
InsideOutSanta 5mo ago
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.
- kenferry 5mo ago
  The native Apple libraries are terrific at rendering rich text, it’s one of their strongest assets. The poster’s issues seem to be specifically because they want to use markdown as the backing. The native rich text backing for native Apple views is attributed strings. They could translate the markdown to attributed strings, but seems like they don’t want to.
  - andix 5mo ago
    [dead]
  - Bolwin 5mo ago
    ..where did you get that impression? The web also requires you to convert to html. I don't see how this is different
    - array_key_first 5mo ago
      Markdown can contain arbitrary HTML. It only makes sense to use an HTML viewer for what is essentially a dialect of HTML, aka a browser engine.
    - kenferry 5mo ago
      I have this impression because I know the native controls are terrific at rich text, so for some reason that support isn't done in a way the author wants to use. The source code of the TextEdit app on Mac is actually published as an example project for the frameworks. Everything in there is provided by the native framework controls. It would make sense, for example, if you wanted to allow editing of the rich text and have the markdown be directly accessible by the user. The conversion of markdown -> attributed strings -> markdown would not produce the same raw text, which is a problem if the user can directly edit or view the markdown. The user hitting cmd-B in the text view to make something bold might end up scrapping some explicit formatting they did to the raw markdown.

stavros 5mo ago

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

joenot443 5mo ago
> 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.
- stavros 5mo ago
  If we're all agreeing that all the native elements are useless, I can see how the question is "do I use Metal or do I use WebKit", but my question wasn't about WebKit vs metal, it was WebKit vs native elements.
Wowfunhappy 5mo ago
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.
- stavros 5mo ago
  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.
  - Wowfunhappy 5mo ago
    HTML is basically analogous to RTF, no?
    - nottorp 5mo ago
      maybe html 0.9 :)
  - deleted 5mo ago
    [deleted]
- carlosjobim 5mo ago
  If think that the MacOS GUI is actually entirely rendered as a series of PDFs, if I have understood things correctly.
  - jonhohle 5mo ago
    That’s how it originally worked, but Apple has moved away from PDF to other native GPU frameworks for drawing. Now window content is stored as bitmaps instead of redrawing vector instructions.
    - mpweiher 5mo ago
      That's not how it ever worked. Quartz is a vector drawing engine whose output can be captured as a PDF and which is closely aligned with the PDF imaging model. Window content was always stored as bitmaps.
p-e-w 5mo ago
> 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.
mrbombastic 5mo ago
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.
tardedmeme 5mo ago
Using an HTML renderer to render arbitrarily formatted text with full HTML formatting capabilities makes perfect sense. If that's your problem statement, then you kinda need an HTML renderer.
- stavros 5mo ago
  The author wasn't trying to render HTML. Everyone is focusing on the word "Markdown", I wish the author had just said "rich text" instead so we could actually have a fruitful conversation.
  - Wowfunhappy 5mo ago
    But if he'd said rich text the answer would be different! Markdown is designed to be converted to html, and in fact it can contain html.
    - stavros 5mo ago
      Right, but he clearly didn't mean HTML, otherwise he wouldn't be trying native elements in the first place.
      - tardedmeme 5mo ago
        He means Markdown, but Markdown is mean to turn into HTML. Rendering it any other way than converting it to HTML gives a different result, and if anyone complains about it, it'll be your fault since you didn't render it the proper way. It turns out a lot of things are like this. Another commentator mentioned Slack messages.
        Wowfunhappy 5mo ago
        I feel like Typescript is a good analogy here. Typescript is its own language, but it is intended to be transpiled into Javascript. Yes, you could probably create a JIT that executes Typescript directly—but you would do so at your own peril. Reaching for an existing Javascript interpreter such as JavaScriptCore or V8 is the logical choice.

dive 5mo ago

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

Wowfunhappy 5mo ago
> 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.
- dive 5mo ago

tantalor 5mo ago

OP thinks "native" = only using Swift/ObjC primitives WebKit is cheating I guess? Because it exists on other platforms? Might as well use Java

ryeights 5mo ago
So I can build my entire app in a WebKit wrapper and call it native? I think ‘native’ in this context is well-understood to mean eschewing web or cross-platform renderers

the_gipsy 5mo ago

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

throawayonthe 5mo ago
markdown is a markup language 'intended' to be rendered as HTML, WebKit seems appropriate to render HTML
- TingPing 5mo ago
  More importantly all HTML is valid markdown.
  - the_gipsy 5mo ago
    Putting HTML in markdown defeats the purpose IMHO.
    - nchie 5mo ago
      That doesn't make it not true though. Markdown generally supports HTML (though oftentimes only a subset), and is typically styled using CSS. Using a web view makes complete sense to me.
    - Wowfunhappy 5mo ago
      I don't think it does at all! > The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. https://daringfireball.net/projects/markdown/ https://daringfireball.net/projects/markdown/ Using some semantic HTML as an occasional escape hatch is perfectly in line with this overall goal.
      - what 5mo ago
        > without looking like it’s been marked up with tags or formatting instructions. From your own quote. Embedding html absolutely violates the spirit.

InsideOutSanta 5mo ago

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.

kenferry 5mo ago
The native Apple libraries are terrific at rendering rich text, it’s one of their strongest assets. The poster’s issues seem to be specifically because they want to use markdown as the backing. The native rich text backing for native Apple views is attributed strings. They could translate the markdown to attributed strings, but seems like they don’t want to.
- andix 5mo ago
  [dead]
- Bolwin 5mo ago
  ..where did you get that impression? The web also requires you to convert to html. I don't see how this is different
  - array_key_first 5mo ago
    Markdown can contain arbitrary HTML. It only makes sense to use an HTML viewer for what is essentially a dialect of HTML, aka a browser engine.
  - kenferry 5mo ago
    I have this impression because I know the native controls are terrific at rich text, so for some reason that support isn't done in a way the author wants to use. The source code of the TextEdit app on Mac is actually published as an example project for the frameworks. Everything in there is provided by the native framework controls. It would make sense, for example, if you wanted to allow editing of the rich text and have the markdown be directly accessible by the user. The conversion of markdown -> attributed strings -> markdown would not produce the same raw text, which is a problem if the user can directly edit or view the markdown. The user hitting cmd-B in the text view to make something bold might end up scrapping some explicit formatting they did to the raw markdown.