Last week was the 5th anniversary of the launch of TypeScript, and I had the opportunity to go back to visit Anders and the team for the weekly TypeScript design meeting — to congratulate them on the milestone and on the incredible progress they’ve continued to make with TypeScript over the 4 years since I left the team.
I also took the opportunity to dig up some old demos I had done of TypeScript from the earliest days of our work on TypeScript (then codenamed Strada) to share with the team.
We started working on it as a side-project in the Fall and Winter of 2010. As a forcing function to help ensure we had something to show, we signed up to do a presentation internally on what we were working on at a mini-conference with programming languages folks from both research and product teams across Microsoft. However, in the month before the talk, Steve (the only engineer on the project at the time!) had a wrist injury which prevented him from doing any serious coding. So, not wanting to back out of the talk — I decided to hack something together that would allow us to get across the experience we were trying to deliver — even without having an actually working compiler. (Steve did shortly after build the first real TypeScript compiler, which enabled our first internal customer — the team that was building what would later become VS Code — to start using TypeScript for real).
Here’s the main piece of code we used in the first Strada demo outside our immediate team — on February 1st, 2011.
There are a number of elements of what ultimately became TypeScript that stand out here.
- Implicit flow of types through the code on lines 28–30 without the need for annotations.
But there are also several things you can see here that we ultimately moved away from with TypeScript.
- Types in prefix position — you can see that types are specified above as
string nameinstead of
name: stringas they are now in TypeScript. We initially gravitated to that syntax because we used the name
varfor the type that is now called
any, allowing the implicit typing to
anyto be effectively explicit in a statement like
var x = .... This was also similar to the work done not long before in C# when
name: stringformat (most notably — ActionScript and the defunct ECMAScript4). This one changed over quite early — code samples I have from just a couple months later already use the
- We had the C#-style
class Foo : Barsyntax for super classes — which we later transitioned over to use
- Somewhat more subtly — note that the code is in a
<script type="text/strada">block — and the comment noting that
StradaCompiler.jsis responsible for compiling
text/stradablocks on the fly. We actually imagined at the time that you would provide TypeScript code directly in your HTML via
<script>tags — instead of having a separate build step — and it would get transpiled on page-load (and hopefully cached). This was a somewhat popular technique for small-scale CoffeeScript projects at the time, but as we talked to more larger development teams we found this was not practical for many/most production workflows. In practice, getting this kind of tight development workflow experience ended up being solved by tools like WebPack and similar running watchers that dynamically recompile code but still present it to the browser in a compiled form.
But even more fun is how we made that piece of code actually work.
I hacked into the pretty-printer a way to emit the resulting ASTs as plain JavaScipt — but instead of throwing away the types, I converted them into into Closure Compiler comments. Now, there’s more or less no way to make this a robust process — but it was enough for the demo!
From there — you guessed it — we just invoked the Closure Compiler on the resulting code as a “type checker”. Closure Compiler had (and still has) a convenient hosted service on AppEngine, so we just POSTed the pretty-printed code to that service to get errors.
These were also the days of Silverlight (and Flash) still playing a meaningful role on the client side. And so to run the parser (implemented in F#), we hosted it as Silverlight inside the page — which reached out to find
text/strada scripts, parse them, send them to Closure and report the errors.
The result was that we could get live error reporting as we changed the contents of the
<script> tag inside the developer tools, giving the impression that there was just a background typechecker running. This managed to demo some key parts of the experience we were trying to enable — even though in practice the way were were showing it couldn’t possibly scale to even a single real user 😄.
Here’s one more of the code snippets we demoed. You can see a few more interesting differences from what became TypeScript here —
double as a type instead of
number (we imagined we might add
I prefix on interfaces as a C#-inspired convention — along with some things that stayed, like interfaces and the ability to seamlessly mix untyped object lookups with strongly typed classes.
A little over a year and a half after that first demo, we launched TypeScript. And in the 5 years since, TypeScript has become one of the fastest growing programming languages across the software industry.
Congrats to everyone on the team and in the TypeScript community for the incredible work making this happen!