Simpler Desktop Apps With Deno

I'll be talking about making desktop apps with Deno now. This again as just mentioned was landed five minutes ago. Yes, I mean, let's get into it. So, first off, yes, I'm Leo. I work at Deno, mainly do developer experience, web APIs, maintain JSR if you use it, and as of recently, also a T39 delegate.

So you built a nice web app. You have a product. You want your thing to be a website. But then suddenly people ask, hey, can I get it as a desktop app? And then you have to set up Electron. Electron while being very powerful is a lot to set up. It's not easy. I mean, you have a decision between, well, you can pick between three different things. Either you get consistent UI, small and fast, or you get a JS ecosystem.

And since we are JS Nation, I assume most people here will want to be able to use MPM, the frameworks, node compatibility, everything that you're familiar with. The problem is nowadays, most of the things, you're stuck with two. You can not get all three of them. But the trade-offs usually are with Electron, it's a massive bundle. You're including all of Chromium. That is not small. But if you use Tari and Deoxys, you get very small binaries because they use the system web view, but because it's web view, it's inconsistent, and you don't get the JS ecosystem which is quite a drawback.

All of them are a second project, a second tool chain. You have to separately think about this. It's like separate apps. You cannot just use your normal web app as your desktop apps. But what if you could just do that? Very, very simply. Don't need to do any changes. Don't need to download a separate tool chain, unless you're not using Deno, but that's one additional tool chain, I guess. But it's only one command, and it's deno-desktop.

You literally just have to call deno-desktop and it will turn your app into a desktop app. This is our first public look. There was a tweet a few days ago from Ryan, but now we have decided that we're actually going to go with this. This is shipping as an experimental feature, so there's a lot of breaking changes. Very buggy to some degree still. That is bound to be.

Anyway, we land it as an experimental feature. We want you to try it out and give us feedback. So deno-desktop, you can point at any of your frameworks that you're using. If you're using Next.js, you can just use that. You just call deno-desktop. You just get a desktop app, like an exe.app, just an executable on Linux, or even a distributable like .msi or DMG. You can get any of this with just no configuration at all. It will just work.

Or if you don't have one of these frameworks, you can just use a HTTP server. It's quite straightforward. You just create your Express app, or deno-serve, yeah. Default fetch, your Express app, or if you have your separate framework that's not listed and generates a HTTP server, you can just use that. It just understands HTTP.

So yeah, for example, here, we just have deno-desktop, this main TS file, that's just an Express app, and you get a very terrible desktop app, because there's no styling, it's just HTML with H1. Obviously, you would want to do more than that. If you set the title, for example, it will also take the title, and many more things.

So let's try to build one. This may go wrong. It could very likely go wrong. But yeah, so we are in an empty directory, I have a backup directory there just in case that it actually goes completely wrong. But let's use MPX, create next app. Just my app, sure, we use the defaults. And hopefully the network collaborates, as we go to the backup. Please. Okay.

All right. And we get a pretty standard Next.js app, as anyone has seen, so I can un-CD into my app, and it's just the standard stuff. Let's turn it into a desktop app. I have a separate binary here, which hopefully, let me prove this, since it seems to be cut off from the screen. Should have checked this beforehand. My bad. Can I resize this? No, I can't.

Let me just show that. I have Arduino, that is just local that I use. Anyhow, it's Arduino desktop. I'll scroll down in a second for you. And I'm gonna pass the dash A flag, because Next.js asked for a lot of permissions, and I'm not gonna pass every single one that they want. And that's pretty much it.

So it will start building it. It will take a moment. And just bundle it all up. And create a binary. And we get an app. So if I... So there is myapp.app. I can just call open on it. And the first time it will take a moment to launch. And it launched on the other... It did launch. That's where the demo gods decide not to cooperate. Launch it again. Trust me, I tested this beforehand, and it was working completely fine. I promise. It's always the case. Oh, come on, now.

Seriously? Okay. That is not as planned. But I mean, I have a different demo app that I'll showcase in a moment later. But imagine that this worked. Yeah! Okay. We can try another thing.

So the desktop also has a HMR flag. So you can compile with HMR, and hopefully maybe that one works. And you get a desktop app that you can just modify on the go live. It's going to take a bit longer to compile this one. Just because it does set up the whole HMR infrastructure. But it seems to be doing it.

And it started the app. And I do see it on my other screen. Give it one second. Setting up... Next.js is compiling. Very very fast. Okay. So imagine this worked. Again, I'll demo this with a separate app that is actually functional. But yeah, this should have worked. It was working ten minutes ago. So I should have done a recording. That's on me. But yeah.

