Your first program

Switch to the 3-your-first-program branch to follow along with this section.

Deno programs can be written in TypeScript or JavaScript. Either will work.

In the "app.ts" file in the "exercise" folder, write out "Hello World" to the terminal.

console.log("Hello World");

Execute the file with Deno from your terminal. Make sure you are in the exercise directory where the "app.ts" file is located.

deno run app.ts

You should see the following output...

Check file:///home/burkeholland/dev/deno-first-look-exercises/app.ts
Hello World

Notice that the terminal says "Check <file-path/app.ts>". There is then a bit of delay before that "Hello World" shows up.

Run the program a second time

deno run app.ts

This time it doesn't say "Checking". This time it just runs and "Hello World" shows up immediately.

In order to understand what's happening here, we need to understand what Deno is doing when it "Checks" a file.

Deno run - behind the scenes

While TypeScript is a first-class citizen in Deno, it still has to be JavaScript before V8 can run it. Deno has to convert the file to TypeScript using the TypeScript compiler/transpiler. When it does this, it creates a "build" of your file on your system. Let's investigate that.

Navigate from your terminal to the "deno" cache directory. This will be different if you are on Windows vs Linux. You can use the "deno info" command from your terminal and it will tell you exactly where your cache folder is.



// on my machine, it looks like this...



// on my machine, it looks like this...

Inside that folder, you will find several files...

  • app.ts.bundleinfo
  • app.ts.js
  • (if this file is not present, it's because your source maps are inline in the app.ts.js file which is fine.)
  • app.ts.metadata

Open this folder in VS Code by executing the following command in the terminal from the same folder where these files are located.

code .

This is the output of your program. The "app.ts.bundleinfo" file contains your program's build info. It has paths to TypeScript definition files.

If you scroll all the way down to the bottom, you'll see an embedded ".tsconfig"

The "app.ts.js" file contains the JavaScript output of your code - minified and with sourcemaps.

The app.ts.meta contains information concerning the version of your file. Deno is using these files to determine what dependencies your program has, what version it is, etc. We'll look at this again later on and you'll understand more about why Deno is doing all of this.

In summary, Deno is the compiler and it checks code for errors the way any strongly typed language compiler would.

Running without checks

You can go around the TypeScript checking all-together by passing the "--no-check" flag to the run command.

Modify the app.ts to contain the following valid TypeScript code...

const message: string = "Hello World";

Run it with the --no-check flag...

deno run --no-check app.ts

This time the app runs without the check. There is still a slight delay as the code is transpiled, but it's faster because it's not checked for errors first.

If you run the code again, it will be even faster because nothing has changed, so it doesn't need to be transpiled again.

Executing JavaScript

In the same way that you execute TypeScript, you can execute plain JavaScript.

In the "app.js" file, add a line to print out "Hello World".

console.log("Hello World");

Run the file from your terminal with Deno.

deno run app.js

Notice that there is no check this time and the result is immediate.

When executing JavaScript files in Node, you don't need to pass a file extension. This is why Express apps have a file called "bin/www" with no extension.

Deno supports this as well. However, it will only recognize a file as TypeScript if the file has a .ts extension. In any event, the follow code works in Node and Deno...

node app || deno run app
Hello  World

Executing remote scripts

Deno can also execute scripts that are remote. That means that you literally call them with a URL. This is why the Deno docs have you call their sample "Hello World" program. This feels awfully unintuitive for a JavaScript developer. We explicitly do not execute scripts from other sources because we don't know what they are going to do. But since Deno is "secure by default" as we discussed earlier, the model changes and Deno actually expects you to include code from remote locations.

Instead of running our local "app.ts" file, execute the remote "Hello World" example that Deno provides...

deno run

Welcome to Deno 🦕

Notice that first Deno downloads the file, then it sends it through the compiler/transpiler, then executes it. Normally, we would consider this a highly dangerous thing to do, because we don't know what this file is or what it might attempt! But because Deno will not allow any program to access your files system, the net or do virtually anything else without your permission, this is ok.

But where is this file downloaded to? For that, we need to go back to the cache.

Where Deno downloads dependencies

Deno treats this file as a dependency, and downloads it to the same place it downloads all dependencies. This file isn't really a dependency that we are using in our program - it IS the program. But Deno treats it the same way it treats dependencies.

Navigate from your terminal to the "" directory in the "deno" cache. This will be different if you are on Windows vs Linux...




// on my machine, it looks like this...

In that folder, provided you have never worked with Deno before, you should see files with really long names. One has no extension and another has a .metadata.json extension. Something like this...


You can open that first file - the one without the extension - in your editor, and you'll see the code in the "welcome.ts" file that you ran from ""...

// Copyright 2018-2020 the Deno authors. All rights reserved. MIT license.
console.log("Welcome to Deno 🦕");

Deno downloaded that file, cached it, transpiled it to JavaScript and executed it.