Discussion summary
Deno Desktop is a new application that uses web technologies, sparking debate about web UI bloat and native app performance.
What the discussion says
- Some users criticize it for adding to web UI bloat and not offering significant advantages.
- Others see it as a competitor to Electron and a way to build cross-platform apps.
- There is a discussion about native UI versus web-based UI and performance considerations.
“Another Chrome wrapper...”
“Web UI slop isn't helping make computers faster.”
Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- > Web technology is the most widely-known UI toolkit in the world.
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.
by jorisw - > Bindings are not IPC. The Deno runtime and the rendering backend run as threads / processes inside the same address space (CEF) or coordinated process group (WebView). Calls go through in-process channels, and the backend dispatches them from its run loop. -- https://docs.deno.com/runtime/desktop/bindings/
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?
by qudat - I'm happy to see this I see that this provides CEF, Webview and Raw * backbends but it would be nice if there was also a launch in browser option (like WebUI has). To me that has the best tradeoffs if you want to avoid the mess that is webkitgtk but still not ship (and be in charge of updating) a chromium engine with your app.by bobajeff
- I'm happy for competition in this space, specially because Deno can run true TypeScript directly and not just strip types like the current Node implementation.
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.
by bel8 - This is a smart thing to ship. For me it would totally be a consideration when deciding on a platform to use.by solarkraft
- Deno continues to impress me. It’s honestly been quite a while since I started a new project without it. It has fully won my support over Node.js, the ecosystem has really matured nicely. I don’t know how often I’ll use this feature, but it’s really nice to have the option!by 40four
- I was wondering how this integrates with Deno's permission system, which is one of its biggest strengths especially for letting agents run amok on your device.
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...
by sheept - > Shared CEF runtime across apps. Every app currently bundles its own CEF copy. A managed shared runtime would drop binary sizes to a few MB per app. On the roadmap.
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?
by leleat