So conceptually speaking, this would have just turned into a desktop app you can modify on the go, and typical hot module reloading, you can build your desktop app. But desktop app is not just being able to use the browser that it comes with, and having your web app there. It's also about being able to use the native OS system. Like you want to modify the window, like custom title, resizing some events. You want to modify the tray. You want to be able to modify the window, you want to modify the tray or the dock and interact with that, or all these different types of events, and also, like, native dialogues, all the kind of stuff that you use to make a desktop app.

And we do have, like, here's a bit of an example. You can just create a browser window, add a binding. So bindings let you call functions from the Deno side in the browser, and so you can just set up a function to just do whatever you need to do that the browser does not have access to. And then this confirm, for example, just creates a native popup. Now, these are stuff that we currently support, but we're going to support more. Native dialogues, notifications, system tray, so you can interact fully with the system tray.

Everything is supported on most of the operating systems, so it works on Linux and Windows. There's some limitations on Linux still that we're figuring out. Again, very experimental. The dock or the task bar, menus, so that, and also the windows, input events, and, again, we are adding more stuff. This is just, like, the first pass that we implemented. Yeah. Bindings are not IPC like in Electron or Tauri, where basically backend talks via a cross-process serialization, socket, and serializers. We actually are in the same process, so this gives some benefits that we can transfer data between the browser and, you know, very efficiently, very fast, and we support, like, under the hood as far as I remember, Electron only supports strings and does its own serialization.

You can move a JavaScript type back and forth. With some limitations, but there's more that can be done than compared to Electron. Yeah, no sockets, no cross-process copies, so very efficient.

Now, the dev loop. Again, HMR, you just edit, save, and see it instantly. It just works. And that purely works with, right, that mainly works well with the frameworks, but it also works very well with any, like, standalone app, which is not part of the frameworks that I showed earlier. It will just work.

So, yeah, framework apps just work, plain apps. Deno watches the process, and it just does any of the reloading. You don't need to have any separate tools. Deno just does this all for you. And yeah, runtime and Windows stay alive. You don't have to constantly see a restart. With Electron, this is a bit slow. So we try to make this much nicer.

But One Engine is not enough. With Electron, you are stuck with WebView, with Chromium. With tower, you're stuck with WebView. What if you want to pick? People should have the power to decide what they want while keeping the technology that they're using. We made it possible to just be able to use either the WebView, which is the default, or you can use Chromium. This is all done via simple flag. It doesn't change. It doesn't make your compilation time any slower while building the app. It just works. We just picked the right stuff for you, and it just makes it work.

So yeah, Ceph obviously gives you more consistency, but it gives you a massive binary. An example binary was like 300 megabytes. We're still trying to optimize it a bit. And WebView is very tiny, like 100 megabytes. For reference, Dino binary itself is like, I think nowadays it's like 80 megabytes. Maybe a bit more, maybe a bit less, not fully sure. But yeah, it's always dependent. So on whatever machine you're on, if you're on a Mac, you're going to potentially see different stuff than you see on a Windows machine, just because on Mac, it would use Safari. On Windows, it was Chrome under the hood. Or you can also just not use an engine.

If you don't want to render a browser window, you don't have to. We have a very lightweight backend, which is the raw backend, which basically just lets you manage Windows, get all the events, et cetera, just like that. You don't get a browser window, but you get a window that you can use WebGPU on. So if you want to render maybe using like three JS to a window, you can just do that quite simply. Yeah, you get obviously no DOM, no Chromium, nothing, but just a GPU window directly. And it's the smallest binary, obviously because we don't have to include a whole browser. Yeah, so if you want to, like, again, just creating a window, getting the GPU device, getting the actual underlying Windows surface that you want to render to, and setting up like Windows Surface is basically just like Canvas. It uses the exact same API. So if you're familiar with Canvas, it just reuses that. And that's how it makes it also compatible with like three JS or other systems that use Canvas.

And yeah, you just configure it and then do whatever magic you want to do and show it to the window. And it will just work. Now, this is like all nice, but what about wanting to debugging your code? So usually, you would have a separate process, like separate debugging for the Deno process or the Node process or whatever, but also then a separate debugging for like the actual browser window, which, yeah, you're juggling the buggers. It's a bit annoying. What if you can just have both in one?

So with dash dash inspect, you will just get a singular debugger window, which shows you both outputs from both processes. You can modify, you can interact with them, you can add break points, you can do everything you're used to with a bugger. Just you can do it for both the browser window and the Deno process, just in one view. You don't have to mess around. And yeah, you can just select it via dropdown in the corner.

