Ten Years of TypeScript

Daniel Rosenwasser

Today is TypeScript’s birthday!

But this birthday is a special one – 10 years ago today, on October 1st, 2012, TypeScript was unveiled publicly for the first time.

The Early Days

When TypeScript first debuted, there was a lot of skepticism – and understandably so. To some JavaScript users, a team trying to bring static types to JavaScript might have sounded like an evil plot or a joke.

But the features had merit, right? Type-checking, catching bugs before you even save your file, and getting rich editor features like code-completion, navigation, and refactorings? We 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. So who wouldn’t want powerful tools to help write it? For the team, there was a vision for what TypeScript could be, and in fact, if you look back at our first announcement post, the value proposition was largely the same as it is today!

Luckily, that vision resonated with others. Early 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. We saw exciting new efforts like the DefinitelyTyped project, 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. These patient, hard-working, and energetic developers laid the foundation for the TypeScript community to grow.

Still, most JavaScript developers were uncertain of TypeScript. So how was this team going to convince JavaScript developers of the value of static types in a dynamically typed language? "Types versus no types" has been a… contentious topic, and that goes back at least half a century in the programming world.

But we really wanted to create amazing JavaScript tools through the power of types.

Could it be done?

Standing the Test of Time

The truth is that this required a completely different approach in development than we were used to, followed by persistence, outreach, and empathy. TypeScript had to be free and open source, and done in a truly out-in-the-open manner. It also had to interoperate seamlessly with existing JavaScript, co-evolve with JavaScript, and feel like JavaScript. TypeScript never set out to build a separate, distinct, and prescriptive language. Instead, TypeScript had to be descriptive – innovating in the type system around conventions and patterns found "in the wild" of the JavaScript ecosystem. This let us meet people where they were, and this philosophy really fit well with the project’s design goals.

It’s actually surprising how well the design goals for TypeScript have held up.

For example, some design goals like

  • "Impose no runtime overhead on emitted programs."
  • "Align with current and future ECMAScript proposals."
  • "Preserve runtime behavior of all JavaScript code."
  • "Avoid adding expression-level syntax."
  • "Use a consistent, fully erasable, structural type system."

all really point TypeScript towards simply being a type-checker for JavaScript, adding only syntax that’s necessary for type-checking.

So we focused chiefly on the type system, and avoided adding new runtime syntax and behaviors. This 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.

But these approaches don’t make sense when trying to build on, and integrate with, JavaScript. Untyped 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. It 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. Nowadays, when TypeScript is missing a useful runtime feature, we don’t just add it to TypeScript. We work within TC39 (the JavaScript standards body) to guide or champion new features so that all JavaScript developers can benefit from them.

Another successful principle is that TypeScript hasn’t tried to be every tool in the toolbox. One 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."

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. The lines aren’t always clearly defined, especially when TypeScript already does a lot as a type-checker, compiler, and language service. In 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. Given 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. It’s been our privilege to collaborate with tool authors in this space, as we all work to make TypeScript and JavaScript easier to use.

Back to Today

Today TypeScript is a thriving language that’s used by millions of developers around the world. In surveys and language rankings like StackOverflow’s Annual Survey, GitHub’s Octoverse Report, and Redmonk’s Language Rankings, TypeScript has consistently stood in the top 10 (if not 5) most-used and most-loved languages.

Of course, the context is important – TypeScript’s use is fundamentally intertwined with JavaScript’s, and every TypeScript developer is also a JavaScript developer. Thankfully, even when asking JavaScript developers if they use TypeScript and like it – like in the State of JS Survey – the answer is a resounding "yes"!

Today’s success is far and above where the core team imagined TypeScript being even a few years ago, let alone a decade ago. The core team has worked hard on TypeScript, but we know that the fundamental thing that’s enabled this success is the community. That includes the external contributors to TypeScript, the library authors and everyday developers who took a bet on TypeScript and proved the language out, the DefinitelyTyped contributors, the community organizers, the experts who took the time to answer questions and taught others and made a path for newcomers – every TypeScript user, from the bottom of our hearts, thank you. You’ve been a part of building something great. We hope that the next 10 years of TypeScript treat you well!

6 comments

Discussion is closed. Login to edit/delete existing comments.

  • Eugene Astafiev 1

    Congrats! Typescript continues the journey of success with pride. More to come 😉

  • Jorge Blom-Dahl 1

    TypeScript saved JavaScript and now is one of the best and more used languages out there. Thanks!

  • Maria SolanoMicrosoft employee 1

    The first 10 years of a language that is already proving to be a legend. Looking forward to the decades to come!

  • MgSam 1

    Congrats on 10 amazing years!! Looking forward to the next 10!

    A few nitpicks:
    – Would be nice to give Steve Lucco and team credit for the original prototype.
    – The design goals you listed are the current design goals. Not the original ones. Obviously, when TypeScript started adding new syntax was fair game; eg. enums.

  • Sungwoo Cho 0

    Many thanks to TypeScript team.

    I have been used TS since 0.8.
    As a lead developer I have to convince members and managers.
    At that time, google released Dart and I was bit skeptical on TS because company behind, MS.
    But, I soon to be realized that TS has more humble approach.
    Unlike Dart, TS provides type annotation embracing JS syntactics not urging developer to follow its own language philosophy.
    I truly bet on TS afterwards.

    I started programming as C++ system engineer and now I’m FE engineer.
    Without TS, I would give up being a FE engineer struggling untyped large code base.
    I love TS, and very appreciated to TS team to provide such a great product.
    I hope TS will expands more on runtime such as WASM and remain to be open and innovative.

    Thank you.

  • 彬 杨 0

    Congrats!

Feedback usabilla icon