How OOP Developers Can Get To Know TypeScript Through Deno

As an old school Object Oriented Programmer (OOP), I’ve always found JavaScript a bit unnatural. So to me (and clearly many others), TypeScript is interesting as it tries to organize JavaScript into a more recognizably class-based style. But it has some very different properties. At the same time as wondering about these, this post looks at Deno, which treats TypeScript as first class and has recently released version 2. One of the problems that those of us from a Java or C# background face is that our mental adoption of OOP has always made it difficult to look at lots of JavaScript — the code looks disorganized because it isn’t in classes, which means the boundaries are a bit too open. TypeScript, while being a superset of JavaScript, does try to bridge some of those differences. In OOP, types are named entities — and they exist from compile to runtime. An object can be of a known type or class. In TypeScript, classes are like sets of things. The structure matters, but type information is actually erased — leading to the worrying phrase Erased Structural Types. But if you think in terms of sets, TypeScript suddenly makes sense. Here is an example: Interfaces are very familiar in the OOP world. But if this code runs, it suggests that I can construct obj — just some random JSON — and it can suddenly take on the mantle of object-ness and satisfy two interfaces. Let’s find out. But first let’s introduce Deno, which is the open source JavaScript runtime that natively supports TypeScript.

Installing Deno

On my MacBook, I used: Or I could have just used: Rather nicely, it asks which shell script you want adjusted (I noticed that when installing Python’s Conda, it changed one script without such politeness). So I’ve got Deno 2 installed and hopefully a reasonably up-to-date TypeScript library. I’ll start with creating a main.ts file, throw in my example code above and just run it: So we have euthanized two birds with one stone: Proof that Deno just runs TypeScript as first-class code and that TypeScript works with structures that are not “nominal types.” Clearly, TypeScript thinks of our JSON object as two sets of values, each of which satisfies one interface. But that implies that types can’t be used as identities, like they can be in C#. So, there would be no real point in reflecting an object’s type, for example. Here is another bit of TypeScript that, viewed from an OOP perspective, looks weird:

class Car {
  drive() {
    // hit the pedal to the floor
  }
}
class Golfer {
  drive() {
    // hit the ball far
  }
}
// No error?
let w: Car = new Golfer();

The equivalent would clearly be weird in C#, but in a TypeScript structural sense, both classes are indeed identical. Let’s use the Deno project initializer to check the above. So it appears that the project created tests, too: I’ll overwrite the template code and create a test for our weird TypeScript example. So, the test can be run directly, and there seems to be no exception error. In this case, weird is good. Deno comes with lots of other TypeScript-specific support.

Deno Deploy

Deno offers you some free infrastructure deployment on its own V8 cloud, and a simple way to do it. Free deployment is always good, plus Deno has given itself a commercial proposition. Rather surprisingly, it has a deploy playground to give you an idea of what “low traffic” examples can be supported. For instance, you could just use Deno.serve to write a simple response server: Press a button, and this is now deployed to https://cloudy-shark-26.deno.dev. So Deno playgrounds can be used to write and deploy small projects. Deno also provides an example of using its simple key-value data store via the playground:

const kv = await Deno.openKv();

Deno.serve(async () => {
  // increment a count using Deno KV
  await kv.atomic().sum(["visitors"], 1n).commit();

  // Get the latest visitor count
  const count = await kv.get(["visitors"]);

  return new Response(`You are TheNewStack DenoKV demo visitor number #${count.value}`);
});

Even though the playground deploys to many different “isolate” servers, it is connected to a single Playground id. This code opens the key-value store, uses the side effect of counting atomic operations, and saves the result as a BigInt in the key “visitors.” I could have changed the 1n to 2n if I wanted it to go up twice as fast. This deployed to here. I get a deployment dashboard too, so I can track all these playground projects.

Conclusion

I think I can see a lot of the old Heroku PaaS dynamism in this easy to access approach to both TypeScript projects and deployment. The AWS Lambda-like Playground service could prove to be an exceptionally cool prototyping tool, as well as a boon to educators. As for TypeScript, it very much isn’t OOP, but it still makes JavaScript a little less icky — so I will endeavor to use it more often when I can.