Ken CaseMay 20

"Native apps are bad at rendering text" is interesting framing. Web browsers are native apps, after all, and they're great at rendering web text. Native PDF viewers are great at rendering PDF text. And native rich text editors are great at RTF text—with rulers containing tab stops, etc.

(Back in the '90s, I built parsers and renderers for all three of these: OmniWeb on AppKit, OmniPDF on AppKit, and RTF text for Java.)

The very real, hard problem is round-tripping content between text systems.

Show threadKen CaseMay 20

Modern HTML + CSS + JavaScript is an incredibly complex text system that can really only be accurately rendered by a modern browser. A modern browser is a very heavyweight, complex piece of native app code that comes with a ton of overhead.

So if you're already running a browser and rendering content inside it, you've already paid the overhead and why not render Markdown/HTML? But if you're running a much leaner native app, adding a simple Markdown notes field is going to add a lot of overhead.

Show threadHelge HeßMay 20
@kcase Wouldn't you still expect that to be part of Cocoa or whatever the native system is, vs. coming as part of custom apps? Why isn't the Cocoa text system essentially a browser rendering engine? I assume it should be?
(No offence, but even OmniWeb is actually a good example of that. It was beautiful and native, but it was actually really slow, so slow, that most people rather used Netscape via X11 IIRC.)
Show threadKen Case

@helge It's already built into the system frameworks as WebKit. I wouldn't want that that overhead for most text fields, but it's certainly available to reach for when I want to use it.

(WebKit is what modern OmniWeb uses, of course. But I also use it for notes in some internal apps. Aside from the overhead, it quickly becomes obvious that a bare web browser engine doesn't itself provide a great text editing experience; that's only possible when you also bolt on a bunch of JavaScript.)

May 20 at 8:18pmIvory for Mac
Show threadHelge HeßMay 20
@kcase Yes, sure, I think the issue is that the engines are currently targeted at *just* providing everything in a browser sandbox.
But I still think that the Cocoa text system should be on par in capabilities and performance w/ a real browser? I.e. it should be trivial to build a browser w/ it. Currently you can embed WK, but it's essentially an opaque blob rather than a 1st party API.
I'm not an expert enough to say how this would work, but as a user I expect it to work :-)