I started working on a project to help application-scale development teams manage large JavaScript codebases in the Fall of 2010 along with Steve Lucco. Steve had been talking to a few engineering VPs in Office who highlighted the rapid transition of their development teams from C++/C# over to JavaScript as they invested in web-based applications and experiences. These teams missed the productivity tools and confidence that the type systems of C++ and C# and the Visual Studio IDE had provided — and they wanted to know what we could do to help as they moved to JavaScript. At the same time we saw the broader industry trend in a similar direction as fast JavaScript engines, progress on HTML5, and several impressive large web “applications” had all converged to quickly change the way JavaScript was being used on the web over the previous couple of years.

There were many options already available, but none seemed to be resonating well with a broad enough section of the market. Internally at Microsoft, Script# was being used by some large teams. It let them use C# directly instead of JavaScript, but as a result, suffered from the kind of impedance mismatch you get when trying to stand at arms length from the runtime model you are really programming against. And there was Google’s Closure Compiler, which offered a rich type system embedded in comments inside JavaScript code to guide some advanced minification processes (and along the way, caught and reported type-related errors). And finally, this was the timeframe of a rapid ascendancy of CoffeeScript within the JavaScript ecosystem — becoming the first heavily used transpiled-to-JavaScript language and paving the way for transpilers in the JavaScript development workflow. (Aside — I often explained TypeScript in the early days using an analogy “CoffeeScript : TypeScript :: Ruby : C#/Java/C++”, often adding — “and there are 50x more C#/Java/C++ developers than Ruby developers :-)”)

What we quickly discovered we wanted to offer was a “best of all worlds” at the intersection of these three — a language as close as possible to JavaScript semantics (like CoffeeScript) and syntax (like Closure Compiler) but able to offer typechecking and rich tooling (like Script#).

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).