Dabbling With Deno — Tales From a Web Developer Playing With a New Toy

Thanks for a great talk. I'm sure you'll enjoy the rest of the event. Thanks for listening. We'll see how we get on.

Before we do, let's do a small introduction. My name's Phil Hawksworth. My pronouns are he, him, and I'm head of developer relations at Deno.

Now, there is going to be a chance for a bit of Q&A at the end of this, but if you're watching this after the fact or if questions come to you later, that's just fine, too. You can find me on the internet. You can ask me questions in lots of places on social media. I'm usually at philhawksworth. At least that certainly was my name when I was on Twitter. I'm not on there so much these days. I guess I'm, where am I? I'm on LinkedIn as philhawksworth. I'm on GitHub as philhawksworth. More often now, I'm philhawksworth.dev on Blue Sky. And even my domain has changed to philhawksworth.dev, so you can find me on the web there. That didn't used to be the case. I used to be on this very natty domain name, hawksworks.com.

Naming things are hard. That's a terrible name. It's not quite my name. It's almost my name. It's difficult to say. It's difficult to spell. So I'm not that anymore. But naming things is hard. We don't all have it as easy as, I don't know, people like Ryan Dahl, the inventor of Node. You know, he came up with a very smart name when he named Node, at the point that he decided to go for a difficult second album and have another go at building a JavaScript runtime and work on Deno. He had to come up with a new name.

So he took Node and he split it, and he sorted it, and he joined it, and Deno was born. That's the name. That's not how the runtime was built. We'll get into that perhaps a little bit later. But yeah, this process of splitting an array and sorting it and joining it might've worked for Ryan for Node, but less so for me trying to come up with a new name for Hawksworks. That didn't work out so well.

So Phil Hawksworth at DevIIS, that's me. You can find me there around the web. And I've been building for the web for a long time. I've been building for the web for about 25 years in different places, in software houses, putting numbers on screens for traders to trade off in large enterprises, in agencies, in tech startups. Most recently, I was working at Netlify, but now I'm working at Deno. And across all of those places, I've observed a few things. And one of those things is that we're, as web developers, we're inclined to indulge in a few trends over the years.

Things come and go, some technologies come and go, some technologies stick around, some become ubiquitous. And when I'm thinking about the world I like to build in, I love building with JavaScript, and JavaScript certainly has become ubiquitous.

Partly, I guess, because it became the runtime for the web as an old colleague of mine used to describe it, present as it is in all web browsers. But increasingly, its footprint has increased. And that is, of course, due to tools like Node.js where that introduced JavaScript to the backend.

And more recently, it is at the edges, it is around the network, it's running in serverless environments all over the place. So really, JavaScript is pretty ubiquitous, not just for where it runs, but also where the kind of companies that run it. Certainly, it's gone from the front end, from the browser to the server and beyond.

And Node is one of these tools that, now I've observed it grow over the years from a curiosity to a ubiquity. Now, it really is everywhere and it's really mainstream now, but that wasn't always the case. And I've had to battle long and hard over the years to convince companies to adopt it, whereas they may have been of a more traditional stance.

That has changed over the years, partly because of how Node has brought JavaScript into the mainstream more and more, and its resilience has increased. And I think that is continuing to increase as we move into the world of TypeScript or JavaScript plus plus, as I shouldn't call it, because naming is hard and that's not what it's called.

But this natural evolution of JavaScript, really taking it to become much more resilient and robust is really exciting. And this is an example of the pool of new, interesting tools. I think as developers, we love trying new things. We love experimenting with what seems exciting or what seems like it opens up new doors for us.

But I personally am very cautious about that. I'm very cautious about adopting new tools. I need some persuading. And in fact, I kind of tried Deno for the first time very much by accident. I don't think I realized I was even using it. And that might be the case for you as well.

As a JavaScript, a web developer, a node developer, however you kind of describe yourself, you may already have encountered Deno without realizing it. The place I discovered Deno for the first time without realizing it was when I was building edge functions on Netlify.

So I had lots of sites. I still have lots of sites on Netlify, and I was using Netlify edge functions as a way of adding some dynamism and some real-time or at-request-time capabilities to my otherwise pre-rendered sites. And little did I realize at the time, but actually that was powered and still is powered by Deno under the hood. But this is what it looks like. It looks like JavaScript to me.

I was writing functions, handlers that look a little bit like this, some of them a bit more complicated than this, but you get the point. This is just JavaScript. Indeed, much of it is now just TypeScript. And that's a really interesting way to start building with something without even realizing that that's what's powering it under the hood.

