[zamadatix]

Wouldn't that just be "Raw"? I.e. start a webserver and ask the system to open the URL. There is no "special stuff" to do in this case like avoid sockets in favor of IPC to a well known webview or package CEF and no real integration to make with dev tools etc after - it's just open socket and serve from prebuilt binary.

[bobajeff]

No. As I understand it, the Raw backed just gives you a Window with input handling and you have to embed something like Skia, WebGPU for the graphics. So basically you have make your widget library yourself.

Now you can just start a server with deno pretty easily and serve a website. But WebUI will actually also manage opening the browser window for you as well a make the communication between backend and frontend just like using a Webview or electron.

[zamadatix]

Raw still exposes access to Deno APIs & ability to call native code but it doesn't seem to assume it should give you a window out of the box or anything based on my testing (AFAICT you have to orchestrate most all of that yourself, Deno just won't get in the way with packaging other stuff like CEF automatically). If this is just some issue on my machine with the canary build though, the existing "Deno compile" should accomplish the same goal for a binary version without any GUI components at all.

Outside making it so you don't have to call to open the link yourself, I'm still not sure what could be integrated in the scenario. Deno can integrate with WebView because the WebView APIs were designed to allow external applications to have full control of the session. CEF (the Electron-like) approach works because Deno packages CEF & the APIs as part of the app itself, having even more control of everything. Browsers are meant to be in control of themselves or the user, and have had a long history of fighting malware trying to act otherwise.