Learn Programming with Typescript: Part 2

Part 2: Setup Your Local Web Server

In the first part of this series, we looked how the basic operations of a computer gave rise to its programmability and the need for programming languages. In this episode we’ll learn how to setup your computer for writing Typescript, our language of choice, and how to work with variables — the containers that hold data values in memory so we can work with them.

The HP9825 was a self-contained desktop computer from 1972 that allowed users to enter programs in a BASIC-like language. The example has a printer but not all users were so lucky. Imagine the fun of editing your program on a single-line display! Each line was compiled as it was entered, making this an interpreted language.

Why Typescript?

We mentioned earlier that operating system design naturally restricts the kind of programs that can be run on each kind of computer. The application programmer expects the operating system to handle input and output.

But what if another layer of abstraction could be added on top to take that problem away? Thus was born the idea of the browser. While many have tried to build something like it before, the one created by Tim Berners-Lee in 1990 is the grandfather of the browsers we use today. A more graphical version by Marc Andreessen, known as Mosaic, was introduced in 1993 and is the most direct parent of Chrome, Safari, and Firefox.

Mosaic was the first popular web browser to combine HTML markup with JavaScript programming.

Like other document generation schemes that came before it, the browser’s HTML language lacked programmability. HTML pages were inert, like pages in a book, and could not be transformed under program control. Brendan Eich’s invention of JavaScript would change all that in 1995 — and go on to become the most important language in the history of computing.

I can make that claim with confidence because, as we all know, the browser with its HTML technology went everywhere. Every school and business had a web page. Every shopping catalog and record label had one, too. And everywhere the browser went, JavaScript went with it.

Every computing device that could display a web browser, like phones and smart TVs, would get JavaScript, too. Overnight and without even trying, JS had been installed on more machines than any language in history — and was seeing more programs written for it than any previous language. Today, JavaScript even runs servers directly with a setup known as Node.JS.

Both Apple’s Newton from 1993 and its first iPhone from 2007 included a web browser, but Newton didn’t run JavaScript. Today, Apple prevents other companies from running their own browsers or JavaScript engines on iOS for fear that they might compete with the built-in browser’s security, as well as the company’s App Store.

Yeah, But Why Typescript?

If JavaScript is the bee’s knees and already works everywhere, what do we need Typescript for? The best way to think about TS is that it’s JavaScript from the future. Over time, regular old JS that’s available everywhere (called ECMAScript) begins to look more like Typescript as the committee that makes those decisions (that’s the ECMA in the official name) adopts many improvements from the newer version. Until then, Microsoft has helpfully introduced Typescript and, with it, the future is now.

The most important feature of Typescript is in its first name: types. As we saw with interpreting numbers in memory, different values in the computer can mean very different things. Typescript aims to eliminate this ambiguity by assigning a type to each variable to help both the programmer and the compiler. By working with strictly defined types, we help eliminate programmer errors caused by misinterpreting the data in memory.

One of Typescript’s best features is that types are optional and we can add as few or as many as we like in our code. One of Typescript’s worst features (for now) is that it requires some setup of your environment to make it work. Note that this setup is only for you, the developer. Regular browsers and visitors to your website will still be able to use your app — because it’s compiled to JavaScript under the hood.

IBM 3279 terminals like the one in this advertisement were on every desk when I was a mainframe programmer there in the 1990’s. Despite the existence of PCs with much better displays, all of the company’s mainframe operating systems were setup to only output text. Color was considered an exciting development and a step-up from earlier terminals — one that few mainframe programs took advantage of.

Tools of the Trade

In order to write any program for the web browser, everyone needs three basic tools:

1. An IDE — a word processor for code.
2. A server to send HTML and JS to the browser.
3. A browser to view your app.

As simple as they are, the array of choices one can make in these tools is the source of many discussions among devs. If you already have these things setup, feel free to skip ahead. If not, there are three ways to get this setup (in order of complexity).

1. With a Typescript playground.
2. With a simple server and console logging.
3. With HTML web components or other page output.

A Typescript playground lets you enter code on the left and see the results on the right using console logging. Be sure to click the Run button at the top left each time you make code changes.

Option 1. Using a Typescript Playground

With a playground, like this one, you can enter and run Typescript code without setting up anything on your computer. This is fine for trying out simple exercises, but will become limiting if you try to develop your code into a real web page or browser app.

