dw.js, like nw.js

[trusktr]

Is there anything like this for Deno yet, that gives us a graphical window?

[nayeemrmn]

Duplicate of #3234.

[axetroy]

duplicated #3234

[trusktr]

Actually, this isn't too much of a duplicate at this point, because people in that thread suggest other ideas like binding Deno code to non-web-based GUI toolsets.

This topic is specifically about having a web-based front end that runs Deno code in it, which is only one possible way that Deno can have a standard GUI. The standard GUI could end be being web-based, or it might not.

At this point, having transitioned to Rust, it seems that Servo would be a possible option for Deno if it will have tight integration (as in running Deno code directly in a web view, not just puppeteering of an external browser using message passing and that does not run actual Deno code).

Deno relies on V8 though, so conveivably they could also fork Chrome, and hook the Rust-stuff onto Chrome's V8, so that the JS context is both Deno and Web.

[crowlKats]

The discussion is for a whole solution of GUI, be it web-based or not, so it does include this. In the discussion both servo and chomium have been mentioned a plethora of times, and reasons why either isnt a possible solution currently have been given.

Deno relies on V8 though, so conveivably they could also fork Chrome, and hook the Rust-stuff onto Chrome's V8, so that the JS context is both Deno and Web.

That is more work than what you think it is, and most definitively not a proper and sustainable solution.

In regards to GUI though, there is movement towards having such a project, as in the deno discord server has added a channel for such discussion and work is being put into it.

[trusktr]

I suppose that is #deno-desktop.

It seems that using https://deno.land/x/[email protected] may be an easy way to do this right now, setting headless mode to false so a window is opened and allows user interaction, and then using message passing between the browser context and the Deno backend.

That would be secure by default: a web site would not be able to modify the file system, even if Deno's file system APIs are enabled, unless the Deno backend allows the client to do so.

With some crafty browser detection, the Deno backend could launch puppeteer connected to whichever browser exists (limited to Chrome, FF, and Edge currently), in some specified fallback order.

Another puppeteering option is Playwright, which supports all browsers, but there is no Deno package for Playwright yet.

---

It seems to me as if the main benefit of using Electron or NW.js is that Node.js APIs can be imported directly inside the browser context, but missing that sort of integration would not be a show stopper.

Essentially missing that integration and having only message passing was exactly what Google Chrome Carlo was: it launched a non-headless Chrome instance from a Node.js app using Puppeteer.

---

That is more work than what you think it is, and most definitively not a proper and sustainable solution.

I agree that maintaining a direct integration of native code into a browser compilation (or opposite direction) seems to have a very high maintenance cost in comparison to puppeteering.

Is it worth having that complexity in the name of essentially avoiding message passing like Electron and NW.js?

[abflow]

One just opened a discussion (#12970) about Deno as a wasm component for the browser (similar to StackBlitz's web container technology for node.js). This would allow offline-first backend applications and using the browser as a host for the user interface at the same time.