So this was my first taste of Deno, and I became increasingly excited about it before I came along to join Deno, the company. The next step for that really, for me, was another kind of gateway drug that took me a bit deeper, and that came in the form of a site generator, one called Loom, which you may or may not have encountered. I love Loom. It's very, very elegantly designed from a technical standpoint. It's kind of aligns with some of my technical tastes. It's one of those projects that, I don't know if you've ever been in this situation, where you take a look at it and you end up reading the docs from start to finish all in one go.

Got very excited about using this, but the first step of installing it was this command. So it was a Deno command. I'd never used Deno before, or so I thought, certainly not explicitly. So this is what led me to Deno. It led me off to the Deno site, where I found how to install that, running this command. All of these commands and all of the content of this, by the way, will be shared later on. So don't be worried about your pen and paper or scribbling these things down. I'll share that later on. But running this command, of course, then gets us to the point that we've got Deno installed and we can start using it explicitly. And we've got this kind of scary blinking cursor of what do we do next?

I haven't really talked about what is Deno. I've mentioned at the very beginning that I was excited to play with it as a new toy, but what exactly is it? Let's just talk just briefly about what it is. I mean, it's an open source JavaScript, TypeScript and WebAssembly runtime. We talk about it having secure defaults. It's built on V8, Rust and Tokyo. And Deno, the company, has a hosting platform. Not gonna talk about that at all today. Really, it's a JavaScript runtime. It's a TypeScript tool chain, if you like. It's a package manager. It's a task runner.

It's a testing tool. It's a linter and formatter. It's a benchmarking tool. It's a compiler. It's a lot of stuff. And we've got, well, quite a lot less than 20 minutes to talk about this. So I'm gonna have to go fast and give you a little taster, but hopefully what I'll do is maybe I'll pick on some of these things and intrigue you in the same way that I was intrigued.

What got me intrigued in the first place? Well, I'm a web developer of many years, as I've mentioned earlier on, and it really struck me at the very beginning of looking at Deno that it was an API designed that's based very heavily on web standards, which is exciting. If you've been working in the web for a long time, it's nice to have something which is an API that's familiar to you. So yeah, Deno is based on web standards and its APIs feel kind of familiar, whether that's when you're dealing with URLs or if you're building things with web sockets or newer APIs like temporal that help you handle dates and times a little bit more easily.

Things like that really help give a tool like Deno a quite shallow on-ramp. The combination of a familiar API and the ability to start things with a single file, you don't need lots of pipelines or infrastructure or configuration, just a single file will get you rolling. Means that it's very low friction to get started, and I love that. So a familiar entry point for many people, familiar with Node will be this. This is how you would run a JavaScript file with Node, just with that Node command. It's the same in Deno. After you've installed Deno, you can do the same thing. You can do the same with TypeScript. You don't need anything else. It's a batteries included, as the folks at Deno like to say, runtime. So you can be running TypeScript straight away, just like this.

And there's some other familiar traits as well. You'll be familiar with doing things like NPN, init to get started. And that's just the same with Deno. Deno can give you a bootstrapped project from Deno.init as well. And that's, this is what that kind of looks like. So we'll get started with a little project here from fresh. All that does when you run Deno.init is it creates you a few little assets. It creates you a configuration file, a very simple script file and a test file so that you can get running your application, testing your applications and then configuring them very, very quickly. As I mentioned earlier, indeed you only need a single file to get started, but this gives you a little bit more.

And you'll see here that, you know, as I started off, I had a few squigglies, you know, what were some of these internals that were built in and not performing or not being recognized by my IDE. Well, enabling Deno in your IDE after installing an extension means that you can have all kinds of insights into your code. It gives you hinting across the Deno ecosystem and that's all available to you as well. So I would urge, if you're going to play with Deno to install the Deno extension for visual code. There are also lots of other LSP tools for you for your particular code editor. And again, I'll share links to that at the end of the talk.

And so if you do get started with Deno, you know, you don't necessarily need to run an NPM install or something equivalent to start building with packages. This is something that appealed to me very much. So if we look at a very simple kind of TypeScript file here that maybe we want to import from some package, it's really important, I think, that we can start bringing things in from the NPM or the node ecosystem to just kind of ease that transition.

It's difficult to start completely from scratch with an environment like this. So if you wanted to be importing from a package such as a node emoji here, you could do that just by running your file after making sure that you've got the specifier at the beginning of your package, which is NPM colons and then the package name. That will tell Deno when you run this script for the first time to go off, install that, cache that for you, and then make it available for your script. So you don't need to run NPM install. There's no package JSON required. There's no node modules for you to manage. Everything can happen in this single file. So you can just run your script. It'll install things, and off you go.

