HTMLRenderer vs CEFSharp

[paulmansour]

What are the pros/cons of using CEFSharp instead of HTMLRenderer?

[StefanoLanzavecchia]

Sorry if I just barge in, but this topic interests me a lot. In fact, let me also apologise for beginning with a question: did you manage to get CEFSharp to work in a Dyalog form? I tried several times, but all I manage to obtain are either very obscure errors from CEFSharp itself or the Dyalog process disappearing without a trace as soon as I initialise an instance of the renderer. I didn't just stop at the error message: I tried to connect the Visual Studio Debugger with the CEFSharp source code and the PDB and everything but eventually I gave up because CEFSharp and CEF are just too complex for my tiny brain.

This said, HTMLRenderer, from what I can see, provides a very tight integration with Dyalog and it's tested to be cross-platform and that's definitely a plus: it pretty much works out of the box and it provides features which one would have to rebuild on CEFSharp. I believe websockets supports through URL interception is one of such features, but I may be wrong. Dyalog have decided to only support a very small fraction of the incredibly large API surfaced by CEF through CEFSharp, which is both a blessing and a curse. Remember when you had to wait for Dyalog to add a new option to their very polished wrapping around the Windows ListView control? This is the same: CEF might support a certain feature, but in the HTMLRenderer it is unreachable. That's why I've tried to experiment with CEFSharp more than once, hoping to cut the middleman.
In the same vein, I have tried to experiment with Microsoft's WebView2 (https://docs.microsoft.com/en-us/micros ... /webview2/) which is another take on a the same problem, basically. Microsoft's approach is more polished than CEFSharp but it's not without its issues. I'll be honest: I don't remember if I managed to get a working instance in a Dyalog form, but that's not the point. The problem is that Microsoft, just like Dyalog, have decided to only wrap a very small subset of the Chromium API. Methods which in my opinion are fundamental like PrintToPdf, are simply not covered, which makes the control useless for my needs. It'll improve over the years, so I'll just sit and wait.
In the meantime I've been bugging Dyalog with feature requests and most got through so it may be that v18.1 of the HTMLRenderer will cover all my current needs and I'll jump to adopt it.
Nevertheless I would not mind being able to use CEFSharp in case a certain feature I need exists but Dyalog cannot or won't wrap it (for good reasons).

[Morten|Dyalog]

Dyalog hasn't been giving work on the HTMLRenderer a very high priority due to the lukewarm reaction that we perceived from our user base, since it was introduced. I'm not sure whether this was because we were ahead of our time with the idea, or key features were missing that made it less useful. However, if users are now keen to dive in more deeply, we are definitely open to putting more time into the HTMLRenderer implementation.

[paulmansour]

Stefano,

Thanks very much for detailed response. Norbert and I spent an hour or two yesterday trying to get CEFSharp to work and failed more or less as you described. Definitely a con for CEFSharp. And as you note HTMLRenderer works out of the box, a big pro. Maybe no more needs to be said. I also looked at WebView2, but couldn't even begin to see how to start using it, lots of MS jargon for the install, and distribution. One look at the issues board on GitHub was enough to make me say forget it.

My gut reaction is to go all-in with HTMLRenderer. I have always been a big fan of having as much as possible in the interpreter. I think the pros of having Dyalog wrap CEF with tight integration probably outweighs the cons (maybe pros!) of not having a huge API and having to wait for Dyalog to add a property or method from time to time. Norbert is not so sure. He thinks there is no reason we shouldn't be able to get CEFSharp to work, and once the initial hurdles are overcome, the advantages may be big, given the resources that go into CEFSharp. We will see if we can even get it to work - he's tinkering with it as I write.

I would also note that one is not cutting out the middleman by using CEFSharp, but rather replacing one middleman with another - same with WebView2. The question is which middleman is the best option. Right now I'm leaning Dyalog.

Paul

PS. If you like printing HTML, have you tried Prince? As far as I know it is the only thing that fully supports the CSS fragmentation module.

[paulmansour]

Morten,

Norbert was an early adopter, but there were definitely bugs and missing features that made early adoption hard if not impossible. For example, the first version did not report the HTTP method in the argument of the HTTPRequest method - which seemed to defeat the purpose of the whole project. I just started using it with V18, and it was very easy to get started. I was also put off by the 250 MB distribution requirement, which now seems be way overstated by around 100 MB.

Either HTMLRenderer or CEFSharp or Webview2 is going to be critical for us. As noted above, I think HTMLRenderer is the probably the right choice.

[PGilbert]

We have tried HTMLRenderer and it is working super fine. The only problem is that there are not too many methods yet. Currently, we are developing our application with https://www.teamdev.com/dotnetbrowser that has a ton of methods and is working fine with Dyalog. Hopefully, HTMLRenderer will catch up and we can switch back to HTMLRenderer before we finish our development.

[paulmansour]

Hopefully, HTMLRenderer will catch up and we can switch back to HTMLRenderer before we finish our development.

Do you have a wish list of enhancements? Are they on Dyalog's radar?

[StefanoLanzavecchia]

PS. If you like printing HTML, have you tried Prince? As far as I know it is the only thing that fully supports the CSS fragmentation module.

Thank you for the suggestion!
Actually, more than liking printing HTML, we have embedded a mini HTML app in Sofia (https://dyalog.tv/Dyalog16/?v=GwhXdnJgDak) and we'd like our users to print from it (PDF or PNG). Extracting the HTML/SVG/CSS contained in our "web view" for printing and feeding it to an external app is relatively difficult. HTMLRenderer (and CEF/CEFSharp) have a wonderful PrintToPdf method which does just that. At the moment CEF/CEFSharp give more control to the options of the PDF generated but they may be coming to HTMLRenderer as well.
WebView2, not yet... (https://github.com/MicrosoftEdge/WebView2Feedback/issues/364).

[PGilbert]

Hello Paul, yes we have shared our list of basic methods that we need with Dyalog and they reacted positively to it. But not all of them were implemented (still waiting for the Zoom method). The only problem is if we need a particular method that is not needed in general by the community it may take longer to implement while with DotNetBrowser everything is there and we just have to choose and experiment with it which makes the development process faster.

We support the idea from Dyalog that HTML is the future for the User Interface and hopefully they will have enough enthusiasm from their customers to encourage them to push it further. To have a public thread about feature requests for the HTMLRenderer could be a good idea. On that note to have data-binding from the APL WS to the HTMLRenderer would be dynamite.

[StefanoLanzavecchia]

On that note to have data-binding from the APL WS to the HTMLRenderer would be dynamite.

I'll be honest: I am a bit skeptical about the idea that it's possible to map data to a web browser without considering a particular framework on the web browser side, be it MiServer, or what Michael Hughes is working on or something else, like React, Angular, Dojo, Syncfusion, and the list goes on and on.

How do you envisage data binding to a (local) web app?