Option 2. Using VSCode & Vite

If you’re willing to setup a simple server and install an IDE (and both are easy), you have an ideal platform for building on your own work. This is the method I recommend and will show here. In order to see our output without also writing HTML, we’ll use the console — a dedicated window in the browser that’s normally hidden from view.

Option 3. Using Web Components

Web components are a modern way of getting the output from your code into HTML elements that we can see in the browser. If you’re interested in starting with web page output, you can see how to set that up in my article — or download my Lit starter kit and do your Typescript coding in a module there.

Discord is one of the most sophisticated, powerful, and easy-to-use applications on the web — and it’s all made with web components. No matter what development route you choose to follow, join me on my Discord channel, The Orchard, to talk more about programming!

Prerequisite: NPM

If this is your first time doing local web development in Typescript (or the first time on this machine), you’ll need to install NPM, the Node Package Manager. A package is simply a folder with files in it that your application needs. Another term for this is dependency. For our application, Typescript is a dependency as we’ll need it to compile our project into JS for the browser.

If you don’t have NPM yet, run the installer for Mac, Windows, or Linux first.

Prerequisite: VSCode

VSCode (or VS Code, or Visual Studio Code) is a modern IDE, an Integrated Development Environment — which is a fancy way of saying a text editor for code. The thing that makes it integrated is that VSCode understands the programming language we are writing. We’ll take advantage of this feature to help us find and eliminate bugs, and to make changes across our program by refactoring.

If you don’t have VSCode, run the installer for Mac, Windows, or Linux.

Prerequisite: Terminal

Working with low-level functions in the computer often requires access to the terminal, a program which takes its name from the hardware teletype terminals that were used with computers before screen displays existed. Just like the teletype, the terminal is command-oriented — meaning you type one command at a time and the terminal responds by typing its output on the line below yours.

In Windows, you can start the terminal by pressing the ⊞ Windows key on the keyboard and typing terminal. I’ll use Windows in my screenshots and examples— but the process is similar for Mac and Linux.

If you can’t find the Windows Terminal, you can install it from the Microsoft Store.

The Apple Lisa was the first “mass market” computer to feature an interface with files, folders, and a desktop metaphor. It cost $10,000 in 1983, the year I got to play with one at a Neiman-Marcus store in Dallas. A lower cost version of the machine would be named Macintosh and help define a new era of user-friendly computing.

File & Folder Setup

We mentioned in our review of computer architecture that all memory and storage locations are equivalent in the computer. Because of this we must take extra caution as humans to tell our program exactly where on disk to run. The starting point is called the root folder.

The contents of the root folder of any application will determine how that application is served up by the web server we’re about to install. You can have several applications on the same computer (or several versions of the same application) by keeping them in separate root folders.

Another term for these folder is repos, short for repository. And it’s a good idea to keep all your repos in one parent folder.

For this example, I’ll keep my repos on my u: drive and inside a folder called repos. After opening the terminal window, I can create that arrangement in Windows by typing these commands one at a time and pressing Enter after each one. You will probably use a different drive letter, which you must type followed by a : colon, — like c: or d:.

u:
cd /
md repos
cd repos

The terminal window after issuing the commands above. The current directory is shown in the prompt, the last line of the display.

After these commands, the prompt — the last line on the screen — shows that we are working in the u:\repos folder — exactly where we want to be for the next step.

Can I Get That To Go?

In case you’re not in the mood to cook up your own server tonight, I’ve helpfully prepared one earlier. You can download my Typescript Starter Kit and install that instead, but it would good for you to learn the recipe here.

A modern rack server, so named because its primary job is to run server software like we’re about to install, doesn’t need a display or keyboard because people view its content remotely in their browsers. Units like this one from HP are designed to fit in a standardized rack enclosure. What we call “the cloud” is just someone else’s room full of these boxes. All internet boxes can run the same software, just like your computer.

I’ll Be Your Server Tonight

Vite (pronounced “veet” and French for quick) is a web server, a piece of software we need to get our files off of the disk and into the browser. While your own installed browser can view files from your hard disk, the internet wouldn’t get very far if you couldn’t read things from other people’s hard disks — and hence the need for a server.

When building an app or web page, we wouldn’t want users directly browsing the contents of our hard drive. Aside from the security implications, that would take away our ability to transform any text or graphics we have into a set of organized pages with links.

