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:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
interface
Pointlike
{
x:
number;
y:
number;
}
interface
Named
{
name:
string;
}
function
logPoint(
point:
Pointlike)
{
console
.
log(
"x = "
+
point
.
x
+
", y = "
+
point
.
y);
}
function
logName(
x:
Named)
{
console
.
log(
"Hello, "
+
x
.
name);
}
const
obj
=
{
x:
0,
y:
0,
name:
"Origin",
};
logPoint(
obj);
logName(
obj);
|
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.
On my MacBook, I used:
|
1
|
curl
-
fsSL
https://
deno
.
land/
install
.
sh
|
sh
|
Or I could have just used:
|
1
|
brew
install
deno
|
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:
|
1
2
3
4
5
6
7
8
9
10
11
12
|
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 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:
|
1
2
3
4
5
6
7
8
9
10
11
|
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.
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.