But of course, dependency management is important. And not everything is as simple as that last script. So with Deno, we can implicitly import things in line as I've just shown, or we can run things like Deno add, Deno install to get your packages managed that way as well. When we install dependencies in Deno, those are cached globally, locally. What I mean by that is they're cached on your machine, but they're global across your machine for all of your projects. So the more you're building with Deno, the more you're building up that cache of kind of shared node modules, if you like, or resources that all of your projects can use. It's very similar to the approach that you may have seen from PNPM.

This is great for kind of speed of installation, also kind of de-duping things in your storage. It's much more efficient than perhaps the way you may be used to. And we can add things to our applications using Deno install commands, just as you could with NPM install, or Deno add, which rather than installing, it just adds it to your configuration so you can install it with one command later on. In either way, these look very, very much the same in terms of their syntax, where you can add many different packages. And if you include the specifier NPM, it'll install them from the NPM registry. There are alternatives. I don't think I'm going to get the chance to talk about JSI, which is another registry that Deno's championing with a few other large players as an interesting alternative to NPM, but either way you can install from JSI or NPM with this kind of command. Now, you're probably much more comfortable with seeing a package.json where you've got the dependencies listed so you can see exactly what's in there. And you can have that provision as well with Deno. Deno.json has an imports map. This is what the imports object looks like there as an example.

And here you can see examples of resources that have been pulled in from the NPM registry or from JSR, all that can be then used within your application. And if you do this, of course, that kind of simplifies things because those become exposed to your applications by those names rather than by the rather more verbose identifiers there. So rather than doing this in our example before, we can go back to doing this if we've got a Deno.json with our import map.

One of the things that kind of excited me about using Deno was how it helped me manage all of these resources and keep these packages up to date. So Deno has this useful utility called outdated built into its package manager. And the way that works is like this. Let's take a little look here. So we've got a simple project that's got a few different dependencies of the imports. It's got React in there, which is coming from NPM of a particular version number. We've also got Vite, which has to be at least, what do we say, 4.5.0 there. And we've got something coming in from JSR, which is from a standard library that we're using.

If we run Deno outdated there, it'll show us what's installed currently, what an update would give us if we were to just honor, kind of make sure it's SEMVer safe, and what the very latest option is available to us. And so we can update in a number of ways. So if we run outdated dash dash update, my typing catches up with me. Just run update there. It'll tell us that there's actually nothing that we can safely update yet, because we're a little bit further behind. So we're as far up to date as we can be for the latest update without breaking SEMVer. But if we go to the very latest, and I'll put the interactive flag on here, this will show us by package exactly what we can install. So we can cherry pick those. So the JSR package, that's just a point release, so we'll upgrade that. And we'll choose one of the others to upgrade as well. And there you can see, we just kind of cherry picked which items to update, and that's been updated again, not just in our local cache, but also in our DNO.JSON to kind of make sure that that's all updated and consistent for when we use that in the future with perhaps a DNO install command in another environment. Okay.

As I mentioned, those dependencies are all kind of cached globally in our local environment, which is a boon for anyone who's like me, who's been, had the headache of Googling for how do I delete all of my node modules across all of my machine? Because I've been in this situation where my disk was full and I had a gazillion gigabytes of node modules. I don't know. Has anyone been down this road where you've been finding these commands to kind of clean things out? It's much easier with DNO. You can just run DNO clean. That will purge your local cache. And then subsequent installs will gradually repopulate that cache to be used across your different projects. There is some further nuance coming to this command in future.

I think I'm allowed to say. I don't know, maybe I'm not. But just between us, I think that we'll be getting a little bit more laser focused in future that have some extra kind of granular control. But for the moment, DNO clean will kind of purge that cache and let you populate it again, piece by piece as you go.

This is a little example here of actually the project that is the DNO docs site. I'm just gonna start completely from fresh here just to show you a couple of things. So this is a brand new kind of clean checkout of that repo. We'll just take a little look at what that project looked like. It's a fairly extensive project with tens of thousands of pages, lots of content, quite a few dependencies. Dependencies there and different tasks that we can run. We'll talk about tasks shortly.

And if after just cloning that, I simply run serve, which is one of the tasks there to bootstrap the project, you'll notice that it's not installing anything. That's because, you know, even though that was a clean checkout, in my other projects, I happened to have installed things that include those dependencies. Had there been any gaps, it would have just installed those and then we'd have been off and running. But as you can see, we're going very, very quickly there from kind of cloning a project to getting running.

