> 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?
The biggest weakness of a framework like Tauri is the choice to target system webviews instead of bundling a browser runtime.
It seems great to be able to cut hundreds of megabytes out of your app installer, but the platform differences wind up being a complete and ongoing pain in the ass.
Tauri support on Windows is phenomenal.
Tauri on Mac runs into lots of WebKit/Safari issues, especially on older Mac machines that have an older engine that doesn't support modern web APIs. Your app can crash or be left non-functional. You'll find out about these runtime bugs in the wild randomly, and patching for some customers can take days, if not weeks.
Linux support is hellish, and it's best to not even try targeting Linux with Tauri.
Tauri is in the process of adding CEF support. It should probably become the default build target for all platforms.
> Because we can’t differentiate between a legitimate sign in and a MITM attack on these platforms, we will be blocking sign-ins from embedded browser frameworks starting in June
Granted this was years ago, maybe the situation improved? I had to abandon my CEF project because of this.
Most apps (on desktop or mobile) open third party auth flows inside the user's default browser, which makes this a non-issue. For one, if you embed the Google login flow into your app then I can't reuse my existing session in my browser. But it also exposes my full credentials to your app for no reason, which is a good thing to avoid.
Just to let you know, CEF was used for Riot and League of Legends client as well [0]. The results haven't been nice, but I'm not aware if this was a problem with the CEF technology itself or other component/processes are to be blamed.
When the new client was built, microservices were the hot new buzzword.
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.
Both Steam and Battle.net use CEF for their UI as well. And IMO they are on 2 ends of the "nice to use" from the implementation side (Steam being a sluggish hell and B.net being nice). Though then again B.net is only for Blizzard games, so they can also optimise for the limited set games.
This is more a function of how mismanaged the project was at Riot (the iron client days, choosing Ember, etc.) which led to the current state of the launcher.
I regularly install and uninstall the league client on Mac based on how I play that game (require fresh installs to raise the playing cost) and their client really sucks. Even freshly installing it, the client inhibits and hijacks mouse clicks from the full screen game when it's open. It took me months to figure out I would have to minimize the game, open and minimize the client (separate app) open, and then clicks would sometimes properly return.
Before that I was closing both and playing a game of roulette. By the the time my game was working, I may have already been reported for being afk and the game ended. Edit: other bugs have included starting to download the game and then signing in afterwards (their UI doesn't stop you) and then download progress disappearing, perhaps hanging, and you having no way to know it for a 40gb file unless over an hour has passed and you check disk size and then realize the client doesn't know how to load it. Start over and do a fresh install again, clear cache etc because their cache of the client still thinks somethings being downloaded even though it's not. Also having chat permanently off, results in weird glitches with friends requests and being unable to add new friends.
Horrible experience. But since the game is so optimized for addiction and dark patterns these days, and sunk cost, its a game I find myself returning to every once in a while.
I doubt the benefit. Practically every Electron app on a desktop uses different versions of Chromium and many are very out of date because of the risk of breaking when upgrading.
People build web apps for an array of browsers and huge ranges of versions. I think if you started using some tech to deploy an end user program and knew from the beginning the browser could be updated beneath you it would work just fine. But if you start with a golden version of Chrome and put off updating for too long you’ve let yourself get too comfortable.
True for this decade, but in the previous decade it was very much the opposite. Before you used any kind of browser api or nice language feature you would feature-detect it:
if (typeof Array.prototype.includes === ‘undefined’) { …
And if it wasn’t there you would define it yourself, it was called “polyfilling”. This was so commonplace that we built significant tooling like babel to standardize feature detection tests and fallback implementations - for a few years you could write
request.then(response => response.json())
And behind the scenes the Rube Goldberg machine would turn this into something that would run in a JavaScript environment that had neither arrow functions nor promises.
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.
You are running a binary that you got from the developer. If it presented you with Deno permissions, I think that would be misleading because there’s no guarantee of their integrity.
That is true. I wonder if it could be possible to let the user supply and wrap the app around their own, trusted installation of Deno (rather than the one bundled in the app) to specify permissions.
> Runtime permissions for desktop apps (a permission prompt on every filesystem / network access, i.e. Deno's permission system applied to desktop sandboxing).
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.
Wouldn't that just be "Raw"? I.e. start a webserver and ask the system to open the URL. There is no "special stuff" to do in this case like avoid sockets in favor of IPC to a well known webview or package CEF and no real integration to make with dev tools etc after - it's just open socket and serve from prebuilt binary.
No. As I understand it, the Raw backed just gives you a Window with input handling and you have to embed something like Skia, WebGPU for the graphics. So basically you have make your widget library yourself.
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.
> I'm happy to see this I see that this provides CEF, Webview and Raw
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.
I think that my Sciter is better option when you need HTML/CSS/JS native application running on
Windows (XP and beyond), MacOS and Linuxes.
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.
This is something that can bring me back to Deno. Binary size is still pretty big IMO. If they can trim down runtime based on the specific uses of standard library (sort of treeshake Deno runtime itself), it would be revolutionary. Java promised this with `jlink` but sadly failed to deliver for wider adoption.
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!
The overall feature seems really solid, but I'm impressed they couldn't reduce the average package size further from 40MB even when not using CEF. I guess that wasn't a huge focus when developing this feature? Tauri and Dioxus can easily hit less than 5MB for package sizes.
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.
Deno Desktop is bundling the V8 JavaScript runtime so it can have JavaScript on the backend. Tauri uses rust for the backend and your browser's JavaScript engine for the frontend.
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.
>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.
this is misleading. there is no "running true ts". you will always be running pure js (until someone actually develops a "true" ts engine), and deno does "type stripping" just the same. the only difference is that it bundles the tools and makes it transparent and config-free which is more convenient (although more rigid).
The same set of reasons anyone made desktop apps before Deno desktop launched. Deno desktop is not the reason desktop apps are made. If someone really wanted a desktop app made before, deno desktop isn't going to suddenly make new ones start appearing. It will just be a new choice among the many.
Tauri doesn't lock you in to one JS ecosystem. In fact, it doesn't require you to use javascript at all.
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.
Deno also just strips the type annotations when running TS code - at least by default. To get type checking you'll need to run via `deno run --check`, or use the separate `deno check` subcommand. No big deal since type checking and linting usually happens automatically in the IDE during development.
> Deno can run true TypeScript directly and not just strip types
What exactly do you mean by that? Because no js engine carries the ts types into the runtime as far as I know. Deno and nodejs both use v8 as the runtime. v8's internal types are not connected at all to the ts types regardless of the wrapper. The only difference might be when/if static type checking is performed.
Temporarily at a place with 10-15 mbps. 150 MB is around 1 minute.
I grew up on 30 mbps. >= 100 is all I need nowadays.
But 10 mbps and websites and downloads really start to take a while.
The more bits and bytes you save, the more people will be pleased with your stuff! Even if they don’t know what bits and bytes are, and just go based on impatience
> 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?
My guess is that it's not using IPC on OS level, like D-Bus on Linux, but rather a supervisior process starts and orchestrates child processes as needed. And all these processes use a shared memory model.
> 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.
That is not why people use Electron. The goal is not and never was to just be a "UI toolkit" and "adopting UI patterns from their host OS".
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).
chromium is basically operating system at this point, it lacks kernel and ability to boot independently (added in chromium os), which is both good (from abilities standpoint) and bad (when copy of chromium is bundled with every app that renders webform with text field and button and nothing else)
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)
How is it a poor choice of words? It might not be "native" UI, but they never claimed as such.
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
I don't mind the idea of using HTML components and widgets to style desktop applications. CSS and the DOM are widely known and reusing those for desktop apps is probably a good idea.
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.
> 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
Blitz (https://github.com/DioxusLabs/blitz) is exactly that. It's a new custom browser engine supporting standard HTML/CSS with a native Rust API (and optional integration with Dioxus which is a React-like UI framework in Rust). Baseline binary sizes are around 10mb.
We share a few components with Servo (Stylo the CSS engine (also shared with Firefox), and html5ever the HTML parser), but we've built a bunch ourselves too: notably we have our own layout engine, DOM tree and event handling. Servo is unfortunately tightly coupled with SpiderMonkey, and there is little prospect of removing that dependency in the short term.
Every time I use Zed across Linux, macOS and Windows , I'm amazed stable and performant it's GPUI framework is. As a user, I'm very happy with it; of course some basic features like accessibility is missing but I'm sure it will be implemented soon.
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.
For me it's not stable. After they change their renderer from one to another it freezes for me from time to time. But on the other hand I'm running Nvidia on Wayland so I feel no hate towards Zed owners - and restart is super quick ;)
> basic features like accessibility is missing but I'm sure it will be implemented soon.
Accessibility implementations frequently are more complex than the entire UI drawing bits. Most custom UI toolkits never implement accessibility, even decades after creation.
> They consistently miss the mark in adopting UI patterns from their host OS.
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+.
I understand historical usage of the term with regards to desktop, but im unsure how you could consider HTML, CSS, JS, and runtime as anything other than a UI toolkit. They control the layout, styling, and actions of a UI.
Even in a "post-vibe code" era I wouldn't want to create multiple versions of the same app, and none of the "platform-native" GUI toolkits run on everything.
SwiftUI is apple-only, gtk has pretty bad compatibility on non-linux, qt is decent but requires C++ or python, and even so still not much for mobile. Don't even get started on "Windows frameworks", because as I write this sentence they may have left a new one in the ditch.
Flutter may be the closest, but why didn't they go with e.g. Java instead of a new language?
So yeah, if you want a truly universal UI then web is your best bet.
I never thought I'd defend Electron, but I'd rather use the bloated web UI than a vibe coded Qt/GTK version I'm positive will not have seen any human QA.
I have better things to do than spend my time adopting UI for various different systems. If Electron gives me the option to easily create a UI that looks the same everywhere, then I'll pick Electron over anything else any day.
At this point the only OS with a consistent look and feel at all is Mac. For the other OSes, I don't even know what a "native" look and feel would be. And most apps have their own branding and style they want to tout anyway. So I don't think "apps should look native" is the leading reason to not use Electron.
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.
> At this point the only OS with a consistent look and feel at all is Mac.
Apparently, NOT! Apple's controversial Liquid Glass UI disrupted their long-standing Human Interface Guidelines by prioritizing cinematic aesthetics (transparency, refractions, and blur) over core tenets like readability, contrast, and content deference. Critics highlight that transparent, light-bending panes frequently clash with underlying wallpapers or videos, causing text and buttons to become illegible. This is a HOT topic in recent WWDCs and amongst UI designers.[1]
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.
I change clothes all the time too, still match the pieces of clothing each time.
There's aesthetic value to coherence. There's also design, usability value. I have Telegram, Steam and Firefox opened right now and each one of them displays different minimize/maximize/close buttons on the top right. That's not ideal.
I genuinely wonder who ever want that, and what apps those people use on their PC. Can you imagine, for example, Blender Foundation says that their next goal is to make Blender's UI look more like the host OS?
I have used Blender just a bit, but it was very jarring when I first opened it and discovered that it has its own menu bar within the window, rather than at the top of the screen. It has its own save/open window rather than using the system-provided one, as nearly all truly native Mac apps do. I doubt most Mac users like this.
I have somewhat more experience with QGIS. It has a standard Mac menu bar, but the icons are inelegant and Windows-ish, window layouts are Windows-ish, dialogs don't behave correctly in Mac full screen mode. It could use a MacOS glow-up.
I think Visual Studio Code (native menu bar, native save/open, but a core UI kind of unto itself that is consistent across Mac and Windows) does a better job of balancing cross-platform vs native.
And then there's the approach taken by Adobe and Microsoft Office. These apps do a much better job of adopting native platform appearance and conventions (sometimes at the expense of application consistency across platforms).
> 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.
Tauri is a good way of packaging offline PWAs. It kind of sucks for building proper applications. The entire model for integrating with a local backend is just bonkers (no, I don't want my local application to pretend to be a web server - it's not a web server, I want to give you actual host bindings and share memory).
Since when did anyone ever complain that youtube, google maps, roblox, or any other web sites didn't have native buttons and UI patterns?
Are you implying that the Windows, Mac, and Linux native desktop user interfaces don't all totally suck??! Or that there wasn't a huge celebration when Alan Dye finally left Apple for Meta? Or that users are clamoring for Jony Ive's infamous shallow superficial visual elegance over affordance and discoverability and usability?
Is it just too confusing for people to use youtube because the buttons don't look and feel exactly like native Mac buttons on the Mac and native Windows buttons on the Windows and whatever the kids are using on Linux desktops these days, therefore nobody uses youtube, and that it will only ever get popular if it just had a native look and feel?
Basically you're saying websites are the same as apps, and whether they're used in the browser or as a desktop app, the UI is fine to ditch that of the OS. Fine if you think so. I'll be sad to see OS and apps diverge completely in terms of UI.
YouTube succeeds for its content. Its UI is hot garbage both in the web and their apps. Google Maps is an atrocity and I’m very thankful Apple has decent data where I live. Roblox I don’t know, other websites I consume mostly in Reader mode.
This. It's nuts how the whole industry accepts that typesetting engine from 80s with bunch of hacks on top is currently dominating cross-platform UI development.
I think the last time I tried Deno for desktop it didn't allow for fullscreen webview apps. that was a showstopper for our kiosk apps. I'll have to revisit that issue and see if it's resolved now. I'm glad to see Deno continuing to march on.
You may have played with a 3rd party/unofficial solution or similar in the past as Deno Desktop has only just now become available in the Canary branch.
It's all so bleeding edge right now. It also depends how deep you want to go. An increasing number of languages support wasm as a compile target, which is helpful.
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
Any indication when v2.9.0 will be released? I'd love to play with this, but the install instructions (at least for linux) don't seem to work. Is it working in Windowsland or on macOS?
This ship has long, long sailed. If you don't spend your all your 24 hours as an office worker using Microsoft software, or you're locked in with a PC from 30 years ago, chances are almost every single UI you use will look differently, besides some microscopic agreements, like back button or a burger menu.
We just got used to it. There is some very vague thin layer of "commonly accepted patterns and symbols", but otherwise users just get through it.
Isn't all uses native OS UI widget? But since the brand need to be experienced the same across platform, it overrides the native rendering and use custom styles instead.
In practice it's much harder to maintain a native app. I am noticing this with ChatGPT Mac app vs. Codex Mac app. ChatGPT on Mac is constantly behind compared the web ChatGPT while Codex is shipping features at a much higher velocity.
Also ChatGPT hangs and has more weird bugs compared to Codex.
The issues with the ChatGPT Mac app could also be reflective of the state of Swift UI considering not even Apple themselves can ship Swift UI apps that aren't janky.
I will die on the hill that Java was a good language, and had the potential to leapfrog us from where we are by at least a decade.
But it got hobbled by the awful, awful enterprise style culture, cultural misunderstanding of OOP (especially inheritance), and corporation shenanigans (fucking oracle).
We were writing and shipping desktop applications with it back in the nineties. Although many of the arguments against it were similar to the arguments against Electron today.
I'm very inexperienced with regards to "JS on the desktop" environments. Does this mean any kind of improvements for Electron apps? Is it possible to port them to Deno?
Having deno desktop do the framework handling for a bunch of popular options is an interesting choice. It seems deno is trying less to be an agnostic JS runtime, and more an "integrate everything toolkit" (not unlike Spring in the Java space).
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.
> The default WebView backend uses the operating system's own webview for small binaries, and you still have the entire npm ecosystem available through Deno's Node compat layer.
Sounds like a similar architecture to Tauri, but your business logic is in typescript instead of rust.
This works well. I’ve been using it to bundle other binaries with my applications and so far my users have had no issues on Windows, Linux, and macOS. I’m still a bit surprised given how new it is
Of all the content they put out I liked the comparison section the most. The last row says iOS/Android - Electron: no, deno: not yet. If they deliver on this it will get much bigger.
This is kind of exciting. I have a lot of web development experience but every time I've tried to write a desktop app in the past, it just feels like a very clunky and unintuitive experience.
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.
Impressive work. This is going to be really interesting for vibe coding Desktop apps. I imagine this on Lovable, Bolt or v0 since they basically default to using Typescript for building web apps. I've been using Go/Wails for desktop projects rather than a bundled Chromium and Node in a small desktop app, Electron did a good job but that was a big No for me.
Curious to know who is using Deno in anger most days and in production full time? It seems like the choice of JS runtimes exploded over the past few years with that, Bun, etc.
I use it for several applications (frontend, backend, CLIs) in production settings, and it has been excellent. Caveat: I serve small internal teams mostly, some projects only serve < dozen users. One is around 500/day. No issues at all. I’ll definitely use Deno desktop for these internal tools. Their binary compilation (especially now that it can include other binaries) has been totally sound and I expect this to work well too.
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.
In case someone is using something we haven't heard of e.g some are running using cloudflare workers which also has some unique runtime properties. AWS has something called LLRT.
libcef is the Chromium embedded framework[0], so your build isn't using a webview or maybe its using both. I just tried it on my mac, and I can't keep libcef out even with `--backend webview`.
IIRC Electron hello world is ~ 100-150 MB because it bundles a browser/Chromium runtime.
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`?)
Interesting but IMHO as we see on mobile providing WebViews work. Maybe instead of having Electron, Tauri, Electrobun, now Deno desktop but also plenty of alternatives then desktop browsers should provide WebViews on desktop with sandbox and permissions that make those applications usable. The alternatives listed here would just be fallback for a transition period until the WebViews are "good enough".
That's a whole can of worms, Micro$lop entangling its own browser with its OS, getting a (gentle) slap on the hand for its abuse of monopoly position for it, having to remove it claiming it's "impossible", etc.
I was just today morning thinking about some such idea, for mhtml to be embedded with light weight renderer so it does'nt have to rely on other browser
I've decided on using a Clojure/Flutter hybrid that gets the best of all worlds. May integrate move from Bun to using Deno here https://codeberg.org/arik/clutter
Maybe it is because it is still in development, but building and running the Hello World example just gives me a blank terminal and a white window that is not responding.
No matter how much you hate everything about js desktop apps — there are no proper alternatives.
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.
can i open a socket with these tools ? can i open an odbc connection for example ? Or have i need to have a backend ? On desktop usually you can do much more than in the sandbox of a browser . I ask because i don't know these technologies. On windows, even if i don't like it, if the interface and the logic are not too complex, powershell with winform make you create things without "anything" installed and you can easily interact with other windows programs ( office 365 suite, autocad and so on ) so for doing "fast things" in my opinion is a very strong alternative .
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.
I challenge you to replicate something "simple", like an iMessage-style UI/UX in pure Win32 or WinForms.
The web views are entirely about productivity gains, not technological excellence. I don't know of many who would argue that the web view approach is superior from a purely technical perspective. It is mostly downsides in terms of performance, E2E latency, startup delay, security edges, etc.
Doesn’t mean you should use it for new things in 2026, but for building a chat app with? Yeah, it’d be very easy.
I’d know, because I’ve done it (granted it was over 15 years ago at this point, but I’ve done it). Was used internally, with a PHP backend. Worked great!
You should try the last few Xcode versions some time. As far as I'm aware there's not a single line of Javascript in it, and all UI is 'native' (whatever that means these days), and the whole experience is such a janky and laggy mess that even VSCode feels slick.
It's trivial to write slow UI application in any tech stack, and just being 'native' really means nothing nowadays.
I've seen variants of this comment for many years. The alternative to "web UI slop" would presumably be one of the many native toolkits.
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.
Yes, native UI toolkits are not perfect, even though I consider Qt very close to one (I'm sure naysayers will find nitpicks). In the end, the choice is between the apps that eat 1GB of your RAM and learning to deal with some idiosyncrasies of native toolkits.
It hasn't made any inroads on the desktop though... all anyone did was just package their own SWA into a self-contained browser that serves its own content. They continue to be websites, with all the pitfalls of them.
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.
Even if SwiftUI, Qt and whatever Windows uses this morning were absolutely perfect, developers would write web UI slop to not have to write three frontends. That, and familiarity with JS are the whole reason.
While I've never liked to use deno compared to node and bun, this looks particularly good. The zero config options are nice, all the features seem to be in the place I like, and I'm happy they're not dogmatic about using the system webview and let you ship your own CEF. The state of system webviews on non-windows platforms is horrendous.
How does this differ from electrobun, which they explicitly mention, but make no point about? I had a quick drive with deno desktop and don't see how it's better. If anything it's lacking in comparison in my opinion. But hey, we can build desktop apps with deno now, too. So they got that going I guess ...
I watched traditional GUIs for a while and used many of them, mostly via ruby as wrapper, sometimes also via java. I finally reached the conclusion not too long ago, that web-apps are the only real alternatives now. Too many things do not work when it comes to traditional desktop applications. There are even regressions, e. g. ruby-gtk4 barely works for me. And there is no real support for any problems really. People make fun of e. g. electron "soooo big so bloated", and WebAssembly is still not really in any breakthrough after almost 20 years. But traditional desktop apps are also even more dead. So I'll have to add JavaScript/TypeScript/Node now simply because there are no real alternatives to this anymore. I'd wish we would have a real "write once, run everywhere"...
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.
Vastly easier to set up, optionally lets you use platform web renderers, Typescript by default, you can use the Deno API instead of Node (compatible with less code but much better designed), built-in auto update, you can use Fresh which IMO is the best web framework.
RE: Tauri not having cross-compile... There's a GitHub action that compiles for Linux, Windows, and Mac. So practically it does have it, just not out of the box.
what happens when two apps need different cef versions? doesn't that just mean you're back to bundling your own browser anyway. does the shared runtime actually save memory when the underlying chrome versions diverge?
> 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?
[0]: https://docs.deno.com/runtime/desktop/comparison/
In case anybody else wondered CEF is the Chromium embedded framework.
https://github.com/chromiumembedded/cef
The biggest weakness of a framework like Tauri is the choice to target system webviews instead of bundling a browser runtime.
It seems great to be able to cut hundreds of megabytes out of your app installer, but the platform differences wind up being a complete and ongoing pain in the ass.
Tauri support on Windows is phenomenal.
Tauri on Mac runs into lots of WebKit/Safari issues, especially on older Mac machines that have an older engine that doesn't support modern web APIs. Your app can crash or be left non-functional. You'll find out about these runtime bugs in the wild randomly, and patching for some customers can take days, if not weeks.
Linux support is hellish, and it's best to not even try targeting Linux with Tauri.
Tauri is in the process of adding CEF support. It should probably become the default build target for all platforms.
I used CEF for a project and Google is detecting CEF via some opaque algorithms and not allowing logins from it. From https://security.googleblog.com/2019/04/better-protection-ag...:
> Because we can’t differentiate between a legitimate sign in and a MITM attack on these platforms, we will be blocking sign-ins from embedded browser frameworks starting in June
Granted this was years ago, maybe the situation improved? I had to abandon my CEF project because of this.
Most apps (on desktop or mobile) open third party auth flows inside the user's default browser, which makes this a non-issue. For one, if you embed the Google login flow into your app then I can't reuse my existing session in my browser. But it also exposes my full credentials to your app for no reason, which is a good thing to avoid.
Just to let you know, CEF was used for Riot and League of Legends client as well [0]. The results haven't been nice, but I'm not aware if this was a problem with the CEF technology itself or other component/processes are to be blamed.
[0]: https://www.riotgames.com/en/news/architecture-league-client...
When the new client was built, microservices were the hot new buzzword.
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.
CEF is + has been the de-facto standard when you have a native app and want to do a web UI.
It's not the only option, but it's the most mature with the largest amount of docs + stack overflow questions, so it's a "safe" choice.
If you peek into the native resources files of most games/desktop apps, you'll find a good portion of them bundle + use the CEF dll.
Also Spotify. I believe Spotify was one of the earliest adopters of CEF, maybe the first major adopter?
The desktop app was originally a native C++ app, but they switched to CEF around 2011-2012. (It caused a very noticeable drop in performance!)
Both Steam and Battle.net use CEF for their UI as well. And IMO they are on 2 ends of the "nice to use" from the implementation side (Steam being a sluggish hell and B.net being nice). Though then again B.net is only for Blizzard games, so they can also optimise for the limited set games.
On the gaming side, last I checked Steam's client was using CEF too and it doesn't get widespread blame for anything.
No shortage of games using it for in-game browser stuff, too.
This is more a function of how mismanaged the project was at Riot (the iron client days, choosing Ember, etc.) which led to the current state of the launcher.
I regularly install and uninstall the league client on Mac based on how I play that game (require fresh installs to raise the playing cost) and their client really sucks. Even freshly installing it, the client inhibits and hijacks mouse clicks from the full screen game when it's open. It took me months to figure out I would have to minimize the game, open and minimize the client (separate app) open, and then clicks would sometimes properly return.
Before that I was closing both and playing a game of roulette. By the the time my game was working, I may have already been reported for being afk and the game ended. Edit: other bugs have included starting to download the game and then signing in afterwards (their UI doesn't stop you) and then download progress disappearing, perhaps hanging, and you having no way to know it for a 40gb file unless over an hour has passed and you check disk size and then realize the client doesn't know how to load it. Start over and do a fresh install again, clear cache etc because their cache of the client still thinks somethings being downloaded even though it's not. Also having chat permanently off, results in weird glitches with friends requests and being unable to add new friends.
Horrible experience. But since the game is so optimized for addiction and dark patterns these days, and sunk cost, its a game I find myself returning to every once in a while.
I doubt the benefit. Practically every Electron app on a desktop uses different versions of Chromium and many are very out of date because of the risk of breaking when upgrading.
People build web apps for an array of browsers and huge ranges of versions. I think if you started using some tech to deploy an end user program and knew from the beginning the browser could be updated beneath you it would work just fine. But if you start with a golden version of Chrome and put off updating for too long you’ve let yourself get too comfortable.
Web devs are used to their target being evergreen, so I suppose you could opt in or out of that model: "just give me what you got".
True for this decade, but in the previous decade it was very much the opposite. Before you used any kind of browser api or nice language feature you would feature-detect it:
And if it wasn’t there you would define it yourself, it was called “polyfilling”. This was so commonplace that we built significant tooling like babel to standardize feature detection tests and fallback implementations - for a few years you could write And behind the scenes the Rube Goldberg machine would turn this into something that would run in a JavaScript environment that had neither arrow functions nor promises.> Web devs are used to their target being evergreen
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.
> Web devs are used to their target being evergreen
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.
A strip down version of electron TBH.
I'd prefer if it just used the system webview rather than downloading and managing an embedded browser itself. Webview2 on Windows for example.
> Small by default, full Node compatibility. The default WebView backend uses the operating system's own webview for small binaries
That appears to be the default, CEF is available if required (hint: it shouldn't be).
System WebView but Electron is now the system
Ah, that's a new systemd module now.
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...
You are running a binary that you got from the developer. If it presented you with Deno permissions, I think that would be misleading because there’s no guarantee of their integrity.
That is true. I wonder if it could be possible to let the user supply and wrap the app around their own, trusted installation of Deno (rather than the one bundled in the app) to specify permissions.
> What deno desktop doesn't have yet
> Runtime permissions for desktop apps (a permission prompt on every filesystem / network access, i.e. Deno's permission system applied to desktop sandboxing).
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.
* https://docs.deno.com/runtime/desktop/backends/
Wouldn't that just be "Raw"? I.e. start a webserver and ask the system to open the URL. There is no "special stuff" to do in this case like avoid sockets in favor of IPC to a well known webview or package CEF and no real integration to make with dev tools etc after - it's just open socket and serve from prebuilt binary.
No. As I understand it, the Raw backed just gives you a Window with input handling and you have to embed something like Skia, WebGPU for the graphics. So basically you have make your widget library yourself.
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.
> I'm happy to see this I see that this provides CEF, Webview and Raw
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.
I think that my Sciter is better option when you need HTML/CSS/JS native application running on Windows (XP and beyond), MacOS and Linuxes.
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.
[1] https://gitlab.com/sciter-engine/sciter-js-sdk/
This is something that can bring me back to Deno. Binary size is still pretty big IMO. If they can trim down runtime based on the specific uses of standard library (sort of treeshake Deno runtime itself), it would be revolutionary. Java promised this with `jlink` but sadly failed to deliver for wider adoption.
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!
This is a smart thing to ship. For me it would totally be a consideration when deciding on a platform to use.
agree, small footprint & cross-platform looks like a nice alternative to electron or tauri..
Their comparison page shows some savings, but not in every case (~40 MB / ~150 MB) https://docs.deno.com/runtime/desktop/comparison/
The overall feature seems really solid, but I'm impressed they couldn't reduce the average package size further from 40MB even when not using CEF. I guess that wasn't a huge focus when developing this feature? Tauri and Dioxus can easily hit less than 5MB for package sizes.
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/
Deno Desktop is bundling the V8 JavaScript runtime so it can have JavaScript on the backend. Tauri uses rust for the backend and your browser's JavaScript engine for the frontend.
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.
>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.
this is misleading. there is no "running true ts". you will always be running pure js (until someone actually develops a "true" ts engine), and deno does "type stripping" just the same. the only difference is that it bundles the tools and makes it transparent and config-free which is more convenient (although more rigid).
> Why would I use Tauri now?
The same set of reasons anyone made desktop apps before Deno desktop launched. Deno desktop is not the reason desktop apps are made. If someone really wanted a desktop app made before, deno desktop isn't going to suddenly make new ones start appearing. It will just be a new choice among the many.
Tauri doesn't lock you in to one JS ecosystem. In fact, it doesn't require you to use javascript at all.
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.
Deno also just strips the type annotations when running TS code - at least by default. To get type checking you'll need to run via `deno run --check`, or use the separate `deno check` subcommand. No big deal since type checking and linting usually happens automatically in the IDE during development.
Good to know. Does it also preclude features like enums?
If you want desktop and mobile builds.
Tauri 2.0 added support for iOS and Android builds as targets.
> Why would I use Tauri now?
You’re “backend” isn’t JavaScript.
> Deno can run true TypeScript directly and not just strip types
What exactly do you mean by that? Because no js engine carries the ts types into the runtime as far as I know. Deno and nodejs both use v8 as the runtime. v8's internal types are not connected at all to the ts types regardless of the wrapper. The only difference might be when/if static type checking is performed.
I think they mean deno handles transpiling for you so there’s no visible machinery for this aspect of the program. It’s just convenient.
There’s no running TS. Everyone executes JS.
Also TS itself is going towards stripped types. There’s this proposal which might land on browsers some day:
https://tc39.es/proposal-type-annotations/
And in preparation you can use this setting on your tsconfig:
https://www.typescriptlang.org/tsconfig/#erasableSyntaxOnly
> and you get a reliable rendering engine
How is it more reliable than Tauri - aren't they both using the system webview?
Deno Desktop can bundle CEF (Chromium Embedded Framework) according to https://docs.deno.com/runtime/desktop/comparison
Deno desktop can use system web view OR embed CEF. Tauri is just system web view.
Temporarily at a place with 10-15 mbps. 150 MB is around 1 minute.
I grew up on 30 mbps. >= 100 is all I need nowadays.
But 10 mbps and websites and downloads really start to take a while.
The more bits and bytes you save, the more people will be pleased with your stuff! Even if they don’t know what bits and bytes are, and just go based on impatience
But that would be the same argument for using electron? Why use this and not electron?
> 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?
My guess is that it's not using IPC on OS level, like D-Bus on Linux, but rather a supervisior process starts and orchestrates child processes as needed. And all these processes use a shared memory model.
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...
this is what I wonder as well.
> 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.
That is not why people use Electron. The goal is not and never was to just be a "UI toolkit" and "adopting UI patterns from their host OS".
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).
gstreamer is not that complicated
chromium is basically operating system at this point, it lacks kernel and ability to boot independently (added in chromium os), which is both good (from abilities standpoint) and bad (when copy of chromium is bundled with every app that renders webform with text field and button and nothing else)
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)
How is it a poor choice of words? It might not be "native" UI, but they never claimed as such.
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
I don't mind the idea of using HTML components and widgets to style desktop applications. CSS and the DOM are widely known and reusing those for desktop apps is probably a good idea.
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.
> 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
Blitz (https://github.com/DioxusLabs/blitz) is exactly that. It's a new custom browser engine supporting standard HTML/CSS with a native Rust API (and optional integration with Dioxus which is a React-like UI framework in Rust). Baseline binary sizes are around 10mb.
We share a few components with Servo (Stylo the CSS engine (also shared with Firefox), and html5ever the HTML parser), but we've built a bunch ourselves too: notably we have our own layout engine, DOM tree and event handling. Servo is unfortunately tightly coupled with SpiderMonkey, and there is little prospect of removing that dependency in the short term.
This isn't exactly what you were suggesting, but it made me think of https://hacks.mozilla.org/2026/02/making-webassembly-a-first... since that article is about not needing to go through js to use wasm.
Every time I use Zed across Linux, macOS and Windows , I'm amazed stable and performant it's GPUI framework is. As a user, I'm very happy with it; of course some basic features like accessibility is missing but I'm sure it will be implemented soon.
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.
Live reload. GUI development in compiled languages is a pain compared to web development.
For me it's not stable. After they change their renderer from one to another it freezes for me from time to time. But on the other hand I'm running Nvidia on Wayland so I feel no hate towards Zed owners - and restart is super quick ;)
> basic features like accessibility is missing but I'm sure it will be implemented soon.
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.
Looking native has long left the station as an objection about a UI.
Like 25 years ago. Nobody gives a damn since Microsoft stopped giving a damn.
I'm not part of the Apple world, but I thought they gave a damn?
> They consistently miss the mark in adopting UI patterns from their host OS.
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+.
That's an advantage to you. Not necessarily to your users.
> look native to the OS
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.
Consistency is a large factor in any good design, UI design more so.
I understand historical usage of the term with regards to desktop, but im unsure how you could consider HTML, CSS, JS, and runtime as anything other than a UI toolkit. They control the layout, styling, and actions of a UI.
Yeah, it is mostly laziness and cost cutting at the expense of users.
Nowadays there isn't even an excuse anymore, just vibe code it away in native frameworks.
Which native framework?
Even in a "post-vibe code" era I wouldn't want to create multiple versions of the same app, and none of the "platform-native" GUI toolkits run on everything.
SwiftUI is apple-only, gtk has pretty bad compatibility on non-linux, qt is decent but requires C++ or python, and even so still not much for mobile. Don't even get started on "Windows frameworks", because as I write this sentence they may have left a new one in the ditch.
Flutter may be the closest, but why didn't they go with e.g. Java instead of a new language?
So yeah, if you want a truly universal UI then web is your best bet.
I never thought I'd defend Electron, but I'd rather use the bloated web UI than a vibe coded Qt/GTK version I'm positive will not have seen any human QA.
When I can modify my desktop/theme (KDE) with css I will happily start doing it since that sounds easy.
I have better things to do than spend my time adopting UI for various different systems. If Electron gives me the option to easily create a UI that looks the same everywhere, then I'll pick Electron over anything else any day.
At this point the only OS with a consistent look and feel at all is Mac. For the other OSes, I don't even know what a "native" look and feel would be. And most apps have their own branding and style they want to tout anyway. So I don't think "apps should look native" is the leading reason to not use Electron.
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.
> At this point the only OS with a consistent look and feel at all is Mac.
Apparently, NOT! Apple's controversial Liquid Glass UI disrupted their long-standing Human Interface Guidelines by prioritizing cinematic aesthetics (transparency, refractions, and blur) over core tenets like readability, contrast, and content deference. Critics highlight that transparent, light-bending panes frequently clash with underlying wallpapers or videos, causing text and buttons to become illegible. This is a HOT topic in recent WWDCs and amongst UI designers.[1]
[1] https://blog.prototypr.io/why-apples-liquid-glass-design-is-...
> Make it a PWA if you want it in its own window.
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.
Who cares if it looks native?
Native UIs change all the time too and not always for the better.
I change clothes all the time too, still match the pieces of clothing each time.
There's aesthetic value to coherence. There's also design, usability value. I have Telegram, Steam and Firefox opened right now and each one of them displays different minimize/maximize/close buttons on the top right. That's not ideal.
Change over time is something different from apps looking vastly different at any given time.
> UI patterns from their host OS
I genuinely wonder who ever want that, and what apps those people use on their PC. Can you imagine, for example, Blender Foundation says that their next goal is to make Blender's UI look more like the host OS?
I have used Blender just a bit, but it was very jarring when I first opened it and discovered that it has its own menu bar within the window, rather than at the top of the screen. It has its own save/open window rather than using the system-provided one, as nearly all truly native Mac apps do. I doubt most Mac users like this.
I have somewhat more experience with QGIS. It has a standard Mac menu bar, but the icons are inelegant and Windows-ish, window layouts are Windows-ish, dialogs don't behave correctly in Mac full screen mode. It could use a MacOS glow-up.
I think Visual Studio Code (native menu bar, native save/open, but a core UI kind of unto itself that is consistent across Mac and Windows) does a better job of balancing cross-platform vs native.
And then there's the approach taken by Adobe and Microsoft Office. These apps do a much better job of adopting native platform appearance and conventions (sometimes at the expense of application consistency across platforms).
> 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.
The irritating, and unnecessary, pedantry.
Indeed. Even Qt isn't native, in the most purist sense.
Tauri is getting traction in the meantime.
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.
Tauri is a good way of packaging offline PWAs. It kind of sucks for building proper applications. The entire model for integrating with a local backend is just bonkers (no, I don't want my local application to pretend to be a web server - it's not a web server, I want to give you actual host bindings and share memory).
Nobody cares about this anymore.
On Windows you have 20 different ways to write native apps that all look different.
On Linux you have Qt/GTK and god knows what else.
Only macOS is somewhat consistent although with Liquid Ass it's also getting worse.
Since when did anyone ever complain that youtube, google maps, roblox, or any other web sites didn't have native buttons and UI patterns?
Are you implying that the Windows, Mac, and Linux native desktop user interfaces don't all totally suck??! Or that there wasn't a huge celebration when Alan Dye finally left Apple for Meta? Or that users are clamoring for Jony Ive's infamous shallow superficial visual elegance over affordance and discoverability and usability?
Is it just too confusing for people to use youtube because the buttons don't look and feel exactly like native Mac buttons on the Mac and native Windows buttons on the Windows and whatever the kids are using on Linux desktops these days, therefore nobody uses youtube, and that it will only ever get popular if it just had a native look and feel?
Basically you're saying websites are the same as apps, and whether they're used in the browser or as a desktop app, the UI is fine to ditch that of the OS. Fine if you think so. I'll be sad to see OS and apps diverge completely in terms of UI.
YouTube succeeds for its content. Its UI is hot garbage both in the web and their apps. Google Maps is an atrocity and I’m very thankful Apple has decent data where I live. Roblox I don’t know, other websites I consume mostly in Reader mode.
None of that changes whether it's a UI toolkit, which it surely is.
This. It's nuts how the whole industry accepts that typesetting engine from 80s with bunch of hacks on top is currently dominating cross-platform UI development.
I think the last time I tried Deno for desktop it didn't allow for fullscreen webview apps. that was a showstopper for our kiosk apps. I'll have to revisit that issue and see if it's resolved now. I'm glad to see Deno continuing to march on.
You may have played with a 3rd party/unofficial solution or similar in the past as Deno Desktop has only just now become available in the Canary branch.
Similar to something I'm working on for games: https://jumpjet.dev
WASM you can bundle for Windows, macOS, Linux, Android, iOS and web. Unlike Deno Desktop, it doesn't rely on a browser engine.
Just FYI, when checking out jumpjets homepage, the white-dot airship in the background made the white text in the hero banner hard to read.
Cool project!
Do you mean "Unlike Deno Desktop"? Deno Desktop definitely relies on a browser engine.
Yes, thanks.
Do you reccomend and resources for building w/ & learning about wasm?
It's all so bleeding edge right now. It also depends how deep you want to go. An increasing number of languages support wasm as a compile target, which is helpful.
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
Why this and not rust or go?
Literally the first question in TFA.
That would give us efficient desktop apps that don’t need a JavaScript runtime.
Deno Desktop supports two backends as of now: CEF (Chromium) and Webview
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
Any indication when v2.9.0 will be released? I'd love to play with this, but the install instructions (at least for linux) don't seem to work. Is it working in Windowsland or on macOS?
As much as I like cross-platform stuff, I also really like native UIs that follow native UX patterns, etc.
This ship has long, long sailed. If you don't spend your all your 24 hours as an office worker using Microsoft software, or you're locked in with a PC from 30 years ago, chances are almost every single UI you use will look differently, besides some microscopic agreements, like back button or a burger menu.
We just got used to it. There is some very vague thin layer of "commonly accepted patterns and symbols", but otherwise users just get through it.
We spend a lot of time using different browsers. As far as I know there no web engine that use native OS UI for rendering.
Isn't all uses native OS UI widget? But since the brand need to be experienced the same across platform, it overrides the native rendering and use custom styles instead.
> As far as I know there no web engine that use native OS UI for rendering.
That sounds like a monster I would be afraid to touch.
In practice it's much harder to maintain a native app. I am noticing this with ChatGPT Mac app vs. Codex Mac app. ChatGPT on Mac is constantly behind compared the web ChatGPT while Codex is shipping features at a much higher velocity.
Also ChatGPT hangs and has more weird bugs compared to Codex.
The issues with the ChatGPT Mac app could also be reflective of the state of Swift UI considering not even Apple themselves can ship Swift UI apps that aren't janky.
https://daringfireball.net/2026/06/swiftui_only_makes_it_eas...
Did they run out of tokens? Why don't they ask their agent to update the mac version?
I swear we're just going to end up with Java again.
I will die on the hill that Java was a good language, and had the potential to leapfrog us from where we are by at least a decade.
But it got hobbled by the awful, awful enterprise style culture, cultural misunderstanding of OOP (especially inheritance), and corporation shenanigans (fucking oracle).
Java may be good, but it's boring. No joy comes from programming in Java.
I need to enjoy my work to be engaged and productive.
I have nothing against java. But for some reason in my experience all the developers using it are low quality, and gave it the reputation it has.
It is better to be D language then - natively compiled and has superb meta programming features.
Especially if to consider that I've added native D support to Sciter [1].
[1] https://terrainformatica.com/2026/06/05/ai-assisted-developm...
Java would be a killer platform if they shipped built-in, tauri-like, UI.
There's Compose Multiplatform if you are willing to switch to Kotlin. Only caveat is that it uses Canvas rendering on web.
At this point I think that would be a more sane outcome than whatever it is we have right now.
We were writing and shipping desktop applications with it back in the nineties. Although many of the arguments against it were similar to the arguments against Electron today.
The Revenge of Javagator!
https://news.ycombinator.com/item?id=19837817
I'm very inexperienced with regards to "JS on the desktop" environments. Does this mean any kind of improvements for Electron apps? Is it possible to port them to Deno?
Having deno desktop do the framework handling for a bunch of popular options is an interesting choice. It seems deno is trying less to be an agnostic JS runtime, and more an "integrate everything toolkit" (not unlike Spring in the Java space).
Actually, this would be amazing for distributing web games as apps for Steam or online purchase. I am going to give it a try.
Why did they describe electrobun as macOS only? I checked their docs and it has support for Windows, macOS and Linux
https://docs.deno.com/runtime/desktop/comparison/ https://github.com/blackboardsh/electrobun#platform-support
Thanks, I'll update the docs. When we wrote them a couple weeks back, Electrobun was announcing Linux only support.
Looks actually good!
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.
> The default WebView backend uses the operating system's own webview for small binaries, and you still have the entire npm ecosystem available through Deno's Node compat layer.
Sounds like a similar architecture to Tauri, but your business logic is in typescript instead of rust.
> Opt into the bundled Chromium (CEF) backend when you need identical rendering across macOS, Windows, and Linux.
Sound more like Electrobun
Neat! Is there any "bundle/integrate with existing native application" story like Tauris sidecar [0]?
[0]: https://v2.tauri.app/develop/sidecar/
From what I understood, what you want is `deno desktop --include […]`.
> Includes an additional module or file/directory in the compiled executable.
This works well. I’ve been using it to bundle other binaries with my applications and so far my users have had no issues on Windows, Linux, and macOS. I’m still a bit surprised given how new it is
Of all the content they put out I liked the comparison section the most. The last row says iOS/Android - Electron: no, deno: not yet. If they deliver on this it will get much bigger.
This is kind of exciting. I have a lot of web development experience but every time I've tried to write a desktop app in the past, it just feels like a very clunky and unintuitive experience.
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.
Is it going to support iOS/Android?
Bartek from the Deno team here. No promises yet, but we're looking into feasibility of it.
No customizable programmable browser runtimes exist for those.
What do you mean by that? Does this[1] not count?
[1] https://capacitorjs.com/
The docs say it's planned but no proper roadmap for it yet.
Impressive work. This is going to be really interesting for vibe coding Desktop apps. I imagine this on Lovable, Bolt or v0 since they basically default to using Typescript for building web apps. I've been using Go/Wails for desktop projects rather than a bundled Chromium and Node in a small desktop app, Electron did a good job but that was a big No for me.
Curious to know who is using Deno in anger most days and in production full time? It seems like the choice of JS runtimes exploded over the past few years with that, Bun, etc.
I use it for several applications (frontend, backend, CLIs) in production settings, and it has been excellent. Caveat: I serve small internal teams mostly, some projects only serve < dozen users. One is around 500/day. No issues at all. I’ll definitely use Deno desktop for these internal tools. Their binary compilation (especially now that it can include other binaries) has been totally sound and I expect this to work well too.
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.
Why "etc."? Isn't it just node, bun and deno? Genuine question
In case someone is using something we haven't heard of e.g some are running using cloudflare workers which also has some unique runtime properties. AWS has something called LLRT.
https://github.com/awslabs/llrt
https://developers.cloudflare.com/workers/runtime-apis/
There's QuickJS, LLRT, Rhino, and GameMaker is about to get TS/JS support.
> deno desktop is opinionated about those tradeoffs:
> 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)
libcef is the Chromium embedded framework[0], so your build isn't using a webview or maybe its using both. I just tried it on my mac, and I can't keep libcef out even with `--backend webview`.
https://github.com/chromiumembedded/cef
IIRC Electron hello world is ~ 100-150 MB because it bundles a browser/Chromium runtime.
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`?)
Try the webview backend: `deno desktop --backend webview`
The docs say that's the default:
https://docs.deno.com/runtime/desktop/backends/#webview-(def...
So how much does a hello world weight?
Interesting but IMHO as we see on mobile providing WebViews work. Maybe instead of having Electron, Tauri, Electrobun, now Deno desktop but also plenty of alternatives then desktop browsers should provide WebViews on desktop with sandbox and permissions that make those applications usable. The alternatives listed here would just be fallback for a transition period until the WebViews are "good enough".
Webviews have always worked since MSHTML, the issue is being comfy helping Google's market share instead of writing portable Web code.
That's a whole can of worms, Micro$lop entangling its own browser with its OS, getting a (gentle) slap on the hand for its abuse of monopoly position for it, having to remove it claiming it's "impossible", etc.
Is it not a web view? With nodejs capabilities from the “backend” half of the app for normal desktop app filesystem access etc?
If a Web View is not provided by a browser then it's an already installed browser then it's as they say "web rendering engine" that they ship along.
I'm trying to argue that it should already be available via Firefox, Chromium, etc on desktop.
I was just today morning thinking about some such idea, for mhtml to be embedded with light weight renderer so it does'nt have to rely on other browser
> for mhtml to be embedded with light weight renderer so it does'nt have to rely on other browser
That's Sciter (https://sciter.com) and Sciter.Quark (https://quark.sciter.com) in particular, no?
I've decided on using a Clojure/Flutter hybrid that gets the best of all worlds. May integrate move from Bun to using Deno here https://codeberg.org/arik/clutter
Care to expand on what this solution is? What is Clojure bringing to Flutter in this case? Ty.
> Backend and UI communication goes through in-process channels, not socket-based IPC
Are they running the frontend and backend in the same process? Sounds a bit dangerous security-wise?
How can in-process channels be more dangerous than a socket-based IPC? The frontend still goes through the "secure" JavaScript engine AFAICS.
Maybe it is because it is still in development, but building and running the Hello World example just gives me a blank terminal and a white window that is not responding.
Sorry to hear that, could I ask you to file an issue in our bug tracker?
So I guess this is a competitor to Electron?
Hmm suppose you have a node GUI-less application. What would you pack it in to have something reasonably self contained to deploy?
Deno actually has had a built in compile to binary feature * I've used it before a few times.
* https://docs.deno.com/runtime/reference/cli/compile/
Look into Single Executable Applications
https://nodejs.org/api/single-executable-applications.html
Thanks!
Is this a new trend? Why are everyone starting to do desktop runtime? For example, I recently saw Bun Electron, and then I saw this project.
I guess people are tired of each instance of an Electron-based app using 1GB+ of RAM.
I just tried `deno desktop helloworld.ts` and the result is 442 MB. So it's not any lighter than Electron (see my toplevel comment)
Why are people parroting this meme?
For 8 years now, constantly updating to newest Electron, my Electron app has been using only about 150mb of RAM - (see Video Hub App)
No matter how good they get, I still hate everything about js desktop apps
No matter how much you hate everything about js desktop apps — there are no proper alternatives.
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.
I'm truly curious about running another desktop environment inside via WASM, honestly...
Deno desktop supporting other backends using raw is crazy!
Awesome! Looking forward to trying this out.
can i open a socket with these tools ? can i open an odbc connection for example ? Or have i need to have a backend ? On desktop usually you can do much more than in the sandbox of a browser . I ask because i don't know these technologies. On windows, even if i don't like it, if the interface and the logic are not too complex, powershell with winform make you create things without "anything" installed and you can easily interact with other windows programs ( office 365 suite, autocad and so on ) so for doing "fast things" in my opinion is a very strong alternative .
Yes, you can do all that. You get a fully-fledged Deno program that can do all of this, _plus_ you get a frontend GUI app.
They had this before I used it to ship some stuff but binaries were big . How small did they get it with this update
I hope bun desktop is coming soon?
I expect a poorly conceived and buggy vibe coded version will be available this afternoon.
Funny how Deno desktop supports prompt(), which electron refuses to implement
I don't get the point of this.
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.
I challenge you to replicate something "simple", like an iMessage-style UI/UX in pure Win32 or WinForms.
The web views are entirely about productivity gains, not technological excellence. I don't know of many who would argue that the web view approach is superior from a purely technical perspective. It is mostly downsides in terms of performance, E2E latency, startup delay, security edges, etc.
In WinForms?
Is that supposed to be a challenge?
WinForms is incredibly easy and simple to use...
Doesn’t mean you should use it for new things in 2026, but for building a chat app with? Yeah, it’d be very easy.
I’d know, because I’ve done it (granted it was over 15 years ago at this point, but I’ve done it). Was used internally, with a PHP backend. Worked great!
You should try the last few Xcode versions some time. As far as I'm aware there's not a single line of Javascript in it, and all UI is 'native' (whatever that means these days), and the whole experience is such a janky and laggy mess that even VSCode feels slick.
It's trivial to write slow UI application in any tech stack, and just being 'native' really means nothing nowadays.
I've seen variants of this comment for many years. The alternative to "web UI slop" would presumably be one of the many native toolkits.
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.
Yes, native UI toolkits are not perfect, even though I consider Qt very close to one (I'm sure naysayers will find nitpicks). In the end, the choice is between the apps that eat 1GB of your RAM and learning to deal with some idiosyncrasies of native toolkits.
It hasn't made any inroads on the desktop though... all anyone did was just package their own SWA into a self-contained browser that serves its own content. They continue to be websites, with all the pitfalls of them.
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.
Even if SwiftUI, Qt and whatever Windows uses this morning were absolutely perfect, developers would write web UI slop to not have to write three frontends. That, and familiarity with JS are the whole reason.
While I've never liked to use deno compared to node and bun, this looks particularly good. The zero config options are nice, all the features seem to be in the place I like, and I'm happy they're not dogmatic about using the system webview and let you ship your own CEF. The state of system webviews on non-windows platforms is horrendous.
How does this differ from electrobun, which they explicitly mention, but make no point about? I had a quick drive with deno desktop and don't see how it's better. If anything it's lacking in comparison in my opinion. But hey, we can build desktop apps with deno now, too. So they got that going I guess ...
Bartek from Deno team hear. I'll love to hear what you feel is missing so we could improve `deno desktop` for more users.
I think for a little while longer, you can catch bun anything, electro or not, refugeess just by not being bun.
I watched traditional GUIs for a while and used many of them, mostly via ruby as wrapper, sometimes also via java. I finally reached the conclusion not too long ago, that web-apps are the only real alternatives now. Too many things do not work when it comes to traditional desktop applications. There are even regressions, e. g. ruby-gtk4 barely works for me. And there is no real support for any problems really. People make fun of e. g. electron "soooo big so bloated", and WebAssembly is still not really in any breakthrough after almost 20 years. But traditional desktop apps are also even more dead. So I'll have to add JavaScript/TypeScript/Node now simply because there are no real alternatives to this anymore. I'd wish we would have a real "write once, run everywhere"...
> I'd wish we would have a real "write once, run everywhere"...
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!
Odd because I'm wrapping up an app that uses Xaw. It should run on the billion or so machines that support X11
https://docs.deno.com/runtime/desktop/#hello%2C-desktop
Yeah, hello desktop.
D:\source\DenoTest>deno desktop main.ts
error: Module not found "file:///D:/source/DenoTest/desktop".
How is this better than Electron?
These from the comparison table stick out to me:
- Can use "raw, system WebView, or bundled CEF" vs "bundled Chromium"
- The size can be smaller in the Raw/WebView cases.
- Built-in automatic differential updates
- Built-in cross-compilation (+the compilations just come built into Deno itself rather than as a 3rd party package).
And, of course, the same lists as one would generate when comparing the base Deno vs Node themselves.
Vastly easier to set up, optionally lets you use platform web renderers, Typescript by default, you can use the Deno API instead of Node (compatible with less code but much better designed), built-in auto update, you can use Fresh which IMO is the best web framework.
would be cool to have a comparison with tauri.
They really did their best comparing it with other tools here https://docs.deno.com/runtime/desktop/comparison/
RE: Tauri not having cross-compile... There's a GitHub action that compiles for Linux, Windows, and Mac. So practically it does have it, just not out of the box.
Another Chrome wrapper...
Great, another way to make shipping bloated javascript apps easier. Just what we need.
what happens when two apps need different cef versions? doesn't that just mean you're back to bundling your own browser anyway. does the shared runtime actually save memory when the underlying chrome versions diverge?
This web page stole my scroll liberty