Deno First Look

Deno Overview

Burke Holland

Burke Holland

Deno First Look

Check out a free preview of the full Deno First Look course

The "Deno Overview" Lesson is part of the full, Deno First Look course featured in this preview video. Here's what you'd learn in this lesson:

Burke discusses the course exercises, how to navigate the course files, and how to use a remote containers extension to open the Deno exercises without installing Deno. Why Deno was created is also covered in this segment.


Transcript from the "Deno Overview" Lesson

>> There are some exercises that go with this project. It's the Deno exercises repository. As you're going through it, if you just clone it, let's go over here and take a look at it. What you'll see in here is a bunch of branches, and if you're using PS code, you can just, once you sign in you can see all the branches down here.

And these branches respond to the different sections that we'll be in. And so as we go through the different exercises, what you'll see is at the top, it'll say, switch to this branch to follow along with this exercise. In the beginning, mostly all that's gonna do is reset the project.

That's it, because for a long time we're just gonna be working basically with one file. But when we get to the sections later on in the course where we're gonna look at building a simple web server. And then we're gonna look at building with a framework called Oak.

Those sections build on each other, and you're gonna wanna be able to move through those. And so as you move through those, we can take a look at one of these later on branches here. So let's take a look at like Oak templates here. You can see there's an exercise folder, which you'll be working in, and then there's a solution folder as well which has the completed code.

And so if anytime you get stuck, you can just jump into the solution folder, and that contains the solution for that particular section. But I'll assume that everybody's gonna be working inside of this exercise folder. Let's talk for a minute about development containers because there is one in here.

So this is a bonus, this is for free. If you go to the main branch, there is a devcontainer folder. And this devcontainer folder specifies something called the development container. If you have Docker installed, and if you have the remote development extension, or remote containers extension for Visual Studio code.

It's just called remote containers right here, then you can open this Deno exercises. I'm gonna mispronounce that all day, by doing let's see, rebuild an opening container. And what happens is Visual Studio code uses Docker, and I've already created a Deno container for you that has everything that you need inside of it.

So you'd actually don't even need to install Deno, this should just work. But it'll start a devcontainer here. And then you can work inside of that container. So this is something you can try if you have Docker installed, and you wanna do do remote containers, you don't wanna install Deno on your local machine.

And then once you're in, you can see that Deno's installed here. And that should just work for you. So that's the devcontainer. And that might make things a little bit easier for you, or you can just install Deno and use it locally. Okay, that's the exercises. Let's go ahead and get started, and talk about Deno.

So let's talk about the what and the why of Deno here first. Deno is a command line runtime for JavaScript. That's what it is. And this means that it allows JavaScript to run outside of the browser. And sometimes we refer to this as JavaScript on the server. You'll hear people say that.

What it is, is it allows JavaScript to do very IO type things like reading and writing to files, or working with streams, or making HTTP requests. Basically the runtime freeze JavaScript from the browser and allows you to use it like you would, Java or C#, or any other programming language that simply runs on this system.

If you've been writing JavaScript for a while, you're probably familiar with an existing runtime that does this, and that's called node. Deno. Deno, [LAUGH] did it again. Deno is an anagram for node, and I'm sure that the node folks don't appreciate me rearranging their logo. This is not official.

This is just to hammer home. That this is where Deno comes from. It literally is the letters node rearranged to make a different word. And this is not an inconsequential detail. If you were gonna build a completely new runtime for JavaScript, why would you use the name node intentionally, and just mix up the letters?

If it's not node, then why wouldn't you call it something entirely different? This is an important question. And in order to understand it, we have to first ask a different question, which is why do we actually need another JavaScript runtime? If you've been in technology for any amount of time or even if you're just getting in, you've probably noticed that things move very, very quickly.

And nowhere do they move more quickly than in the world of JavaScript. It seems like there's a new library or a new framework every month. And yesterday's best practices are today's anti patterns. It's incredibly frustrating to try to keep up with all that because you feel like you're always behind.

My gut reaction to hearing about Deno was, please no. And the reason for that is that I already no node, I've worked with it a lot. I'm very comfortable with NPM. Very comfortable with the concepts of node. I've spent much of my career getting to know node. I spend my day-to-day at Microsoft trying to make node work better on Azure.

And now you're telling me that there's a new JavaScript runtime. I mean, node and NPM are so critical to JavaScript developers. And if you don't believe that, just look Microsoft or GitHub's recent acquisition of NPM which is owned by Microsoft. So I mean, I'm open to new ideas.

But I think that if we're gonna do it, they have to solve a major problem. It can't just be, also me kind of thing, I wanna do it, too. What enormous benefits does it provide us over what we're doing right now? Because the constant switching of technologies is a really fantastic way to accrue massive amounts of technical debt.

We really don't want to do that. It's fine to learn new things, but in the day-to-day, what we wanna do is standardize and stay consistent. Otherwise, we just end up with a smattering of projects written in all types of languages. And we're always refactoring, trying to keep up.

Deno was created by Ryan Dahl. Ryan is the same person who created node. And Ryan points out that when he initially created node, he was just obsessed with IO operations. And in specifically, he was frustrated with the predominant web server at that time, which was Apache, and its inability to handle large numbers of concurrent HTTP requests.

And so he talks about how he became obsessed with optimizing IO, in the fact that at the time, the prominent paradigm for coding languages was that they were sequential in nature. Which is that on a web server code executes top to bottom. And if some operational on the way, it takes a long time, the entire thing is hung up waiting on that specific operation to execute before the next one would.

And that could make things perform poorly. And so all of this to say that when Ryan initially created node, he was trying to create a highly performant HTTP server. And he accomplished that goal. In 2012, Ryan left the project because he considered node to be done. So let that sink in for a moment because today, it's 2020 now and we know that node has changed significantly since 2012, a lot.

It's been eight years and that's been enough time for Ryan to reflect there, and there are now many things that he says that he regrets about node. There's this video here, a talk that he gives called 10 Things That I Regret About Nodes, that I highly recommend watching.

I'm gonna cover some of the ideas that he lays out in that video because it's very important to understand why he made the decisions that he made, and it will inform why Deno is the way that it is. I think, hindsight it's always 2020, no software is perfect.

JavaScript is not perfect. PHP is not perfect. Java is not perfect, C# is not perfect. The projects that we create are not perfect. When we're building software of any kind or a language, we're sort of prognosticating about the future, and there's so many things that we don't know.

And what we do is we make educated guesses, and we architect things based on the unknown. And when we look back, we always look at a project and be like, I wish I had done that differently. Everyone does this. I don't know that there's anyone who's ever written something and been like, that's perfect.

There are no mistakes in that. I nailed it. I just don't think that that happens. And so, the regrets, while regret is not normally a good thing. In this context it helps us understand why Deno exists. So Deno is Ryan's second attempt at creating a command line runtime for JavaScript.

And it is based on the mistakes that he feels like were made when he built node now that he knows and can look back with the hindsight to do that. And that's why it's an anagram. That's why it's an anagram because it is directly related to node. So to say that Deno has nothing to do with node is simply not true.

It absolutely does. It is intentionally meant by Ryan to perfect the ideas that he really had with node while fixing some of the things that he considers to be flaws with node. And when we understand those regrets, then the audit teams of Deno make a whole lot more sense because it is odd.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now