We spoke with Ryan about his history, his current role and his passion for TypeScript.
What was the initial inspiration for TypeScript? As an evangelist for TypeScript, what is the main thing that excites you about it today?
TypeScript inspires me because it solves a real problem in a simple, elegant way. There’s nothing I love more than seeing someone on Twitter say something like “I was hesitant at first, but I’m never going back to JS after using TypeScript” – it means we’ve done our jobs right.
What did you work on at Microsoft before TypeScript, and how did you get involved in TypeScript?
Before working on TypeScript I worked on the internal tools we use in Visual Studio to automate testing VS, and before that on Visual Studio LightSwitch.
What was your role in the development of TypeScript? What is your role now on the TypeScript team?
My first task was to revamp the testing suite we use to keep TypeScript stable. Since then I’ve worked on all aspects of the language, most notably adding JSX/React support to the language, creating our automatic type acquisition (NPM @types) story, adding language service extensibility, and now working on adding refactoring support.
As a developer on the team I’m responsible for general feature implementation and bug fixes. Additionally I maintain our GitHub process and am a primary triager of issues reported on our GitHub repo. As part of this work I drive decisions on community suggestions, provide language design and prioritization feedback, and try to engage with the community as much as I can. I also do some work on the Node Tools for Visual Studio.
Adding React stateless function component support to TypeScript! pic.twitter.com/gP2CuL50tH— Ryan Cavanaugh (@SeaRyanC) 30 October 2015
What do you see in the future for TypeScript?
Turns out TypeScript and cake are my two favorite things, so... pic.twitter.com/WCZ8DMA0z7— Ryan Cavanaugh (@SeaRyanC) 22 September 2016
Give us a sneak preview of what your talk will be all about.
I’ll be covering Typescript’s design process and philosophy, examples of trade-offs we’ve made in the language and their impact, how and why we’ve made breaking changes, how we pick new features, and an exploration into what “soundness” means for a JS-based language (sort of a comparison with Flow and how the two languages make similar but subtly different trade-offs in this space).