The Latest From Deno

I will be talking about making desktop apps with Dino now. This was landed five minutes ago. Let's get into it. So first off, yes, I'm Leo. I work at Dino. I do developer experience, web APIs, maintain JSR if you use it, and as of very recently, also a TC39 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. And 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 the JS ecosystem.

And since we're JS Nation, I assume most people here want to be able to use NPM, the frameworks, node compatibility, everything you're familiar with. So the problem is nowadays, most of the things, you're stuck with two of these options. You cannot get all three of them. But the trade-offs usually are with Electron, it's a massive bundle, including all of Chromium. That is not small. But if you use Aria on the Rxs, you get small binaries because they use the system webview.

But because it's webview, it's inconsistent, and you don't get the JS ecosystem which is quite a drawback. And yes, 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 denodesktop. You literally have to call denodesktop and it will turn your app into a desktop app.

This is a 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. And very buggy to some degree still. That is bound to be. That's why we land it as an experimental feature. We want you to try it out and give us feedback.

So denodesktop. You can point at any of the frameworks that you're using. If you're using Next.js, you can just use that. And you just call denodesktop. You just get a desktop app, like an exe, a .app, just an executable in 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 DNServe, 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. For example, here, we just have denodesktop, this main TS file, just an Express app, and you get a very terrible desktop app because there's no styling. It's just bare HTML with a 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 mean, 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 network collaborates, else we go to the backup. Please? Okay. All right. And we get pretty standard Next.js app as anyone has seen, so I can cd into my app, and, yes, it's just the standard stuff. So let's turn it into a desktop app. I have a separate binary here that's r underscore dino, 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 rdino. That is just dino local that I use. Anyhow, it's rdino desktop. I'll scroll down a second for you. I'm going to pass the dash A flag, because Next.js asks for a lot of permissions, and I'm not going to 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... When did it launch? That's where the demo gods decided not to cooperate. Let me launch it again. Trust me. Trust me. I tested this beforehand, and it was working completely fine. 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 Dino Desktop also has an 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 gonna 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. But 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. Oh, come on. Hmm.

Okay. So imagine this worked. Again. I should have done 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, just 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... Oh. Am I... That's... Wait a second. There we go. Sorry. So, yeah, so 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, like, a desktop app. And, we do have... Like here's a bit of an example. You can just create a browser window at a binding.

So bindings let you call functions from the Deno site in the browser. 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 gonna support more. So again, native dialogues, notifications, system tray, so you can interact fully with the system tray. Binding is supported on most of the operating systems, so it works on Linux and Windows. There's some limitations on Linux 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're adding more stuff. This is just, like, the first pass that we implemented. Bindings are not IPC like in Electron or Tauri, where basically backend talks via a cross process serialization socket. We actually are in the same process. So this gives some benefits that we can transfer data between the browser and Deno very efficiently, very fast, and under the hood, as far as I remember, Electron actually only supports strings and just does its own serialization. You can move a JavaScript type back and forth. With some limitations, but there's more that can be done then 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, 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. It 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.

I mean, with Electron, you're stuck with WebView, with Chromium. With Tauri, you're stuck with WebView. What if you want to pick? I mean, people should have the power to decide with what they want while keeping the technology that they're using. So, 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 just a simple flag. It doesn't change. It doesn't make your compilation time any slower while building the app. It just works. We just pick 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, like an example binary was 300 megabyte. 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 at like 80 megabytes. Maybe a bit more, maybe a bit less, not fully sure. But yeah, it's OS-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, like, 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. I mean, 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 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, 3.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 the whole browser. Yeah. So, if you want to, like, again, just creating a window, getting the GPU device, getting the actual, like, underlying Windows surface that you want to render to, and setting up, like Windows Surface is just like Canvas. It uses the exact same API. If you're familiar with Canvas, it just reuses that.