There's the renderer, which is the window, like the Chromium window, or the Deno process. Now, this feature only works with the Ceph backend, not with the Chrome backend, not with the WebView backend. We cannot reliably transform the inspector protocol from Safari into the one viable for V8. That's a technical aspect I'm not willing to dwell into translating protocols. So now you want to ship this app. How do you do this? Distribution is always complicated, but we provide different outputs.

We support .app, .exe, and .appimage for the different browsers as the base default. And you can also get .dmg on Mac OS, but we're also adding the .msi and .deb files and .rpm files for Linux and Windows respectively. And we might add some more, but these are the baseline to actually really support nearly most use cases. These are going to be shipping really soon, like in the next few days in addition.

And you want to build for every platform in one machine, because you can just cross-compile, because else this gets very complicated. So you can cross-compile for your whatever machine you want to target. And we support the most common use cases, so Mac OS, Linux, Windows, both on ARM and not ARM, except Windows on ARM is not a thing yet for us. But everything else just works. And you don't need to run CI in different machines and get it working and compile across. It will just work.

There is one slight limitation from the previous tab, is that .dmg is only possible to do on Mac OS. It's a Mac OS-specific tool. So that is slightly difficult to avoid. Now, you want to update. So we have an auto-updater. And this is the API. And yeah, you just, whenever your update is ready, you can just apply the update and roll back. You basically can define the behavior you want to do. But it ships with binary diffs. It doesn't ship the actual full binary. So if you just do a small change, like 4kb, you don't send a whole 200 or 400 megabyte app again.

You just download the difference. This is just done via binary diffs, which is very nice and very convenient for users, especially when the network is very terrible, or they're at a conference where usually it's not the greatest. So yeah, it applies to the next launch that the user relaunches the app. You have the update ready callback, so you can technically force a relaunch and just apply it immediately. Or if the update fails, there's just a rollback.

Then there's also a dnote.desktop version to get the latest version of the app that you are building. Most of these things are configurable via the config file. It's DNO, so it's using all the permission and sandboxing that DNO provides. By default, we're sandboxed, so your desktop app cannot suddenly access the user's file system or et cetera. Obviously it's more interesting for the end user, and not for you. You're probably trying to collect as much calamity data on the user as possible, let's be honest. So you might probably just run this with Dash all. But this is an option.

Since we already have it, why not use it? So where does it land? Again, Electron is the main way to do this currently, but it does not have HMR, it does not have the framework auto detect, and it doesn't have the permission system. Everything else works. Then again, updates, you're gonna send a whole binary again, not ideal. Tory is very nice and small and convenient, but then you're starting to use Rust. Most people don't want to deal with another programming language or Rust. Most people here are familiar with JavaScript and want to stick to JavaScript. So we try to make it the best of both worlds, and not have to touch other languages.

So we try to make it the best of both worlds, and not have to touch other languages. Now, this is just a first look. Today, it's very experimental. It's just in a branch. Well, actually again, it should have landed, hopefully, a few minutes ago, just before this talk. Yeah, it works on all the operating systems. Again, there are some limitations depending on the OS you're on, but we're trying to figure this out. Yeah, it's just a desktop-ready toolkit. You can just call all these things. You don't have just a recap. This is all you have to do. Now, you can actually try this out already. You can use Deno upgrade PR, the PR number 33441, or you can wait until this evening, and it's going to be in Deno 2.8.3, I believe.

There's going to be a release. I know I'm already slightly over time, but I'm going to quickly show one fast demo of an actual working app, because I was not able to show that before. So I actually have an example app I made a few days ago, which is a matrix client. For those that don't know, it's like a chat platform, similar to like Discord or whatever. I have another window here that is my main client that I use myself, and then this one is the actual app, and I can send a message here, and this is running via the dash dash HMR flag as well, so I can modify the code in a moment and show you that.

But if I send a message, it will take a moment and you see that I get a notification on the bottom, and I do have notifications disabled currently during the talk, but I do have a notification that arrived. Let's see if I can show this here. What if I disable that and send another message? It shows up on my laptop. I wish I could show you that, but notifications do work. On this demo app, we also have custom menu. You can start a new room, stuff like that, or we also have this menu. So if I do send again, one more test app, a test message, and I go on here, I have the small panel with that, and I can do whatever I want. It's just another browser window. Yes, this is Deno desktop, and, as I noticed, we're going to push for this, and Deno is Node-compatible. We do pass more than 75 per cent of Node.js tests. You don't need to be in the Deno ecosystem to use this.

