This[0] sounds interesting. I am not familiar with CEF, so I wonder how the versioning works. When different apps require different versions of CEF, do we just essentially end up with the electron model where every app bundles their own browser (just slightly less bad). Or is there still an advantage to a "shared runtime" in that case?

[0]: https://docs.deno.com/runtime/desktop/comparison/

The CLI reference page[0] notes,

> The permissions you grant at compile time are baked into the compiled binary:

I think it would be nice if this could be surfaced to the user somehow, like letting the user know and decide which permissions they want to give access to.

[0]: https://docs.deno.com/runtime/reference/cli/desktop/#runtime...

* https://docs.deno.com/runtime/desktop/backends/

With that said, this is going to eat a lot of Tauri market. Why would I use Tauri now? The 150mb of additional bundle size is just an extra 1 to 10 seconds of download time in most internet connections and you get a reliable rendering engine.

I don't understand how the coordinated process group works. Doesn't that mean in this multi-process mode it must be IPC? Maybe the claim "shared memory space" is more an architectural description than an OS-level claim?

Poor choice of words there IMHO.

The reason Electron apps get a lot of flak is because they are everything _but_ a UI toolkit. They consistently miss the mark in adopting UI patterns from their host OS.

Web tech is just web tech. Yes it will allow you to render a button, but even unstyled, the button won't necessarily look native to the OS, and will vary between browsers.

I find the feature matrix comparison to be extremely well done and the sections beneath explaining advantages and disadvantages to be some of the best docs I've read recently.

https://docs.deno.com/runtime/desktop/comparison/

https://docs.deno.com/runtime/desktop/comparison/ https://github.com/blackboardsh/electrobun#platform-support

- We can embed an existing application using a sidecar [1].

- Now, we can also use Elixir in the backend, embed the BEAM, and deliver a single binary, see ElixirKit [2].

As far as I know, LiveBook Desktop [3] is using Tauri for building binaries for MacOS and Windows. If Tauri works for the Elixir team, I think it works for me too.

Also, I know that Tauri is not bullet proof. WebView can be limited for some use cases, see [4]. There is some effort to use CEF to mitigate those problems, though [5].

I'd like to know how Deno Desktop compares with Tauri in this context. I know it is a new product, not sure if we could bundle an existing binary in Deno Desktop, like in ElixirKit.

[1] https://v2.tauri.app/develop/sidecar/

[2] https://elixirkit.hexdocs.pm/tauri.html

[3] https://github.com/livebook-dev/livebook/blob/main/rel/app/t...

[4] https://www.youtube.com/watch?v=vmslGvxObvM&t=621s

[5] https://github.com/orgs/tauri-apps/discussions/8524

WASM you can bundle for Windows, macOS, Linux, Android, iOS and web. Unlike Deno Desktop, it doesn't rely on a browser engine.

You can get your app sizes as low as 15mb with `deno desktop --compress` (in canary)

A tiny "raw" windowing backend exists for WebGPU rendering as well

I tried out the most basic possible example, from the linked page:

    Deno.serve(() => new Response("<h1>Hello, desktop</h1>", { headers: { "content-type": "text/html" }, }) );

There's a downside though... that "Hello, desktop" app weight in at 308MB on macOS.

Now, I don't know how that compares to an electron app, or the most lightweight app possible handcrafted specifically for macOS, and there are many, many layers of abstraction between my 1 line of code and the resultant but that is enormous!

I wonder if it supports opening invisible browser windows and doing things like intercepting cookies. In my desktop application I leverage a hidden browser window to manage auth state and use it like a proxy for the rest of the application. Might try to port it to deno desktop.

Sounds like a similar architecture to Tauri, but your business logic is in typescript instead of rust.

[0]: https://v2.tauri.app/develop/sidecar/

Smart move from the Deno team to get me to try out their ecosystem. I probably wouldn't have bothered prior. I've been mostly fine with npm, as its been much faster of late, and the security features recently released are good.

Yeah, hello desktop.

D:\source\DenoTest>deno desktop main.ts

error: Module not found "file:///D:/source/DenoTest/desktop".

> Small by default, full Node compatibility

I tried `deno desktop index.ts` with the 5-line Hello world in the article.

Result (Windows 10): 442 MB. Ouch.

I thought it would be smaller than an Electron build, but it's far worse. Did I do something wrong?

(libcef.dll: 247 MB) (deno-test.dll: 78 MB <- contains the hello world)

Are they running the frontend and backend in the same process? Sounds a bit dangerous security-wise?

The world is trying to make computers faster and more accessible, more web UI slop isn't going to help that. Dumping Javascript entirely is the first step on that road.