Deno First Look

Built on Typescript

Burke Holland

Burke Holland

Deno First Look

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

The "Built on Typescript" 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 explains the benefits and drawbacks of strongly typed languages and the improved tooling experience with Deno's TypeScript-first environment. How Deno avoids initializing projects in JavaScript is also discussed in this segment.


Transcript from the "Built on Typescript" Lesson

>> The other thing that it's important to understand about Deno is that it's TypeScript first. And in fact, let's look at the Deno project here. So let's just go out and take a look at their GitHub here. And let's go to their standard library. And if we look at their standard library here, let's take a look at HTTP.

You can see that everything in Deno is written in typescript, so they really expect that you're going to write typescript, with Deno. Now, Ryan and his talk sort of mentions and he says, dynamic languages like JavaScript and Python are good for things like prototyping and doing scientific computing running small batches of code to do some isolated processing.

And and then he doesn't explicitly say it, but he's sort of implies that complex systems on the other hand need a structured language with the type system, okay. You may or may not agree with that statement. I don't know that I necessarily do. But there are some key reasons why you might want to consider TypeScript as your preferred language, especially for larger and more complex applications.

One of the beautiful things about JavaScript is that there's no one right way to do it. And every one organizes their projects differently. Some people use classes some people don't. Some people use objects to store collections. Some people use arrays. If you remember the book, if you ever read the book, The Lorax, if you're familiar with that book in that book, they're making this thing called a need.

And nobody's quite sure what it does. It just does everything. It's just whatever you want it to be. And so JavaScript is kind of like a need in that regard. But this is also one of the drawbacks because when large organizations adopt JavaScript, it's difficult for them to standardize on it because they have to invent their own patterns.

Strongly typed languages are different. There's generally accepted patterns and practices that go into object oriented languages they've been around for a while. Things like the the Gang of Four's design patterns. And by the way, one of those Erich Gamma, who's one of the authors of the Gang of Four is one of the architects of vs code.

So, there are some philosophical reasons there to adopt it. The other reasons are things like better tooling. So let us take a look at something real quick here. I am gonna go. Actually, we do not need to, let us just create a new file here and call it app.ts.

And what I wanna do here is I'm going to pull in a module called Cosmos. And this is Azure's Cosmos DB TypeScript package. We're not gonna use it. I just want to use it to show you the benefits of writing things in TypeScript. And so this module is written in TypeScript here.

And we'll wait for this to install here. Just a second. But once we get this, let's look at the tooling benefits that we get from this. So, what I wanna do here is import from and of course VS code is aware. It sees the different packages that we have here that can pull in.

And I'm actually gonna delete this node modules folder cuz it's enormous. So we want to be pulling from this what we can do is, and this is not just for Azure for TypeScript, this works for JavaScript as well. But we can pull in I think, see here, Cosmos client from Azure cosmos.

Let's see what does it want? I installed and they removed the node modules folder where it was [LAUGH] It's not gonna work very well. Finally it's installed. And then if we mouse over it here, we get this tooling, which is provided by TypeScript. And again, you get some of this with JavaScript, DS codes pretty good about that.

But with TypeScript, you get even more. So for instance, like we know here that there's an overloaded constructor, which is not something that you can do with JavaScript. You can't overload constructors, but you can do that with TypeScript. And you can take a connection string and it's a type string.

Even better though, is that we have this options, right but we don't know what these options are. But with TypeScript we do. And so it knows that these are the different options that you can gonna have and then we know what type they are. If we come over them again, it tells us what they are.

And it tells us whether or not they are required. And we can tell that by the question mark on the end, which means they're optional parameters. These are things that TypeScript provides that you just don't get with JavaScript. So just better tooling, which is quite nice. Quite a benefit.

The problem is currently with TypeScript, which is not a first class citizen, is that we have to transpile it or compile it to something else before it'll run. So for instance, if we did something like this message which is of type string says, Hello World. And then let's just log it out.

We'll just log out the message. All right. Now the problem is that node can't run this, right? So if we were to pass this to node, it's gonna error because it doesn't recognize this type thing right here that is specific to TypeScript. So to run this, we actually have to turn this into JavaScript.

And so to do that, we would then have to initialize our project as a TypeScript project with a ts config file, which I just did with tsc dash dash and let me clear out the terminal. And then that file is gonna have a ton of different I mean, this is every possible option here.

But we actually don't need to change anything. We can just come to VS code and do like a Ctrl Shift B. And then we can select build, and it will just build for us based on that, ts config file. And it should give us an app.js file right, which looks like that and now we can run this this will work.

And that's fine. But the problem is that as you have more and more files so like let's say you have a utils file here. A TypeScript file. Make sure that's in the right directory. And then, let's just add something here called const utils, all right. Then in order, we have to compile this too.

So let's do that. Let's see here. No, no, no, let's do this. There we go. So it's build and now we have two files and and then if we had source maps, then we would have three files, right? So every for every single file, you have then a TypeScript file a JavaScript file and a source map.

And the way that we usually deal with this is you go to workspace settings. Let's see workspace settings in VS code and what you can do is you can say, I think it's files.exclude. There we go. And then we can come in here and just tell it like, these are called globs.

And we could say hey, just like we're not gonna look at the .DS_Store, let's just not show any JavaScript files, right. And as we save this, then all of our JavaScript files, oops, All of our JavaScript files will go away. And then we just see our code files while they're still there.

We just don't see them. The next problem that we have with TypeScript is not a first class citizen is that usually when we deploy the app, we just want the JavaScript, you don't want the TypeScript too, we don't need that anymore, right? The TypeScript is a source but to run it in production, we just want the JavaScript.

So how do we get just the JavaScript? Well then to do that, we have to come back to ts config. And then we usually go to something like the out directory and we'll change this out directory to say, I don't know it's slash, let's just say it's like dist.

Like this, and now when we build, if we do build, we'll get a dist folder that will contain just the JavaScript, right? But we can't see it because we hid it, so now we have to bring it back, but there it is. But you can see how this is starting to become a problem, right?

Like there's configuration here. We have to figure out how are we gonna keep the JavaScript and the map files from showing up? Where are we gonna put them when we actually do the build step. None of this is a problem in Deno, none of this. TypeScript just works and we don't have to do anything extra to make it do that.

Now I should note here that something that's kind of interesting about node is that so this app.js file, we can now run this with node, app.js and that will work. But node will execute any file. [LAUGH] It doesn't care. And so actually you don't even have to have an extension you just call it app and just say node app.

Oops node app. There we go. So you can try this out just like take a file and change the extension to something else. I don't know like Git Smurf or something. And this will work. In Dino is actually the same way Deno doesn't care that the file extension.

If it's not a ts extension, then Deno will assume that is JavaScript. Otherwise, if it's ts, it will try to parse it as TypeScript. So just a little bit of information about how those things work. All right, so we've been over this we talked about excluding files about output directories.

I'm not saying that any of this is a bad thing, maybe this is how it should be. But usually when you wanna have a TypeScript project, you now need to bring in gulp. And you need some sort of an a build process. And all I'm saying is these things can be tricky to set up, easy to mess up and kind of a drag.

In Dino TypeScript is a first class citizen. And so, as you see, what that means is that all of that hackiness of compilation and where we put files and all that stuff, all that goes away. The TypeScript just is your code. And that's all there is.

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