That's how it makes it compatible with 3.js or other systems that use Canvas. 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 all nice. But what about wanting to debugging your code? So, usually, you would have a 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 debuggers. 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, I don't know, add breakpoints. You can do everything you're used to with a debugger. 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 either 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 Chromium backend, not with the WebView backend. That's just because we cannot reliably transform the inspector protocol from, like, Safari into the one viable for V8. That is a technical aspect I'm not willing to delve into translating protocols.

So, now, you want to ship this app. How do you do this? Distribution is always complicated, but, yeah, we provide different outputs. We support dot app, dot exe and dot app image for the different browsers as the base default. You can also get dot DMG on macOS, but we're also adding the dot MSI and dot dev files and dot RPM files for Linux and Windows, respectively.

You might add some more, but these are the baseline to really support nearly most use cases. These are going to be shipping really soon, like, in the next few days in addition. 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 whatever machine you want to target, and we support the most common use cases, so macOS, Linux, Windows, both on ARM and not ARM, except Windows on ARM is not a thing yet for us, but everything else just works.

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 dot DMG is only possible to do on macOS. That's just because it's a macOS-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, yes, whenever your update is ready, you can just apply the update and roll back. It basically can define the behaviour you want to do. But it ships with binary diffs. It doesn't ship the full binary. If you do a small change, 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 yes, it applies to the next launch that the user relaunches the app, but you have the onUpdateReady callback, so you can technically force a relaunch and apply it immediately. Or, if the update fails, there's just a rollback. Now, yes, then there's also a dno.desktop version to get the latest version of the app that you're building. Most of these things are configurable via the config file.

And, yes, it is dno, so it is using all the permission and sandboxing that dno provides, and by default, we're sandboxed, so your desktop app cannot suddenly access the user's file system, or et cetera. Obviously, that'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 autodetect, and it doesn't have the permission system. Everything else works, then, again, updates, you're going to send a whole binary again, not ideal. Tari is 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. Now, this is just a first look. Today, it's very experimental. It's just in a branch. Actually, again, it should have landed, hopefully, a few minutes ago, just before this talk, and, yes, it works on all the operating systems. Again, there are some limitations depending on the OS you're on, but we are trying to figure this out. Yes, it's just a desktop-ready toolkit. You can just call all these things. You don't have to 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 of you that want to know, it's like a chat platform, similar to 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. Let me try. 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. MacOS does not let you set where notifications show up, and 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 like this 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 can use it from your current Node.js app. Please, do test it out. Thank you.

Can Deno integrate with the OS's native design system, so buttons, dialogues, input fields, like macOS 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 backend is nothing. We're considering, actually, there's already one project that does this, which is NativeScript. 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.

According to the output of Deno Desktop, command size of the empty Next.js desktop app is around 395 megabytes. How much smaller is the production bundle, and is that different from Electron in that regard? Yeah, so the bundle is one thing we're still optimizing. 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. 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's an HTTP server that's running on it, it will just work. Though we might also add, just for a static directory, just being able to call Deno Desktop on that, and you can just use it.

Does 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 during 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 backend? Are workers, audio, and other features supported? Okay, so currently not. That is something that will change, because basically you're all on the Deno side.

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 backend? Are workers, audio, and other features supported? 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 going to implement these APIs for the desktop system. It's not going to 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, okay.

And somebody has said, Leo, this looks awesome. When can we run the apps on Android slash OS X? Actually, this is something we are considering. We can actually compile this to iOS and Android. 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, there's, like, 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.

How does the native app compare to a PWA? Not quite sure. Oh, I see.

Oh, I see. I mean, a PWA, as much people like them, they never really took off. I mean, PWAs on desktop I feel like are not as common or popular. Most people use it on iPhone, but even then, most people don't use a PWA at the end of the day. Okay. Interesting.

And the app, somebody's comment is saying the app works and launched. The title showed my app. What about keychain support and for users trying to migrate from Electron to Deano, keychain migration? I'm 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. Deano 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 back end you pick. So if you put the Chromium or Ceph back end, 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 are on Mac OS, then whatever Safari supports. Good luck. Thank you. I've got one final question.