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.
[00:00:21] 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.
[00:00:38] 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.
[00:00:52] 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.
[00:01:13] 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.
[00:01:31] 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.
[00:01:53] 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.
[00:02:17] 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.
[00:02:32] 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.
[00:05:24] 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.
[00:06:11] 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.
[00:06:31] 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.
[00:06:46] 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.
[00:07:15] 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.
[00:07:39] 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.
[00:08:11] 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.
[00:08:25] 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.
[00:09:04] 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.
[00:09:40] 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.
[00:09:57] 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.