Hi, I'm Ryan Dahl. You might know me as the creator of Node.js. As a programmer, I like things that are simple. Really simple.
Programming should be simple. That's why I created Node. But these days, Node is not simple. Just ask Rachel. She's been here for days.
Setting up TypeScript is an easy 47-step process. First, you take a TS-Config file. You take a TS here and add an ES in front of it. Then comes a JavaScript target.
Don't forget Al Gore! And here's Steve commemorating the 20th test framework he's recently learned. Please be gentle. Okay. I'm good.
Getting Node APIs to work in the browser can be... Ugh! Frustrating. Security is also a nightmare.
NPM packages have access to everything. But you can be a faster, more productive developer with Deno, the simplest way to program. Deno comes with TypeScript, all-in-one tooling, and web-standard APIs, so you can write once and run anywhere. Anywhere? Anywhere.
Deno is secure by default, so every dependency doesn't have full access to your computer. And you don't have to give up the packages you love from NPM. Yeah. And many more.
So join hundreds of thousands of developers using Deno. Because programming should be simple. Hi, my name is Ryan Dahl, creator of Node.js and Deno.
Today, we're releasing our biggest update yet, Deno 2. Let's go check it out. JavaScript is the world's default programming language. It's deeply rooted in human infrastructure because it's part of the web like HTTP or CSS, and it's not going away anytime soon. It's going to be here five, 10 years from now, if not 20 years from now.
Because of that, we are building on JavaScript. We want to make it great. Deno is a runtime for JavaScript development. It natively supports TypeScript as well.
And it tries to narrow the gap between browser JavaScript and server-side JavaScript. It uses web standards, ES modules, fetch API, all sorts of stuff. It is an all-in-one toolchain for JavaScript development that's really batteries included. It has all of the utilities you need. It's secure by default and backwards compatible with Node, and we'll see that in action.
Deno is the simplest way to get started programming TypeScript. You can really just open a single file. You don't need to create a package JSON or have a node modules folder. A single file is all you need to get started.
Let's see that in action. I'm going to create a LS program, listing the files in a directory. Let's see how that looks in Deno.
Let me just create a main TS file, and Let's open up VS Code. So to list the files in the directory, there's an API called dino.readdir. This is one of the built-in Dino APIs, and it takes a path as an argument.
You can see the built-in documentation working here, and the built-in language server giving me a red squiggly because I don't have any arguments. So I'll give just the current directory dot as the argument to start with. And this thing is this command, this function.
returns an async iterable that lists the elements in the files in the current directory. Let's try to loop over these using an async await, entry const entry of dino.readdir. For now, let's just console log that entry out. So if we run dino, main TS, you'll see the secure by default permission prompt in action here. So we're trying to access the file system.
Deno doesn't allow you to do that unless you explicitly give it permission. You need to give it the allow read flag or say yes at this prompt. If you do, it will work.
But often you don't want to click through a bunch of permission prompts. You probably want to give the allow read flag that lets you do this. Or the shorthand version of that is. dash capital R to give the allow read permission.
Let's expand this a little bit instead of using dots as the hard-coded directory that we're going to list. Let's actually take an argument from the command line. So we'll use dino args 0 here.
We can of course do dot or we could do, I don't know, a different directory that has a bunch of files in it like this one. Let's abstract this a little bit further, turn this into a function. So tree, we'll call it tree. And let's say it takes an argument called dir, that's a string.
And let's say this tree function just returns a bunch of strings in an array of each of the file names. So we'll move that loop up here. And you can see that we're getting some red squigglies here from the language server.
is saying that we're doing a for await loop outside of an async function. So let's just add an async here. By the way, you can see these same errors if you do dino check. So just to back up a bit, we'll do dino check main TS, where you can see these same errors.
But it's often more convenient to see this in the LSP. It is... complaining because i'm not returning a promise of course it's an async function so let's add a promise there and it's still complaining because i'm not actually returning anything duh so const out equals empty array and we'll just push out and entry is actually an object let's let's actually output the the name of the just the name of the file there and and we'll return return out at the end. And then of course we need to call this thing.
So let's say await tree and we'll do dno args 0 here. And let's just console log out those files. And I'm realizing that I'm actually not using the argument here. I should move change this to a dir. and yes, red squiggly because I'm missing a parentheses.
Okay. So how does that look? Yeah.
All right. So now we've kind of abstracted this out into a function. As I said, Deno is an all-in-one runtime, and it combines a lot of disparate tooling that you need from in the Node ecosystem into a single binary. Deno is literally a single file.
So for example, you might use prettier in Node to format your code. In Deno, it's just Deno format. Or for type checking, you might use TSC. In Deno, it's just Deno check.
Or maybe you use ESLint in Node. You can do the same thing with DenoLint and many more. Let's take a look at one of these subcommands in more detail, Deno compile.
So, This actually takes your JavaScript and bundles it together with the runtime and creates a binary output, just called the dino compile subcommand. And as you can see, it has created this demo file here, which is an ARM64 Macintosh executable file. And we can just call that like we would any other program.
Of course, we need to give a proper file name here, and it works as normal. So you can distribute this without Deno, and it will continue to work indefinitely. It doesn't depend on any other files.
One cool feature of Deno Compile is that it can actually cross-compile. So if you do dash dash target, it will give you a list of possible platform targets that you can give to it. Let's try to cross-compile this program for Windows. So we'll do an x64 Windows binary, if I can spell target correctly. And as you can see, we now have a demo.exe file that is appropriate for running on Windows.
I don't have a Windows computer here, but suffice it to say this demo.exe is appropriate for running on Windows. But you could do all of that with Deno 1. Let's talk about Deno 2. Deno 2 is a revamp in multiple areas. Ecosystem compatibility, package management, and enterprise features. Let's start with ecosystem compatibility.
One of the things I've heard the most from users of Deno is that they love how simple Deno is. They don't have to have any configuration. They can just get started with TypeScript.
But inevitably, they come across some existing node project that they need to interact with, whether it's an NPM library or some existing project. Deno 2 is fully backwards compatible with Node when using ESM. Deno 2 understands your package JSON, Node modules, and npm workspaces.
Npm packages are supported, even complex ones like gRPC, or ones that use native extensions, the so-called NAPI. This allows you now in Deno 2 to incrementally adopt Deno. without doing an overnight stop the world full migration.
To see a complex node application running in Deno, let me show you create next app. So create next app, of course, creates a boilerplate Next.js application. Normally, you would do npx create next app. In Deno here, I'm actually going to deno-a npm create next app.
Yeah, we're going to run kind of the creation script and let's choose all the default options here. And wait a second while NPM installs it. It takes a while because NPM is slow. We'll see how to alleviate that in a second. Possibly the internet is slow.
Possibly I don't have internet. Okay, I do have internet. Here it is actually forking out to Node and using NPM. But when we're done, we finally have this my app folder with a Node modules folder in it, of course, and a package JSON, a typical create next step.
In Deno now, Deno understands all of these things. So you can run Deno task and you'll see a list of available commands here like Deno dev, and build, and start, and lint. Let's run the dev server now with Deno.
So Deno task dev will actually start the Next.js dev server here at port 3000. Yeah, you can see it running. Just to clarify that this is working correctly, let's just edit. this page TSX file and we'll just say get started by editing and write Deno instead here.
And yeah, hot module reloading works. All of this is being executed by the Deno runtime. It's not just Next, Remix, Astro, and many other frameworks are supported by Deno.
In addition to full backwards compatibility with Node applications, All Deno programs can now import node libraries in the form of NPM packages without requiring a package JSON or node modules folder, and secure by default execution is maintained. Let's take a look at this in action with our LS example here, and let's just try to make some color output using the NPM Chalk library. To do that in Deno, you can just do import Chalk from NPM colon Chalk. Note, auto formatting is happening in the background, and we can just use chalk as normal.
So chalk, say BG blue for a blue background, and files is actually an array. So let's just join that with new line character. So Dino main TS, running this again will hit this permission prompt. So what's happening is that chalk is Trying to access various environment variables. Force color here, let's allow that by saying yes.
TF build, let's allow that. Term, CI, TeamCityVersion, color term. If we say yes to all of those, we do finally get the proper output here with blue background color. We can avoid those permission prompts by adding in allow and flag. and then we don't get those or just a dash capital E for short, Deno-RER.
But actually there's a better way to do this in Deno. Let me show you how you can get color outputs just as an example of how Deno uses web standard APIs, how you can get color output in a way that also works in web browsers. So console.log%c, actually allows you to supply some CSS.
So we'll do files join backslash in, and we can just say background-color, let's change it to red. This should give us our red background LS for whatever reason you might want that. This doesn't actually read any environment variables, so we can remove the allow and flag from the execution. Just to recap, in Deno 2, you can run existing Node applications.
Deno now understands your package JSON and Node modules folders out of the box. And if you're not using package JSON, Deno allows you to use the full breadth of NPM libraries in your Deno code without any configuration. and allowing them to be secure by default. And that's ecosystem compatibility.
Now let's talk about package management. With Deno's support of package JSON and node modules, we've added three new subcommands to help you manage these. They're really similar to NPM. You should basically immediately know what they do. Deno install, Deno add, and Deno remove.
Deno install inspects your package JSON and installs dependencies, but really, really fast. When you have a package JSON, Deno will install your dependencies in the node modules folder, creating one in your project tree. If you don't have a package JSON, it will look at your Deno JSON file, find any dependencies in an import map, and cache those globally. Deno add and Deno remove are...
Really simple subcommands that add and remove dependencies from a package JSON or a Deno JSON file. Let's take a deeper look at Deno install. We're back in our create-next-app where we have a node-modules folder that create-next-app created. Actually, npm install created this. Create-next-app ran npm install.
This is a folder that has roughly 319 megabytes of dependencies. Let's see what dino install does by just removing this directory and then running dino install. It happens really fast. Now we have a new node modules folder with the same size as before.
And of course, you can run Next.js by running dino task dev. That's what dino install does. But if this was all there was to package management in dino, this would be pretty disappointing, which is why it's not. Let's talk about...
JSR, the successor to NPM. JSR is a new package registry where you can publish JavaScript code and share it with people. And it's not just JavaScript.
TypeScript is also supported. JSR is meant for the future. It is a registry that is not just for Node, but for all JavaScript runtimes. And we need a registry that can support all of those different runtimes.
JSR only supports ECMAScript modules, not common JS. So kind of forces you into the future in a certain way, and is really designed to work with NPM. and not against it. So meaning that packages in JSR can actually have NPM dependencies.
So in a sense, it's a superset of NPM. JSR, of course, provides really great developer experience for consumers and publishers of packages, and we'll see that in a second. Deno's standard library has been developed over the past four years. It's a great set of utility functions in all sorts of areas. And we have now stabilized the Deno standard library to 1.0 and published it to JSR.
Also, this set of libraries is not just for Deno now. You can actually import a lot of the standard library modules in Node and other runtimes. So instead of needing to know all sorts of different NPM packages, you can actually just use the standard library.
My hope is that this can serve as a base and help level up JavaScript. So, for example, instead of using Jest, you might use Testing. Or instead of using Chai, you could use Expect. Or for command line flag parsing, maybe instead of using Minimist, you can just use CLI. Or instead of Lodash, use Collections.
And many other packages are available. Let's make use of one of these standard libraries. the file system library and we'll try to use that to improve our LS demo.
So let's just go to the JSR website and search for stdfs. This has various file system functionalities, helpers for file system. Let's search for walk here, which gives you the functionality to recursively walk through a directory tree. It's really similar to the Dino Reader. except it's recursive.
So it also takes a string argument and returns an async iterable. Let's make use of this by just copying this import here and pasting it into our demo. We can make use of it basically immediately by replacing the dino readdir with walk.
And that's all that we need to do here. We can just run this code now and you might notice that there's quite a few more files now. Let's actually change, so it's entry.name is just the file name, but if we do entry.path, we'll actually get absolute paths of all of these things and you can see that it's kind of recursively jumping into like the the jsr directory in this case.
Let's actually make those absolute paths into relative paths by using one of the node built-in libraries, node path. Just to give you a sense of what it's like to pull in node built-in libraries. So you can import relative from node colon path, a library that I assume many people are familiar with.
And all we need to do here is replace this entry path here with relative. dir, entry path to actually make these relative paths. So that's all there is to pulling in JSR dependencies.
Again, we don't need to create any extra files. There's no node modules folder, there's no installation at all. It happens automatically. Let's say we want to publish this and share this tree function with people.
Let's see what it's like to actually publish to JSR. So all I need to do here is go into my JSR window, my browser, and click Publish. And I'll publish this under the RIScope and the package name, let's call it Demo. And when you click Publish, publish here it's going to give you a little json snippet that you can drop into jsr.json or dino json and let's just create i'll do a dino json so i'll create a dino json file and i'm just going to update the version here to to version 3 because i've tried this before and uh yeah the exports actually i don't have a mod ts but a main ts file so let me modify that And then in my main TS file, I need to export this function. And I don't actually want these two lines here at the bottom to execute on every time you import it.
So I'm actually going to wrap those in if import meta main. And yeah, we should be ready to publish. So all we need to do is run dnopublish. And I'm getting two errors here.
The first one is on line one with this JSR import. I don't have a version specifier. So it's fine to import packages from JSR and not have a version constraint. But if you're going to use those packages and publish a library to JSR, you actually need to be a little bit more specific about what version you're depending on so that we can resolve those packages concretely.
And we'll depend on version one, semver version one of that. The other thing it's complaining about here is a missing license field in my dino.json file. So let me add license and we'll just call it MIT.
And let's run dino publish again. I need to authorize this publishing. Again, I'm logged into the website and we have some security constraints on JSR.
Wait a second, and yeah, this is now published. So you can see the doc generation happening here, and you can see the tree function has been published to JSR. There's no actual JS doc or documentation for this yet. Maybe I'll just show you what it's like to add some docs here. So let me add some JS docs.
So we'll just say recursively list out files in a directory. All we need to do then is bump the version and run publish again. Approve it.
Wait a second. There we go. Now we can see the doc string represented in the auto-generated documentation.
To recap package management improvements, we've added three new subcommands, dino install, dino add, and dino remove to help you manage package JSON or dino JSON files, the dependencies in them. We've introduced JSR, a modern registry for publishing JavaScript and TypeScript code that supports all runtimes. We've stabilized the dino standard library to Semver 1.0 and published it to JSR. and made it available to all of these different runtimes out there. That's package management.
We've been talking to a lot of users at larger companies about their usage of Deno, and the feedback that we've received is that it's great, but there are a couple of missing points. Private registries, Mono repo support. and stability guarantees or long-term support. So let's talk about each of those.
First of all, private registries are now supported in Deno2, essentially in the same way that they're supported in Node. You can add a.npmrc file, use the same syntax that you do in Node, and you can access your company's internal private registry server. Easy as that.
You can pull in those private. NPM packages. Deno Workspaces is similar to NPM Workspaces, in fact, interoperates with NPM Workspaces, but essentially is monorepo support.
It allows you to have multiple packages in a single monorepo, and Deno Workspaces lets you mix and match package JSON modules and Deno JSON modules. seamlessly and has the great developer experience that one knows and loves from Deno. We've seen that larger, more mature development teams can't upgrade at the same cadence that we are releasing Deno minor releases.
We release every six weeks. So to help support those teams, we are introducing long-term support branch, LTS releases. This is going to start with Deno 2.1, which will be released in October, and we will be backporting critical bug fixes to this branch for six months. This LTS release, of course, will be MIT licensed, freely available like the rest of Deno, but is largely aimed at companies that need to kind of vet individual binaries or have processes for introducing new versions.
We have additional enterprise support, commercial support available. You can learn more about that at dino.com slash enterprise. I want to touch on Dino's performance. Dino's performance is great.
For instance, Dino's HTTP server has almost twice the throughput as nodes. JavaScript runtimes are multifaceted and have lots of different functionality. And so it's hard to sum it up in a single number or a single graph.
But here are a number of benchmarks that give you some broad idea of how Deno performs. Overall, Deno performs fantastic. And there's much more.
We're just scratching the surface here. We haven't talked about WebGPU. We haven't talked about... Deno's documentation generation.
We haven't talked about our FFI or Fresh or Deno Deploy. I do want to leave you with one more demo here on our Jupyter Notebook support. So I'm going to just open up Jupyter Notebooks, and I'm going to create a new notebook.
All you need to do is switch the kernel from Python, the default of course, to Deno, and you can now execute some Deno code. What I'm going to do is pull in observable plot and plot some stuff with JavaScript. So let's do that. So import star as plot from npm colon observable HQ slash plot. Let's make sure that works.
Yes. Observable plot is just a fantastic graphics library for analyzing data. I need a little bit of data to analyze, so let me pull in a dataset called penguins. So import penguins, penguins from, and this is just a little library that I have called Jupiter-helper. on JSR.
Penguins is an async function that returns some data. So I'll just await penguins and let's see if we can actually load some data here. Yeah. So here's a table.
This dataset is a bunch of measurements of penguins, just a sample dataset. We need one more object here, which is a document object in order to interact with observable plot. So let me assign this penguins dataset to p here.
Let me print it out again just so I can see. Yeah, let's do a scatter plot with two rows of this data here. So observable works like this.
You do plot plot and you give it some marks, which is an array, and you give it this document. Inside of marks, if you want to do a scatter plot, do plot dot, and we'll just do p2 records to get our penguins data set in the right format. And then we just need to give it x and y coordinates here. Yeah, let's just say const x equals Coleman length.
I think this is some measurement of a penguin's beak size maybe. And I don't know, let's measure it against flipper length. Const y is flipper length. And yeah, there we go. We have a scatter plot.
It's black and white. You know, maybe not so interesting. Maybe we can add some color here and kind of color it based on species.
Suddenly, you can see three different species of penguins broken out by their flipper length and beak length. Just to take everything full circle here, let's pull in that tree function that we just published to JSR and plot a directory tree with that. First of all, import tree from jsr://dino2-demo. Let's just make sure this works. So await tree users, rye, src, dino, runtime, my favorite directory.
We've got an array of data here. Let's assign this to a variable files, let's say. Let's do some observable. Observable link.
So plot plot marks is in array, and we'll just do plot. tree and we'll give files here and again document. Suddenly you have a visual representation of a file tree.
Can maybe even clean it up a little bit more by turning off the axis and giving it a margin. But yeah, same thing. Observable is super cool. Check it out and it interacts very nicely with Deno and Jupyter Notebooks. Like I said before, there's so much more to Dino.
We're just scratching the surface. Dino is ready for production now. I can't wait for you to explore it.
And by the way, we're also introducing a new logo, so check that out. Thanks, everyone. Hello, everybody. This is the Dino team streaming to you live from a hotel conference room in Dublin. I'm Jo, I'm the dev rel here at Dino and I'll be our host for this live stream.
I hope you're super excited about Dino 2, I know we all are. The whole team were actually here together for an off-site that was happening. We're in Ireland, it's about 5.30pm for us at the moment, but we thought we'd take the opportunity to open the floor up to the entire... team to your questions.
We're looking forward to hearing what you're excited about, what you'd like to know, and you can get the chance to actually ask questions of the engineers who've built the runtime that you love. But before we get to the questions, let's actually introduce the team. They'd really love to meet you all as well and hear a little bit about what everyone has worked on. So first up, let's have Luca. Hi folks, I'm Luca.
I've been working at Deno for actually ever since the 1.0 release and I've been been working on Deno 2 for a while, mostly on node crypto upgrades and JSR. Yeah, I want to introduce Divya next. Hello, I'm Divi.
I worked on framework compact like Next.js, Astro for Deno 2 and Deno Compile. And yeah, I'm really excited about Deno 2. Yeah, David? Hi everyone, I'm David. I work on the CLI team.
I've worked mostly on workspaces and NPM resolution most recently. And Nathan? Hi, I'm Nathan.
I've been working on node compatibility like Angular and Playwright. Also the dino install subcommand and the dino serve parallel option. Gus?
Hello, I'm Gus or Snek. Been at Deno for a few months. I work on CLI on node compatibility like the node API and async hooks.
I also work on maintaining and upgrading our JavaScript v8 bindings. Keep those nice and fresh. Next we got Josh.
Hey, Josh, front-end developer at Deno. I have been working mainly on the website and the new Deno brand and docs here and there, lots of other fun stuff, especially in tandem with our designer, John. Hey, I'm John, product designer here.
I work on Docs and JSR and DenoDeploy and some other new stuff that we haven't seen yet. So yeah, I guess we go over here. Hey, I'm Leo.
I work on JSR, web APIs, and a bunch of docs and doc generation stuff. And here are Bartek, Rai, and Bert. I see a lot of folks on the livestream asking about how they can get stickers. If you would like to get some stickers, if you contribute an example to our doc site we will happily send you out some stickers, so get contributing. But team, introduce yourselves.
Hi, I'm Bartek. I'm the team lead for the Deno CLI. I've been working on Deno for over five years.
And I wrote stuff like Deno Bench or Deno Tech. test DinoLint, but I pretty much touched everything there is at some point. Ryan?
I'm Ryan. You just listened to me stutter through a prolonged introduction to Dino. Hopefully it wasn't too painful. Somehow I've become a marketing mascot for this company.
But yeah, also co-founded it here with Bert. Yeah, I'm Bert. Ryan and I go back more than a decade.
to the early days of Node.js actually where you know Ryan of course invented that and I was involved in the development of libv and porting it to Windows. Bert actually made it possible. Yeah.
Together with Igor by the way who is in the back of the room to introduce himself. I forgot to say we have of course also got the deploy team with us here today. Say hi deploy team.
Awesome so let's jump straight in. with the most important question, which has come from the chat, which is, Ryan, how did you manage to code all of that without Copilot? I think I did have... Co-pilot on in there, but maybe I disabled it.
Yeah, really, I practice live demos like many, many times. Still stutter through them. Excellent. So first of all, a question from me. What are the challenges?
changes that you're most excited about that have come in from dino 2 uh like do you do you have a personal favorite each of you oh i love all of them honestly that's cheating uh sure it is uh well Well, I believe I'm most excited about giving folks the ability to run their existing projects that were probably offered for Node.js with Deno with little to no changes. That's a huge thing. I really like JSR.
It's fantastic. The NodeCompat stuff is good and necessary, but it's more fun when we can kind of push the envelope of what's possible in JavaScript. Yeah, for me it would also be exactly that.
The compatibility with the ecosystem in a broad sense is really important for me. I also really like workspaces to be honest. I think it's easy to forget that.
I think it's very useful. Nice, awesome. Some cool things for people to look out for, particularly for Arduino 2. So there's been a couple of people asking in the chat, what's happening with bundling? in Deno 2. Is that something that's going to be supported?
What's the plan? Well, the plan is still in the works. As you folks probably know, we deprecated and removed Deno bundle, but we're not giving up on it. We're just regrouping here and figuring out the best solutions so we can actually cater to your needs and satisfy what you want to do when bundling with Deno. So stay tuned for some news.
This is a very hard problem. in general. And we've had a simple solution that just compiles all of your code into a single file, and that's nice for some use cases. But in general, for websites, bundling is a very, very difficult problem. And Deno is more focused on executing JavaScript than solving this other very difficult problem of bundling.
And we are not satisfied with how Deno bundle operates. and didn't feel that we could contribute something that was state-of-the-art for website bundling and so removed it so will we we acknowledge that this is an important part of the JavaScript tool chain but yeah we are going to be looking at how to improve that situation in the future it you know I I think this this might mean shelling out to to some other bundler like ESBuild. It might mean kind of working with, yeah, there's many projects out there that are attempting this and we'll integrate that somehow into the overall Deno tool chain, but that's not here in Deno 2. Cool.
And there's a few people asking about compile. So are we going to be able to take the node tools, like things that require a node installed, compile them and then remove the node required? for end users?
Oh that's a tough one. Well, it depends on the particular tool. It's hard to say en masse that all of them will work, but that's certainly possible for some of them.
I think ESLint might be a good example that could be compiled down and not require Node anymore. But yeah, pretty much you need to evaluate on the tool by tool basis because these tools are really complex and they do a lot of intricate operations. So can't really promise that all of them will be able to be compiled down without Node.
And there was a lot of people asking about Electron. and desktop apps, are we going to be able to build those? So Deno does have some pretty interesting support for windowing.
And I'm blanking on the actual suite for binding a window. What if you window surface? There's unsafe window surface. Unsafe window surface.
And Divi's got some demos. out there of kind of drawing native applications. And I think the very interesting ones are taking WebGPU without a browser and kind of drawing a window directly on there. He's got like a Flappy Birds demo that is GPU accelerated and drawing on a desktop and can use Deno Compile and compile down into a binary. But actually it doesn't use, it's not bundling a browser at all.
Electron-like capability is likely you want to have a web browser bundle along with that and I think would require more infrastructure. But I think this can be built with DenoCompile. with some work.
Awesome. And this is maybe a difficult question off the top of your head. Do you know how big the compiled runtime is?
It's, I think, 60 megabytes or so on Macintosh. I think it depends on the platform, which you might balk at if you're a Go user and seeing a Hello World demo that is a couple of kilobytes large. But it is the full JavaScript runtime.
So the way that Deno compile works, is it kind of takes your JavaScript and attaches it to the end of a slimmed down Deno binary. It's not compiling your JavaScript into assembly. That's not possible. JavaScript is a very dynamic language. But frankly, does it really matter, like 60 megabytes?
I think it's a kind of academic argument. It might matter in certain situations, but in those certain situations, JavaScript's probably not the right tool for the job in the first place. And somebody asked, I don't actually know, can we install Deno with Homebrew at the moment?
Are we planning to be able to install Deno with Homebrew? Oh, yeah, certainly. Not right now.
We released Deno to literally a couple hours ago. And Nathan back here is working really hard to provide the Homebrew build. So expect it to be available maybe in a matter of hours or maybe in a couple of days. But, yeah, it's getting done. Awesome.
That's really cool to hear. And there was a. There's a lot of love for fresh happening in the chat while the video was streaming.
So what's happening with fresh and is there going to be a fresh two? Fresh two is coming. We've been working on this Deno two for a while now, but it's, you know, we're dotting our I's and crossing our T's. So yeah, stay tuned. And how about deploy?
Does deploy support Deno two? Not yet, but we are. Not this hour, but maybe.
Maybe in the next hour. Very soon now. Very cool.
Very cool. Okay. And there's somebody asking, does Deno work with Playwright?
Yeah, it does work with Playwright. Certainly Linux, Mac. So just try it out and you should be good to go. Excellent.
And what else have we got in here? Does DenoCache completely replace the timeout warmup in? containers now? Oh, that's a tough one.
I don't think DenoCache produces the V8 code cache. No, it does not. However, you can still use DenoRun to warm up the V8 caches and have pretty much as much data as possible cached to improve your startup time.
So the answer would be no, DenoCache does not replace it. By the way, switch your DenoCache. usage to Deno install. That's the preferred way of naming it. Deno cache is still there, but it's a to-do for Deno install to produce the V8 code cache, which is what's necessary to really optimize the cold start time.
And we have a blog post on AWS Lambda cold start optimization and show how to do that in a Docker file. Yeah, you can Google it. And if you are, obviously, if you you have a Deno 1x project where can we go to learn about how to swap over to Deno 2?
Well first of all if you do upgrade Deno from Deno 1x to Deno 2 you will be presented with this nice banner linking to the blog post but also to the migration guide which should work you through most of the changes required and well there should not be too many changes required we were really diligent in how you migrate from Deno 1 to Deno 2. So hopefully just do Deno upgrade and everything still works. But if you need help go to docsdeno.com and search for the migration guide page. Awesome. So the website talks a lot about Deno being secure, but like what does that actually mean in comparison to Node for example?
That means that when you do any sort of IOR operation when you access the operating system, if you touch the disk, if you open a network connection, if you do some operating system, you try to list the network interfaces, Deno by default will not allow that to happen. In a similar way that if you go to a website that tries to open your camera, you just don't have that permission by default. You have to kind of opt into that permission.
And so similarly in Deno, you... you need to opt into being able to read from the file system, for example, or open a network connection. Awesome.
OK, what other questions have we got in from chat? Are we going to get JSR private packages and self-hosting? Maybe.
Not yet. Well, if you're brave enough, you can certainly host your own JSR instance and use it with Deno. Yeah, JSR is open source, unlike the NPM registry.
And you can go find that code, github.com slash DenoLAN slash JSR, I believe. And yeah, host it yourself. You know, it's going to be more than like running a single command, of course. And we haven't made that particularly easy.
All right. You know, I think if you do need private packages, I think the right way to go about that right now is to have a NPM private registry, as you normally would. And Deno supports that, and you can kind of pull in packages via NPM colon. Having private JSR registry is something we've discussed, and certainly possible if you kind of twiddle the knobs enough, but probably. probably not a happy path for most people.
Fair enough. Okay, and Bert, you mentioned that WorkSpaces were your sort of most excited feature that you've added. Could you expand a little bit on what WorkSpaces are and what the plan for extending WorkSpace functionality is in the future?
I don't think I'm the right person to ask how to extend it, but WorkSpaces really helps you if you have a more, if you have a more. monorepo where you develop multiple applications or multiple Deno programs and you need to share something between them. I think Bartek, what are we planning to do there next? Well right now you can use Deno workspaces, like let's say Deno first, but you can also use NPM workspaces with Deno and you can even mix the two of them in a single monorepo.
So let's say you have an existing app that consists of multiple support supporting libraries, you don't have to buy write-in for all of it. Like Ryan mentioned in the presentation, you can start small. Add a new directory that is Deno first and essentially mix and match, feel if you like the flow and then migrate gradually. So that's like one of the coolest features of workspaces we have right now. But obviously people have a lot of experience with workspaces in Yarn, PMPM.
NPM and we definitely want to keep improving Deno's implementation to make it more ergonomic and powerful as people need it. Nice. So a few folks have mentioned having the ability to create plugins or extensions. Is that something that's in the works like a Yarn plugin or like an install look or custom CLI command? I'm not sure I know Yarn plugin.
plugins, to be honest. Well, you can certainly create CLI tools with Deno. That's pretty much one of the best use cases. As Ryan presented, Deno compiler, you essentially get the single executable. So that's the perfect solution.
As for Yarn plugins, I'm really not sure what to answer here. I'm not familiar with them. Yeah, what do Yarn plugins do?
Does anyone know what Yarn plugins do? We don't have much. I think custom resolution.
Custom resolution. Yeah. I mean, if the question is like, how do you kind of do your own custom resolution scheme, we're fairly adamantly against that, right?
We want kind of a defined resolution mechanism. So, you know, we have these npm colon. You can pull in HEPS.
You can pull in source code from URLs. There's a couple of defined paths for pulling in packages, but we don't want the language. to just go off in every different direction.
Like we kind of want a structured language that It has a defined resolution scheme. This is essentially what makes a lot of node tooling so complicated is that people augment the language and pass it through transpilers and do all sorts of funky stuff with it that ultimately results in a pretty complicated system. But that said, I don't actually know what yarn plug-ins do, so that's all an assumption.
Okay. Then moving on... Someone has asked whether security tools like Snyk are going to be able to analyze the Deno source so that enterprise security groups are going to be more willing to adopt Deno LTS.
We should use socket.dev instead of Snyk, first of all. But eventually, yes. We're very open to working with Snyk.org. And I'm sure Socket will add support before that. Excellent.
At the end of the day, it's very... vanilla JavaScript that you write with Deno. So tooling that they already have that should work for Node probably is very easy to adapt to Deno.
Awesome. And when is Deno 2 going to be a certified image for Lambda? Unknown. Yeah, unknown. We're trying.
Does Deno 2 work nicely with Puppeteer? Yes, it does. Excellent. And are we getting native SQLite API, SQLite? It's simple.
DIVI just implemented it yesterday, the node colon SQLite built-in library that Node has. I think we probably wait until Node unflags it before we release it. But given that we implement all of the Node built-in APIs, if they stabilize it, we will follow.
Awesome. All right. Well, we're reaching the top of the hour, so maybe we could consider wrapping it up. But I'd just like to ask each of you, and indeed anyone in the room, it's lovely to have you all here. You know, this is like a significant milestone for Deno.
So what future enhancements are you personally excited to see? about like what's coming what can people out there get excited about the list is endless no my personal favorite something that we've been pondering for a long time is maybe plugins for for linting so that you can use your favorite presets or write your own presets to enforce certain conventions across your team and company? I'm looking for a DaWasm imports.
We've been doing, Luca has been doing work. in TC39 to kind of make sure that this is sound with the language and I think this is all kind of worked out so I think very soon now we'll be adding the ability to just import a WASM binary. I think mine would be so this is really something that comes out of our experience with Deno deploy where we're looking at building telemetry and observability deep into Deno so that would be very very easy for you to get traces and logs and especially like associate them with requests that come in through an http server and that's really to make like operating you know a dino website much easier and also just during development that seems very useful so i think that's you know around the corner but not yet in dino 2. i might add interactive graphs and notebooks so imagine spryan's demo of uh penguin beaks and flat slippers, but then you got some sliders there so we can zoom in or maybe filter out some some of the data center and I think that's also really close.
I love that, that would be very cool. Amazing. Well thank you everybody so much for joining us. We hope that you're super excited about Deno 2 and we would love to hear your thoughts so try it out, let us know and we'll see you online.