Today is TypeScript’s birthday!<\/p>\n
But this birthday is a special one – 10 years ago today, on October 1st, 2012, TypeScript was unveiled publicly for the first time.<\/p>\n
When TypeScript first debuted, there was a lot<\/em> of skepticism – and understandably so.\nTo some JavaScript users, a team trying to bring static types to JavaScript might have sounded like an evil plot or a joke.<\/p>\n But the features had merit, right?\nType-checking, catching bugs before you even save your file, and getting rich editor features like code-completion, navigation, and refactorings?\nWe knew teams inside and outside of our company were having huge challenges with complex JavaScript codebases, and we knew that JavaScript was going to be used everywhere<\/em>.\nSo who wouldn’t want powerful tools to help write it?\nFor the team, there was a vision for what TypeScript could be, and in fact, if you look back at our first announcement post<\/a>, the value proposition was largely the same as it is today!<\/p>\n Luckily, that vision resonated with others.\nEarly on, we built a small but hard-working and enthusiastic community, willing to experiment and ride out the experience while we were still iterating, learning, and building something that hadn’t yet even hit 1.0.\nWe saw exciting new efforts like the DefinitelyTyped project<\/a>, new community members helping out on StackOverflow and our issue tracker, authors writing books and tutorials for the language, and new libraries taking a bet on TypeScript.\nThese patient, hard-working, and energetic developers laid the foundation for the TypeScript community to grow.<\/p>\n Still, most JavaScript developers were uncertain of TypeScript.\nSo how was this team going to convince JavaScript developers of the value of static types in a dynamically typed language?\n"Types versus no types" has been a… contentious topic, and that goes back at least<\/em> half a century in the programming world.<\/p>\n But we really wanted to create amazing JavaScript tools through the power of types.<\/p>\n Could it be done?<\/p>\n The truth is that this required a completely different approach in development than we were used to, followed by persistence, outreach, and empathy.\nTypeScript had to be free and open source, and done in a truly out-in-the-open manner.\nIt also had to interoperate seamlessly with existing JavaScript, co-evolve with JavaScript, and feel<\/em> like JavaScript.\nTypeScript never set out to build a separate, distinct, and prescriptive language.\nInstead, TypeScript had to be descriptive<\/em> – innovating in the type system around conventions and patterns found "in the wild" of the JavaScript ecosystem.\nThis let us meet people where they were, and this philosophy really fit well with the project’s design goals.<\/p>\n It’s actually surprising how well the design goals<\/a> for TypeScript have held up.<\/p>\n For example, some design goals like<\/p>\n all really point TypeScript towards simply being a type-checker for JavaScript, adding only syntax that’s necessary for type-checking.<\/p>\n So we focused chiefly on the type system, and avoided adding new runtime syntax and behaviors.\nThis might seem obvious 10 years later, but programming languages often try to differentiate themselves based on what their runnable code looks like – plus, lots of typed languages guide their runtime behavior based on the types.<\/p>\n But these approaches don’t make sense when trying to build on, and integrate with, JavaScript.\nUntyped JavaScript had to work the same when pasted into a TypeScript file, and converting TypeScript to JavaScript needed to be as easy as stripping away types.\nIt took a few missteps early on for us to realize this, but it was a learning opportunity and the team has avoided runtime syntax for the better part of 10 years.\nNowadays, when TypeScript is missing a useful runtime feature, we don’t just add it to TypeScript.\nWe work within TC39 (the JavaScript standards body) to guide or champion new features so that all<\/em> JavaScript developers can benefit from them.<\/p>\n Another successful principle is that TypeScript hasn’t tried to be every tool in the toolbox.\nOne of our non goals is to not "provide an end-to-end build pipeline. Instead, make the system extensible so that external tools can use the compiler for more complex build workflows."<\/p>\n There have been plenty of times when TypeScript has gotten requests to be a linter, a bundler, an optimizer\/minifier, a build orchestrator, a bundler (again), and more.\nThe lines aren’t always clearly defined, especially when TypeScript already does a lot<\/em> as a type-checker, compiler, and language service.\nIn the JavaScript ecosystem, where best practices have continued to evolve over the years, it’s been incredibly important that TypeScript stay scoped and flexible to fit different needs.\nGiven all the different bundlers, different runtimes, different build orchestrators, and different linters over the past years, it’s been crucial that TypeScript integrate well with each of these without trying to displace any of them.\nIt’s been our privilege to collaborate with tool authors in this space, as we all work to make TypeScript and JavaScript easier to use.<\/p>\n Today TypeScript is a thriving language that’s used by millions of developers around the world.\nIn surveys and language rankings like StackOverflow’s Annual Survey<\/a>, GitHub’s Octoverse Report<\/a>, and Redmonk’s Language Rankings<\/a>, TypeScript has consistently stood in the top 10 (if not 5) most-used and most-loved languages.<\/p>\nStanding the Test of Time<\/h2>\n
\n
Back to Today<\/h2>\n