Proposal: WebView API #18042
Replies: 6 comments
-
Unfortunately, there is no way to monetize desktop apps! |
Beta Was this translation helpful? Give feedback.
-
This is an interesting proposal. You may already be aware of them, but at the language level, I noticed that there are similar initiatives too, which are already working projects, based on webview: Go: Rust: |
Beta Was this translation helpful? Give feedback.
-
Webview desktop apps are interesting, but it seems to one that a better way to distribute desktop applications based on web technologies would rather be to have a browser PWA which would acquire a capability to launch a Deno process locally based on user permission. |
Beta Was this translation helpful? Give feedback.
-
Nevertheless, another option, besides Wry, would be to load a native addon for webview built for nodejs with the Node-API. |
Beta Was this translation helpful? Give feedback.
-
interesting proposal |
Beta Was this translation helpful? Give feedback.
-
interesting |
Beta Was this translation helpful? Give feedback.
-
WebView API
This is a proposal from the discussion #3234.
It aims to provide an API to start WebView windows from deno, resulting in a similar experience as Electron.
The main benefit of such a feature would be to write desktop applications.
This can expand the use of Deno from CLI tools and servers.
Just how Electron expanded the use of node.js to desktop applications.
Electron currently has problems loading ESM modules, which don't seem to be receiving active development. This is an opportunity for Deno to step in and improve on Electrons approach.
When Electron was launched there was no alternative but to include it's own browser, chromium. Now there is WebView, which uses a browser that is already installed. This greatly reduces the impact on binary size.
Another tempting feature that can be added is TS support. Just like Deno supports TS out of the box on the backend, so can the frontend.
Usage
Starting a new window is one line:
Passing information can be as simple as this:
And on the frontend:
Architecture
The diagram above shows the basic flow of the API.
Function names are of course up for debate, this is just to show the functionality.
The following subsections will explain each step.
Initialization
When a Window is opened and there is no WebView process running a new one is started.
Requests are intercepted in the webviews process, see security section.
Any local requests are send to the main process, where it loads the file and sends back the contents.
Typescript
Intercepting requests makes it possible to transpiles TS files on the fly before it reaches the browser. By transpiling and changing the
content-type
tojs
it will add support for TS. Thedeno_emit
crate can be used for this functionality.Multi Window
When the WebView process is already running, it can be reused for any new windows created.
It is not necessary to start a process for each window.
IPC
There needs to be some form of communication between webview and deno, otherwise it would just show a static website. The simplest way would probably be to only allow string messages, sharing objects is not really possible when they run in sepparate processes.
See why running on a separate process is needed in the Q&A section
Closing Windows
Once the window was closed by the user an event is send to deno. If there are no more windows open, webview sends another event and stops.
Security
Security becomes a concern when we give WebView access to deno through IPC.
In and of itself it is not an issue, but if the developer links IPC messages to reading/writing files then external scripts could also access them.
My proposal would be to only allow local resources to be loaded by default.
That way no external javascript can get access to the IPC channel.
Putting full access behind a permissions flag, like
--allow-webview-external
.Crossplatform support
All platforms that Deno currently supports also support WebView.
While they each have their own library, there exist crates that support them all.
WRY is an example.
Interprocess communication is another hurdle which all platforms have their own way to solve.
But again there are crates that put them all under one API, like interprocess.
Q&A
Why run WebView in a new process?
You can run WebView on another thread as well, but this is not supported by MacOS.
So to make it work on MacOS, Deno would need to be run off the main thread.
While that may be possible it would need a flag before starting the runtime or somehow switch deno to another thread when
new Window()
is called.Which is not ideal/possible.
How would the WebView binary be distributed?
The are two options:
My preference would be for the second option, as the binary won't be that large (just ~2MB) and allows for portable offline applications.
Why include it in Deno, can't this be a third party library?
Maybe.
Some things might be easier/better if natively supported, like direct access to
deno_emit
and IPC throughinterprocess
.Portability is also difficult with a library, as it would need to include the webview binary. While this can probably be done, the developer experience won't be good.
This would also require any application to have the
--allow-run
permission, which is not ideal.Apart from technical reasons, there has been a lot of interest into a standard GUI, see #3234.
Natively supporting such a feature could be a good selling point for Deno.
Won't this be a lot of work?
Luckily there are some great crates that can help the process, WRY for webview and interprocess.
Other libraries with similar functionality can also be used, these seemed the most common.
The following things are required:
Deno.send(string)
andDeno.onMessage(callback)
local_socket
(cross platform)Deno.webview.create(config)
Deno.webview.send(string)
Deno.webview.onMessage(callback)
Deno.webview.onClose(callback)
Deno.webview.onExit(callback)
These are a few things that are nice to haves:
--asset
flag to compile #17994--no-terminal
to compile command #17991Beta Was this translation helpful? Give feedback.
All reactions