Item — HN Reader

Why is there no browser engine? It would seem like your method of "writing my own of everything I need" doesn't really scale well to something like the entire browser stack. And it appears that WebKit should not be that hard to integrate (in the general case, not sure about this kind of authoring app).

You may have a good reason, I just can't think of it off the top of my head.

1 comments

Well, of course the real reason is simply that I wanted to make use of the stuff that I already had written, which consisted primarily of a fast compositing engine with JavaScript hooks. (I'm not one of those people who want to start from scratch for each project.)

But I do think there is a solid case for this approach. Consider something like image filters and applying them to video. If the authoring UI were implemented in WebKit, I don't know how I could get realtime responsiveness for video manipulation. Now it's no problem in Radi because the rendering bottleneck to produce actual browser-playable <video> content only happens upon publishing.

Being on the native side gives me a theoretical edge when it comes to new browser features -- I'm thinking of something like visual effects which may be supported only by Mozilla but not WebKit, or vice versa. Not being married with a specific engine could be an advantage.

It's worth mentioning that Radi does actually use WebKit to render the content in HTML layers. So you can place custom HTML within a document, and it's rendered with browser-style text antialiasing within the app. (It's not dynamic, though -- just a snapshot of the HTML rendering.)