You don't need to be in the Deno ecosystem to use this. You can just use this from your current Node.js app. So please, do test it out. APPLAUSE Can Deno integrate with the OS's native design system, so buttons, dialogues, input fields, like Mac OS, Liquid UI, or Windows UI? Currently not, but we've been discussing it. It's a different world of pain to implement, and currently, our system is based on browsers, and the one back-end is nothing. But we're considering, actually, like there is already one project that does this which is NativeScript, and let's first start with competing with Electron. I don't want to compete with multiple projects at the same time. That's a big can of worms, but maybe in the future.

Great. I love how smooth it looks to build for browsers, so that's a great one. Next question from Jan. According to the output of Deno desktop, the command size of the empty Next.js app is around 395 megabytes. How much smaller is the production bundle, and is that different from Electron in that regard? Yes, so the bundle is one thing we're still optimising. Right now, what you saw, it was including the whole Node modules directory, so basically including everything that you probably will never touch. We do have a patch for that ready. It's just not part of there yet. And you will just be able to actually bundle, and then use that. Or, I mean, you can also just run your own bundle step and not use the framework detection, and just call Deno desktop on your directory as long as there is an HTTP server that's running on it. It will just work. But we might also add just for static directory, just being able to call Deno desktop on that, and you can just use it. Very cool. So coming soon.

Will Deno support top menu bars and native sidebars? Top menu bars and native sidebars. Not sure what that entails. If you mean with top menu bars, like the top nav bar that I showed doing the demo? I mean, yeah. With native sidebars, I am not quite sure what you mean with that. Okay, well, you will be able to chat to Leo afterwards in the deep dive section, so do go with that question for him. But I'll move on to another one. Leo, what limitations exist with the raw back-end? Are workers, audio and other features supported? Okay, so currently not.

Okay, so currently not. That is something that will change because basically, you're all on the Deno side. We don't have a browser. So Deno is gonna implement these APIs for the desktop system. It's not gonna be like a normal Deno execution, like having audio APIs, that is out of scope for Deno itself, but for desktop system, it makes sense. So, currently, no. The limitations are just, yeah, you don't have a browser. You just have a native window and whatever Deno APIs provides. Cool.

And somebody has said, Leo, this looks awesome. When can we run the apps on Android slash OS X? Actually, this is something we're considering. We can actually compile this to iOS and Android. It's just, we need to experiment with this more, but it is something that we are looking into and seems viable. Awesome. Does it support the borderless windows? Yes, the window constructor has a lot of options. You can modify the window, you can make it borderless, you can hide the top bar and not make it borderless, but still have the controls, hide the controls. It's like Electron, relatively similar in terms of what you can change. Maybe a few things are still missing, but we're still expanding on it. Again, this is experimental. We need people to try it out. Very cool.

Get experimenting. How does the native app compare to a PWA? Not quite sure. Oh, I see. I mean, a PWA, as much as people like them, they never really took off. I mean, PWAs on desktop, I feel like, are not as common or popular. Most people maybe use it on iPhone, but even then, most people don't use a PWA at the end of the day. Okay, interesting.

Somebody has commented saying the app works and launched. The title showed My App. What about keychain support and the users trying to migrate from Electron to Deno, keychain migration? Not too sure what you mean with that. If you mean like the keychain, like accessing the system keychain, we don't have an API for that yet, but that's one of the next steps that we're adding. Deno already has this under the hood, so this is actually relatively simple for us to add. Okay, cool.

Just a case of exposing it. Awesome. And which rendering engine is it using and which CSS features are supported? Well, the rendering engine depends on which backend you pick. So if you pick the Chromium or Ceph backend, you get whatever Chrome supports. If you use WebView, then good luck figuring out what you can because whatever system your users are running on, that's what you're going to get. So if you're on Mac OS, then whatever Safari supports, good luck. Thank you. I've got one final question.

If I could just ask the people leaving and coming in to be quiet while we listen to the final answer from Leo, which is about using the no engine option. So if you use the no engine option with Deno Desktop, does it mean that the UI consistency is not guaranteed? I guess the UI between the different... I mean, no engine would be the WebGPU backend. Let's say the raw backend, that one does not have a browser engine at all in the backend. So there is, yeah. I mean, it's not inconsistent. It just isn't there. You just use it to, like, if you want to make a game, that's what you would use, that raw or WebGPU backend, because you just want pure GPU compute power and not like a browser. Okay, cool. So it's all completely dependent on the context of what you're building. Yeah. Super helpful. Thanks so much, Leo. Can we have one more round of applause for Leo? Thank you.