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?
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...
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.
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 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.
WASM you can bundle for Windows, macOS, Linux, Android, iOS and web. Unlike Deno Desktop, it doesn't rely on a browser engine.
https://docs.deno.com/runtime/desktop/comparison/ https://github.com/blackboardsh/electrobun#platform-support
Sounds like a similar architecture to Tauri, but your business logic is in typescript instead of rust.
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.
Also, we've had several developer framework startups get acquired -- Astro, Nuxt, UV, Bun, Vite. It doesn't exactly inspire confidence in a software that you want to last and give support for years.
You’re “backend” isn’t JavaScript.
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?
> Runtime permissions for desktop apps (a permission prompt on every filesystem / network access, i.e. Deno's permission system applied to desktop sandboxing).
A non-native UI has some issues, but also one clear advantage - it is easier to make a cross-system app with the same looks.
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.
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
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.
[0]: https://www.riotgames.com/en/news/architecture-league-client...
Chromium has so much stuff packed into it, its insane. All that utility comes with Electron. And that's a good thing.
If you ever worked with video, for example, you know that having the full power of a modern browser in a desktop app is a game changer. Video playback (not to mention transcoding, which is also possible with modern web and webcodecs) is a complex beast, implementing that yourself is massive undertaking, not to mention in a desktop app that is supposed to work on win/mac/lin. I've built apps with Electron in tens of hours that would otherwise take me tens of days or more (and thats with AI because I'm not a video expert).
I've always felt that native UI on Linux always looks incredibly ugly and I'd much rather use a nicely styled HTML+CSS layout instead.
In my experience, Electron mostly gets flak for being bloated and slow, it not being native is sometimes a secondary point people add on top.
I've always wanted to build a direct-browser integration that could use HTML+CSS for the layout, but avoids needing a JS runtime. Idk how lightweight servo is but one day I hope I will see my idea come to light
Like 25 years ago. Nobody gives a damn since Microsoft stopped giving a damn.
As a developer, I'm not sure what's the barrier for entry is apart from Rust then again it's the USP as well.
What you suggest is a disadvantage is one of the key advantages of Electron to me. I precisely do not want my things to look different on different OS. I don't have the resources to test my apps on all devices, and knowing that whatever I test on one system looks the same on another is A+.
Native UIs change all the time too and not always for the better.
For me, the leading reason to use Electron is the fact that I already have a browser running so why not just use that to render your webpage... Make it a PWA if you want it in its own window.
Is that a problem? A button with a legible label is a button. The host OS doesn't have to look exactly like the applications it runs.
> 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?
Cool project!
Sound more like Electrobun
The new client is some weird plugins/services based architecture. Things that'd barely warrant their own class in a boring OOP-based UI framework are instead now "isolated" services. The reality of this isolation being that if one piece breaks, the whole UI becomes unusable anyways. Dozens of things that in another app would've been just a simple synchronous call now behave like remote procedure calls and messages, forcing all the complexity of distributed systems into a local application for no reason.
That's why it runs like ass, breaks if you look at it wrong, and your CPU draws more power when using the client than when playing the game at 200FPS.
I would think/hope web developers are used to “just give me what you got”. Any other mindset leads to “you must install <browser> to see this site”.
It’s Electron devs that are used to that.
Since when? The browser landscape is much better today than 10 years ago, but no web dev worth their salt assumes anything about the user agent.
when it goes about using webapps as desktop apps, native PWA support should be used, it would - in theory at least - lessen most issues electron apps have but will need extra effort and that's why we can't have nice things (like RAM free for other tasks)
The problem, as you've pointed out, is that electron apps are bloated and slow. If they became the default and my editor, chat client, terminal, and everything else that I keep open were just thin layers around web applications, I'd rather figure out a way to move things into a browser rather than pull a piece of the browser out to wrap these applications.
Accessibility implementations frequently are more complex than the entire UI drawing bits. Most custom UI toolkits never implement accessibility, even decades after creation.
That hope is misplaced.
Seems like I'm part of a shrinking minority (in this thread at least) who believes that web[sites/apps] in a browser, and apps running on the host platform, are different things in terms of UX expectations.
How is it more reliable than Tauri - aren't they both using the system webview?
I see it in a different way. The fact that "web UI slop" has managed to make great inroads on the desktop is an indictment of the state of native toolkits. If you think it's a problem that desktop apps are being written with web toolkits, the solution for that isn't to shame (as the term "web UI slop" clearly tries to do), but rather to figure out how to improve the native toolkits.
The opportunity to improve those toolkits was always there, and the ball was dropped.
They beat Tauri at their CEF support.
Webviews are a mistake in most cases. They're too platform-specific, and certain Webviews (Safari/Webkit) are buggy as hell, making platform support a nightmare. (Linux, ironically, is even worse due to how underbaked webviews are on the major desktop Linuces - Tauri is barely functional on Linux.)
Deno Desktop could be a real contender in this space. It's good to see more Electron alternatives.
Bytecode Alliance do semi-regular streams on Youtube. I think reading (recent) material on WASI (0.3) and the Component Model would be a good start.
Understanding the relationship between a host and a guest is valuable. Learning what wasmtime is and how it works is also illuminating: https://docs.wasmtime.dev
That sounds like a monster I would be afraid to touch.
Here's the CEF docs on processes: https://chromiumembedded.github.io/cef/general_usage.html#pr...
EDIT: ...and the CEF docs on IPC: https://chromiumembedded.github.io/cef/general_usage.html#in...
I get what you're trying to say, but Chromium is far from being an OS. What you could say is, Chromium is as complex as an OS, or is replacing the OS in providing functional libraries atop devices (OS-provided application framework, if you will).
The other thing I find most Mac people appreciate is a shared understanding of hotkeys and if your app goes against the norm, one of the first feature requests will be to add configurable hotkey support.
Unfortunately, Apple has dropped the ball with their newest native apps in regards to UX and it will take years for them to go back and improve things. The new OS this fall is aiming to start that process, but it will still be a band-aid in some respect.
What DE? I'm on KDE.
This is a techie complaint, and that's opting for a charitably nice description.
Windows has like 4 frameworks available on a bare new, latest OS install, just go deep enough in the "settings" or whatever they call it, and you can reach down to winforms. And on top the start menu is a react element!
(And in Linux you have the gtk and the qt world, and everything else)
This upsets HN users but the rest of the world decided that apps looking like windows built ins doesn't matter.
I'm trying to argue that it should already be available via Firefox, Chromium, etc on desktop.
I don't need to spend 2GB-4GB of RAM just to have a over-glorified IRC clone!
Also, the native toolkits are fine. Windows has two toolkits, the ShellUI/MFC family (which does everything required, although it doesn't always get hidpi on legacy apps correct; it gets integration for blind people and also unicode/multilingual correct, and also works with touch interfaces), and WinUI does it more modernly (and ticks all the boxes). OSX has its toolkit, seems to nail everything correctly. Linux has Qt (lets ignore GTK for now, only reason you use GTK is if you want to appear Gnome-native), and Qt also does native++ uplifting on other toolkits (ie, native widget + additional feature expansion, plus perfect mimicry of native look for entirely new widgets), plus Qt does everything you need to do correctly and easily.
There are also new UI toolkits coming up through the ranks that are trying to knock Qt off that #1 position. None of the WebUIs would even place in this race.
Web UI toolkits always look non-native, are hard to interpret, often use low contrast (and frankly ugly) colorschemes, are easy to use in ways that do not comply with usability standards across OSes, and usually do nothing for A11Y.
The opportunity to improve those toolkits was always there, and the ball was dropped.
Yeah, hello desktop.
D:\source\DenoTest>deno desktop main.ts
error: Module not found "file:///D:/source/DenoTest/desktop".
The framework was reasonably good for its time. By the time good looking UI frameworks came, the bad reputation was already set.
Do they render different looking buttons?
Sorry, are you saying that two random web apps will typically share more UI consistency than two random Windows apps? Because, although I'm not currently familiar with Windows, I would be amazed if that were true.
Wait...
That doesn't say anything about the value of whatever UI kit is in place, being shared consistently by apps. A virtue that, apparent from this thread, is no longer universally shared.
> Includes an additional module or file/directory in the compiled executable.
deno desktop turns a Deno project (anything from a single TypeScript file to a Next.js app) into a self-contained desktop application. The output is a redistributable binary that bundles your code, the Deno runtime, and a web rendering engine into one bundle per platform.
Coming in Deno 2.9
deno desktop ships in Deno v2.9.0 and is not in a stable release yet. To try it now, run deno upgrade canary to install the canary build. The command, configuration keys, and TypeScript APIs may still change before the feature is stable.
deno desktop Jump to headingWeb technology is the most widely-known UI toolkit in the world. Desktop apps built on web stacks (Electron, Tauri, Electrobun) take advantage of that, but each has tradeoffs you have to live with: huge binaries, missing platform support, no JavaScript ecosystem, no built-in update story, no framework integration.
deno desktop is opinionated about those tradeoffs:
deno desktop at a Next.js, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start, or Vite SSR project and it runs: the production server in release mode, the dev server with hot reload under --hmr. No code changes are required to take an existing web project to the desktop.latest.json manifest and bsdiff patches; the runtime polls, applies, and rolls back automatically on failed launches.Create a one-file desktop app:
main.ts
Deno.serve(() =>
new Response("<h1>Hello, desktop</h1>", {
headers: { "content-type": "text/html" },
})
);
>_
deno desktop main.ts
The compiled binary opens a window pointed at a local HTTP server bound to your Deno.serve() handler. Run it directly:
>_
./main # macOS / Linux
.\main.exe # Windows
Deno.serve() automatically binds to the address the webview navigates to, so you do not need to pass a port or hostname. See HTTP serving for details.
desktop block in deno.json.Deno.serve() integration and the serving model.Deno.BrowserWindow lifecycle, multiple windows, events.bindings.<name>().prompt(), alert(), confirm() as native popups.Notification API.--hmr for framework and non-framework apps.Deno.autoUpdate(), manifests, bsdiff, rollback.deno desktop relates to Electron, Tauri, Electrobun, Dioxus.deno desktop CLI reference: the command, its flags, and the deno.json desktop schema.E.g. Tauri uses WebKitGTK on Linux, which has historically been slow, unstable, and frequently lagging behind the main WebKit project. This is enough of an issue that even Tauri is working on the ability to use CEF instead of the system web view in Tauri apps.
Things are generally fine on recent versions of Windows and macOS. The system web views on these platforms will be evergreen versions of WebKit or Blink. But if you want to support very old versions of Windows or macOS, you might choose to use CEF instead of wrestling with Safari-from-five-years-ago.
And, btw, the reason Microsoft even bothered is because (dun dun dunnnn) lots of internal apps at Microsoft were written with Qt, not MFC, and leadership got pissed when they realized (they couldn't tell the difference, since Qt does the native++ technique).
As for Linux, yeah, thats a shitshow. Qt was closed source, Linux isn't, so they made Gtk, but then Qt got open sourced, and then the Gtk guys just kept going. Qt can mimic Gtk3/4 themes and already uses 100% native rendering (same APIs Gtk does).
People keep writing Gtk apps for some reason, and I don't know why. I can get the C++ hate, but Qt has the cleanest C++ I've ever seen.
So I hoped we could have a <= 20 MB solution by reusing the OS webview or similar. Having more than 400 MB is a bit deceptive for me. (Again: maybe I just did something wrong in the config: should I do something else than `deno desktop test.ts`?)
That's Sciter (https://sciter.com) and Sciter.Quark (https://quark.sciter.com) in particular, no?
The web is probably the closest thing the software industry has to a truly universal, open application platform. There is corporate influence, but it is substantially more vendor-neutral than any other UI platforms.
The web stuff mostly uses licenses such as MIT, Apache 2.0, and BSD. GPL-licensed projects exist, but still many more on permissive side.
Web is based on open standards developed through organizations and specifications are publicly available, royalty-free, and implemented by multiple independent browser engines rather than being owned by a single corporation.
Hi! I'm trying my best okay? Hokusai Pocket might currently be composed of wood and string, but one day he will be a real boy!
Worth noting is that the team has improved compilation features steadily. Every issue I watched last year has been completed and I’m not encountering blockers anymore.
deno desktop ships in Deno v2.9.0 and is not in a stable release yet. To try it now, run deno upgrade canary to install the canary build. The command, configuration keys, and TypeScript APIs may still change before the feature is stable.As a minor bonus, the live-reload is also faster than what frameworks like React do. It truly has subsecond latency, which isn't exactly a game changer but is nice when iterating on visual details of an app.
Some speculate that agentic engineering will enable the return of native apps
Sciter SDK [1] contains scapp[.exe] - standalone Sciter engine that can be attached to HTML/CSS/JS bundle making standalone (single exe file) and portable executable. https://quark.sciter.com/ tool allows to compile such apps.
Size of "hello world" is a size of scapp.exe binary + size of compressed HTML/CSS/JS bundle.
On Windows scapp.exe is of ~14 Mb. On Linux ~18 Mb.
Linux version at startup detects GTK4, Wayland or X11 and uses those as windowing backends.
On all platforms Sciter provides out of the box: HTML/CSS/JS runtime, libuv based Node.JS alike runtime, GPU accelerated rendering, WebGL 3D runtime, JS built-in persistence (NoSQL DB).
It does not have TS compiler built-in as Deno, but that TS-to-JS compiler is better to be outside anyway as it is used only once - at app loading.
Now you can just start a server with deno pretty easily and serve a website. But WebUI will actually also manage opening the browser window for you as well a make the communication between backend and frontend just like using a Webview or electron.
For 8 years now, constantly updating to newest Electron, my Electron app has been using only about 150mb of RAM - (see Video Hub App)
https://docs.deno.com/runtime/desktop/backends/#webview-(def...