Has there been any discussion about having a standard way of doing GUI in Deno? I don't necessarily mean that it all has to be in the core or std modules, and I don't mean anything complicated or very high-level, just something that lets us open native windows, show dialogs and generally create GUI apps using just JS/TS.
In issue #1629 about WebGL from January (the only issue related to GUI that I've found) @ry you said that you want to support WebGL in core eventually. If it is possible to open a native window and draw using WebGL then it will be possible to use it to create a GUI framework as a third party module, but thinking about it I started wondering about a Web way to do GUIs, which is really HTML. I'm not arguing that it is the best way but this is certainly the most Web-style way. And since one of the goals of Deno is to have a similar API for the things that people are used to in browsers, then it seems like something worth thinking about.
If Deno doesn't use a Web way of creating GUIs then soon it will have to reinvent HTML and CSS, plus some logic of dispatching the click events etc. and it will soon get quite complicated.
If, on the other hand, Deno is able to open a window with HTML even with very limited functionality (like only text and canvas, for example), then it will be relatively easier to not go too far away from what people are used to in the browsers.
Of course having something like Electron bundled in Deno might be a little overkill (or maybe not? any thoughts on that?), but having a possibility to write an Electron-like framework as a third-party module without producing a separate Deno binary to be able to do that, would be something to think about.
Running deno run https://www.example.com/gui-example.ts
to start a GUI program, instead of deno-electron-like-fork run https://www.example.com/gui-example.ts
would be something to consider.
I wonder if there has already been any discussion about it.
@ry and I recently talked about it, and we presented the intent at TSConf, but there was no issue for it. There was some conversation on Gitter recently as well.
An Electron-ish thing built with Deno would be a big deal to me. I'd put a lot of effort into switching my apps to it, since the security improvements alone would be quite substantial. I suspect the resource efficiency would be much better, too, if Deno's startup time is anything to go by.
@kitsonk Thanks, I didn't know about it. Having a full-blown browser bundled would be something absolutely perfect, if only the overhead is not prohibitively expensive - but since you are already considering it with Ryan then I guess that happily it isn't.
Will what you were presenting with Ryan at TSConf about this be available online to watch? Or maybe it is already?
It would be great if Servo could be used here. The tight coupling with SpiderMonkey seems like a problem, unless it would be used just as a completely separated frontend and communicate with the main Deno process with a WebSocket or something like that, maybe having Deno transpiling the frontend code from TS to JS on the fly.
It is actually pretty interesting how it could be done - from GUI windows being just lightweight browsers, getting all assets via some proxy or file protocol and communicating via WebSockets with the Deno process, to having some duality like Electron, to having a browser part using the same engine or even the same process and event loop as the main Deno code. I wonder what is your and @ry's idea of what would be optimal here.
@sholladay Yeah, I am currently writing an app that needs a GUI which I am doing it in Electron but it is something that could be written in Deno with the current API with no problems if I could only do GUI with Deno (and unfortunately it cannot be a web app). I am concerned exactly with security of what I am doing right now, that the app will have full access to user's data, which could be nicely restricted with Deno. Not to mention the transpilation steps etc.
Having a built-in module which bundles a cross-platform webview implementation would be the killer-feature that would get me to start experimenting/migrating from node.js.
I have some basic feature requests. Few native dialogs. Alert, prompt, confirm and file/folder picker/save dialogs. Because sometimes you have app running in the background it will throw an error but user can't notice it so you have to show some dialog about what is going on and in Node.js there is no easy way to do that.
Ya鈥檒l should have a chat with @nothingismagick and the other fine folks at Tauri: https://github.com/tauri-apps/tauri/
A lot of what has been described here, they鈥檙e already working on or have already thought a great deal about.
@erlend-sh Are you sure this project is alive? The tauri.studio domain (from github.com/tauri-apps/tauri.studio) redirects to a domain parking page and on tauri-apps.org (the documentation link in the readme of github.com/tauri-apps/tauri) I get ERR_CONNECTION_TIMED_OUT:
This site can鈥檛 be reached tauri-apps.org took too long to respond.
Yes - its alive. We're preparing our site to launch this month.
@rsp - we've had so many moving parts that we couldn't justify publishing the docs about how to use tauri until we've got a stabilized API and build system. Feel free to drop by our discord server if you want some quick support about getting setup with it.
On a sidenote, we do plan to release a deno CLI and rust integration once deno is stable enough for that too.
@nothingismagick Thanks for the info. The project after reading the readme looks almost too good to be true. Really looking forward to reading the docs when they are available. It's great to hear that you plan releasing a Deno CLI as well.
yeah - we just a comment from a svelte user today. they confirmed a final linux build size of ca 600KB.
But I know we can break the 500KB boundary for sure. Here's the discord if you want to stop in and have a chat:
https://discord.gg/SpmNs4S
It would be great if we remembered that this is a Deno issue tracker. :smile:
I would very much like to port my desktop environment to Deno, watching.
Here is another idea for building GUI.
Call Chrome with Chrome DevTools Protocol
Build a GUI based on Chrome
This should be widely available
After all, most people's computers have Chromium kernel browsers. Including Chromium Edge
/Chrome
There are already real cases here
Node.js implement: https://github.com/GoogleChromeLabs/carlo/
Golang implement: https://github.com/zserge/lorca
I think this is a way to build a GUI application with lowest cost.
I'm working on http://github.com/maxharris9/layout, and I'd like to port it to Deno. Layout currently runs in browsers and on node-canvas.
+1
Here is another idea for building GUI.
Call Chrome with Chrome DevTools Protocol
...
Node.js implement: https://github.com/GoogleChromeLabs/carlo/
Golang implement: https://github.com/zserge/lorcaI think this is a way to build a GUI application with lowest cost.
Why is this so frowned upon? This would mean super small package sizes when bundled and it would also be easier to build rather than a full rendering engine etc, unlike Electron apps? I second this idea!
Especially since future Windows versions ship with a Chromium distribution (Chromium Edge) by default
Not everyone has a chromium browser. I think Webview is the right way to go
Indeed, chromium is a no go for FLOSS in some situations (e.g. you will not be able to ship Chromium based apps on the PureOS app store).
Not everyone has a chromium browser. I think Webview is the right way to go
On Windows systems that don't have the Edge Browser, like Windows 7, which is still pretty common, Webview uses MSHTML/Internet Explorer, which is a pretty big nope
chromium is a no go for FLOSS in some situations
I would say that a minority as such could just not have supported. It's not an necessity to support every single platform - I'd rather have a Deno base framework replacement for Electron and support windows and mac exclusively. Electron's primary demographic so to speak is Windows and Mac devices and they don't plan to support minority OS's.
TLDR, I can't see how not supporting OS's used by very few people (when the primary audience would be Windows and Mac) would be a problem
On Windows systems that don't have the Edge Browser, like Windows 7 which is still pretty common
Windows 7 is EOL since 14th January. Microsoft is not supporting it, there is no reason for third parties to do so.
Windows 7 is EOL since 14th January. Microsoft is not supporting it, there is no reason for third parties to do so.
When you're writing commercial software you can't just not support an operating system just because it isn't supported anymore, as long as its userbase is big enough you have to support it.
At https://github.com/tauri-apps we are building the new official rust bindings to https://github.com/zserge/webview - Zserge's work will become the source headers for a pantheon of bindings projects to webviews, such as potentially https://github.com/eliassjogreen/deno_webview
Although tauri at the moment is focussing on rust, we anticipate making our rust-based builder and API available to other bindings, like deno - and have in fact started work on making a deno based CLI. (Which was paused because deno was missing a lot of stuff we needed.)
If you want to stop over and have a chat you can find the semi-official webview channel here:
https://discord.gg/KHmTZdH
(Semi official, only because at tauri we're hosting it until the webview org proper gets kickstarted).
Isn't WebView using WebKit on Linux and isn't WebKit that Browser that refuses to implement WebGL2 for over 3 years?
Tauri has been working on new bindings to make it so the backing engine can be replaced. We have a "maybe in the future" goal of trying to bundle Servo, as an alternative for portability.
More directly responding, there aren't any good OSS alternatives to WebkitGTK for Linux. Qt is the only real alternative, but Qt has its licensing concerns.
Basic set of dialog boxes in scripting languages can be used with https://en.wikipedia.org/wiki/Zenity
I have some basic feature requests. Few native dialogs. Alert, prompt, confirm and file/folder picker/save dialogs. Because sometimes you have app running in the background it will throw an error but user can't notice it so you have to show some dialog about what is going on and in Node.js there is no easy way to do that.
@jardicc you can already do alerts with https://github.com/divy-work/autopilot-deno, but there's no way to determine which button (close or confirm) was used, yet. Author is still working on it, and it will probably have more info soon (hopefully)
The status here is that there are both technical and non-technical reasons why integrating deno as the JS runtime in Electron instead of node is not possible or wanted at this time.
https://github.com/electron/electron/issues/23613
This conversation has been locked as resolved...
Integrate Deno in Electron is a dream.
Keep Node in Electron would be a nightmare.
The status here is that there are both technical and non-technical reasons why integrating deno as the JS runtime in Electron instead of node is not possible or wanted at this time.
electron/electron#23613
_This conversation has been locked as resolved..._Integrate Deno in Electron is a dream.
Keep Node in Electron would be a nightmare.
It鈥檚 been almost 5 years since esm was released, and electron is still not supported
Most helpful comment
Having a built-in module which bundles a cross-platform webview implementation would be the killer-feature that would get me to start experimenting/migrating from node.js.