I just want to show you what cleaning looks like. So if I stop the server, and then we'll run Deno. Let's have a look at the info first of all. So you can see here from running Deno info, the location of where our various caches and resources are stored locally, so we can interrogate those if we wish. But I'm just going to clean that down, purge that entirely. It's removed that cache. So now if I run Deno, to run my task, let's use task rather than run this time. They're kind of interchangeable for tasks. Run task serve.

You'll notice I haven't installed anything yet. Deno will install those for me automatically. It'll figure out the dependencies according to the Deno.json. It'll install those in the cache for future use, not just in this project, but the other projects as well. And we're off and running once again. Okay, time is moving on.

Let's keep rolling as fast as we can. A task runner. Oh, this is really exciting to me. Who knew that running tasks would be a cause of excitement? You may be used to running different scripts in your Node projects with npm run dev. You can do likewise in Deno with tasks with the command run, or indeed with task. These tasks are managed in your Deno.json.

And if we just show a little example here kind of quickly of just Deno task without naming a task, what it'll do is it'll describe to us what all the available tasks are, and it gives a description of what they are, if there are any other dependencies that it depends on. And we can see here that this task has a commander. It'll run and it's dependent on styles and so forth. This is all configured in what I think is a fairly familiar-looking object within Deno.json, very similar to the scripts in package.json. But you can see that we can provide a description and the dependencies within this construct, meaning that Deno will resolve the dependencies for us across our projects. And it can do some kind of handy things like doing diamond dependencies, deep cascading dependencies and what have you.

So, for instance, if I run denotask build, that is a command that runs build docs and build blog, but they both depend on build styles. And Deno is smart enough just to run build styles once as a dependency of both of those other subtasks before those other tasks are run. This is the kind of thing that I used to install other tools and applications to help me with before using Deno. And I love the fact that it's built in now and everyone can kind of conform to using one particular set of tools.

I'm gonna go quickly through test running. Deno includes a test framework, and you can run your tests using the command denotest. Just at the very beginning of this, of our little demos, we looked at starting a simple project and that gave us a denotest file straight away. You can run that there with denotest and see what that looks like. And this is a great kind of starting point to build out your tests across your application as you build it. Deno will look for files with these naming conventions, so anything underscore test or anything dot test, and look for the tests within those files. And you can structure those however you like and you get access to things like mocking, asynchronous testing, coverage tools, and a variety of different test styles. I don't really have the time to talk about that too much here, but I would recommend checking out some of the examples on docs.deno.com forward slash examples where we talk about testing fundamentals and isolating things with mocks and much more.

Time's getting on, so I need to just kind of allude to this TypeScript tool chain that I talked about at the very beginning. It's kind of also a JavaScript tool chain, I guess. I think maybe perhaps development tool chain would have been a better phrase for it. Suffice to say, it's already built in. You know, we didn't have to do anything extra. We didn't have to add any configuration.

We run it just by simply the same way that we would run JavaScript file, we run a TypeScript file. We don't have to compile anything or do any extra work or configuration to make that work. Now, there are facilities to do more things related to TypeScript, such as do our type checking with deno-check or generate type definitions with deno-types. These are all built in as well and ready for you to use, as are things like formatting for formatting the code similar to how you might install something like Prettier to format your code and make those consistent across the project or create a set of rules for linting your code with deno-lint. All of these are built in and kind of configurable and extensible.

I love tools that simplify and unify the tools. There are a lot of things that I've reached for other tools here that are now baked all into the one tool, which helps teams coalesce around a bit of consensus around the kind of tools that they're going to use and you don't have to learn quite so many things. Deno is kind of regularly improving and building quite rapidly, similar to many of the things within this kind of landscape. And I'm excited by the fact that I kind of know this already because of its basis on web standards. I think all of these things help have a lower friction, a kind of fewer quirks so that you can get building things very, very quickly and you kind of build on Deno's quite robust security model and its impressive performance, which sounds like a very salesy way to wrap up a talk.

I would urge you to play with Deno if you're at all interested by taking a look at some of these resources. I showed very quickly a list of examples and tutorials. You can dig into those there. Also, there's lots of help available in the Deno Discord and conversation and updates happening on Blue Sky. And I'd also recommend this video from the folks at Syntax who did a very deep dive warts and all look at Deno, using it for a particular project and really dig into that quite a lot there as well. Okay, a few minutes over time. So apologies for that. Let's see if we can tighten this up in the edit. Let's see. But with that, I would just say thanks for your time. Thanks for listening. You can contact me for questions on philhawkswith.dev and you can get these slides from the QR code. Find that at hellodino. Thanks very much.