In practice, web pages are made up of HTML which brings together your text and graphical content — plus JavaScript that allows us to manipulate that content. The server sends HTML and JavaScript to a browser remotely using a protocol known as HTTP, which is why remote web addresses that you visit in the browser start with HTTP://.

This thin client from HP, is the opposite of the rack server above. It’s designed to receive information from a remote server, not store it locally. Often, these devices (which plug into a desktop monitor and keyboard) have limited processors, memory, and storage. You’ll find them at banks and other companies where security and consistency are more important than local processing.

Installing Vite with NPM

Still in the parent folder we just created, run this NPM command:

npm create vite@latest

This command will return several prompts, in this order:

1. Ok to proceed?
   Press Enter to choose y for yes.
2. Project name…
   Type a name for your project and press Enter. I chose learn-ts.
3. Select a framework >
   Use the keyboard arrow keys to move to vanilla and press Enter.
4. Select a variant >
   Use the arrow keys to select vanilla-ts and press Enter.

The terminal window after creating a new project with Vite. The application’s root folder is the one shown after the text, “Scaffolding project in.” Here, that’s u:\repos\learn-ts.

The Path Less Traveled By

While we’re here, we’ll add one more dependency to make working with file and folder names as simple as possible in VSCode. In a nutshell, this program wires together Typescript’s understanding of file and folder locations with that of the web server, letting us write shorter references.

Still at the terminal prompt, run the following commands. If you picked a different project name than learn-ts, you’ll need to cd (change directory) to that folder instead in the first command.

cd learn-ts
npm i vite-tsconfig-paths

If you’re not familiar with the Windows command prompt, this guide offers a helpful introduction. Many of these commands are historical in nature, having originated with CP/M and DOS — before Windows existed.

The terminal window after adding the vite-tsconfig-paths dependency to the repo.

Douglas Engelbart, here seen conducting the Mother of All Demos in 1968, would foreshadow many future developments in computers that we take for granted today — including the mouse he invented. His demo included charts and graphics, video and audio conferencing, and data sharing between remote users.

It Keeps You Runnin’

Every time we want to the visit our website or app in the browser, the server must be running first. Just like when your favorite website is offline — if this step isn’t working there will be nothing to see in the browser.

The first time we setup a Typescript app, we must install the app itself with NPM, meaning install all of its dependencies. Still in the root folder of the app, run these two commands:

npm install
npm run dev

The first time we add dependencies to a repo, we must npm install the app (from its root folder). This installs the dependencies themselves — as opposed to just adding them to the list of required files.

A running Vite web server will display a link to IP address and port where the website is hosted. Ctrl-Click to visit the site in your browser.

The development server must be running in order to visit your working app in the browser, as indicated by this final display in the Terminal. You can Ctrl-Click the link to http://127.0.0.01:5173 to open it, or type the same address into a browser to visit it.

You might see a different address and that’s OK, too. These strange web links, by the way, are comprised of an IP address and port number — a method of separating out applications running on different machines. All we need to know for now is that this is the web address where this app will be visible on our local machine.

If you think setting up a modern app is tiresome, you’d love the punch card reader in the IBM 1401 Demo Lab at the Computer History Museum. For decades, programmers had to punch (or pencil-in) a stack of cards representing their program before it could be run for the first time. Readers like this had collating baskets (the wires at the bottom left) to sort cards from various users as they came out of the machine.

Don’t Make Me Do That Again

What a fun process, huh? The many layers of abstractions in today’s programming require many setup steps to get them working. The good news is that we don’t need to do any of these steps again for this app. When we want to run it again in the future (after turning off the machine, for example) we only need to restart the server.

You can start the dev server later by navigating to the root folder and running npm run dev. Leave the window open to keep the server running.

u:\
cd /repos/learning-ts
npm run dev

Note that, as with all command line examples, you should use the disk and folder names you selected. If the terminal prompt is already in your repo folder, you only need to run the npm run dev command.

Tip: You can break out of the server (and stop it from running) at the command prompt by pressing CTRL-C. After stopping the server, you can press ⇧ Up Arrow on your keyboard repeatedly to scroll back through previous commands (like npm run dev). When you hit the one you want, press Enter to run it again.

Take Me To Your Leader!

Now that the server is running, we can make some code changes with VSCode and see if our system is working. Open VSCode and choose File/Open Folder, then navigate to the root folder where your app is installed. You’ll see the folder contents open up on the left.

The root folder name appears at the top left (in purple). Down that side is the contents of the folder (in yellow). The index.html file is currently opened for editing, as indicated by the tab at the top (in pink).

Our web server serves up index.html if we don’t ask for any particular page. Let’s double-click that file on the left so we can edit its contents on the right.

Now, inside the file, change the contents of the <title> on line 8 to look like this:

<title>Learn Typescript</title>

Also, change the entire <div> on line 12 to look like this:

<div>Hello, world!</div>

After making these two changes, your index.html file should look like this:

Rewriting the contents of the <title> tag and the <div> tag in index.html.

If you haven’t already done, open the new website in your browser. If we save the file (Ctrl-S) and visit the browser, we should see an exciting new page.

A Hello world program is the classic way to show that your setup is working. We did it!

Our page title and text are showing up — and we’ve had to explain more HTML than I cared to, but such is the nature of web development. We need the browser running with an HTML page inside it in order to do anything useful with Typescript. Now that we’ve achieved that, let’s do something!

You may have noticed that our index.html makes reference to another file on line 13, main.ts. This is a source code file where we will write our Typescript code. A file like this with code in it is called a module, as opposed to files that contain HTML or graphics. Let’s open that main.ts file now by double-clicking it on the left and completely replacing its contents with this:

/// Learn Typescript

VSCode complains in several ways if our file has problems, which this one does because it is missing the export statement needed for a Typescript module. The complaint is visible in the red folder and file names (on the left), the red file name at the top, and with a red squiggle where VSCode thinks the problem lies.

The infamous ERROR 601 that comes at the end of Michael Chricton’s film, The Andromeda Strain, meant that the computer had completely given up. Console logging is used in Typescript development to print out errors and other diagnostic info while you’re developing your code. This technique, known as print debugging, doesn’t rely on HTML output on your page — which might not be working.

Console Logging

Finally, we can write some Typescript! I mentioned that, in order to avoid dealing with HTML alongside TS, we’ll use the console to display our output. Let’s add a command that writes something there:

The console.log() function on line 5 writes to the console window, which must be opened separately in the browser. We write what we want logged inside the parentheses. When writing plain text like this, called a string, we must enclose the string in quotes.

Line 3 relates to the idea of modules I mentioned a moment ago. We can use this idea to group our code together into files of related code, then share parts of that code across our application. Right now, we won’t be doing any sharing, so we’ll add an empty export statement on line 3. We’ll examine both the export and the meaning of the {} curly braces that follow it when we discuss functions and objects. Notice that adding the required export statement makes all of the VSCode complaints go away.

Line 5 is where the logging happens. The console.log() function is a procedure built into the Typescript language. To make it work, it needs a value to place in memory before calling the procedure. Here, we’ve given it some literal text — and the rules of TS say that literal text like that must be enclosed in quotes, as “Hello World” is here.

Viewing the Console

One way to open the console in a browser is to reveal the development panel by right-clicking the window and choosing Inspect.

There are several ways to open the console window in a browser, but the one I use most often is to right-click and choose Inspect. In the window that appears, click the Console tab at the top. You may want to adjust the overall window size and also the split between the two sides (by dragging the line where they meet) in order to get a window layout that’s readable to you.

From within the development panel, click the Console tab at the top to see the console log. Notice our output appears (at the purple arrow). On the same line, to the right, is the file name and line number that did the logging. In this case, that’s main.ts:5.

And there it is! Hello World appears in the console because of the Typescript we wrote on line 5. Notice this content has no relation to the “Hello, world!” we typed in the index.html file. It’s even capitalized differently. Which brings up an important point. You, as the programmer, are the only one who knows which data you want where. Like the cubbyholes with labels from our mental model of computer memory, it’s up to people to put the right goodies in the right boxes.

Power to the Programmers!

With much ado, we’ve setup our environment for Typescript application development. Although we haven’t seen how yet, this setup also allows us to package and publish our application for distribution on a static hosting site — the cheapest and easiest way to get your work on the web. We’ll take that for a spin in a later post.

In Part 3, coming up next, we’ll learn to work with variables in Typescript. These are the named containers that point to values in memory. We’ll examine the most important types of variables and how they differ, then play with some simple processor operations on those different types of data.

Until then, thanks for reading!

— D