TypeScript and the Road to 1.0

TypeScript and the Road to 1.0

Rate This
  • Comments 42

With TypeScript, we have focused on bridging the wildly popular JavaScript language with types for easy error detection, while bringing forward features from the future version of JavaScript in a way that’s compatible with modern browsers.  We’re now focused on getting to TypeScript 1.0, and in this post we’ll give an update on our plans to get us there.

Visual Studio 2013 RC and RTM

We shipped TypeScript as part of Visual Studio 2013 RC to get feedback from a broader range of Visual Studio users.  Given TypeScript’s continued evolution toward 1.0, we’ve decided to keep TypeScript as a separate download in Visual Studio, while continuing to make it easily available for all Visual Studio users. In Visual Studio 2013 RTM, you can install the latest version using the “Install the Latest TypeScript for Visual Studio” link provided in the new project templates.  Using this link will allow you to stay up to date with TypeScript as it evolves to 1.0.  The updates are also available directly from the web.

Reliability and Correctness

As a community, we’ve grown quickly.  There are now dozens of large applications written by teams in Microsoft, including Bing, Xbox, TFS, So.cl, as well as in projects such as Adobe Digital Publishing Suite for Windows 8.1, Zud.io, Away3D, and Turbulenz.  Millions of lines of code are now active in the wild, which reflects a serious indication of the level of commitment and energy that that the community is investing in TypeScript. 

Responding to Your Feedback

With the 0.9 release series, we delivered key new language features and a compiler re-architected for scalability. While these releases have opened up a lot of new capabilities, the feedback from our users is that these releases were not at the level of quality for teams who depend on TypeScript for their development. 

Our goal is to ensure that the compiler is reliable.

Users should be able depend on the TypeScript tools to build large applications without worrying about the tools crashing or consuming large amounts of memory.  We’ve already made progress on this front, with over 60 stability-related issues already fixed since our last public release in the develop branch.

Backward Compatibility

Another important step for 1.0, and for the future of projects that use TypeScript, is that the compiler needs to correctly implement the language specification.  This will allow users to be able to write code and trust that once we get to 1.0, future compiler upgrades will continue to work with their existing code.  To get to this point, we will need to introduce a few last breaking changes as we complete the language spec and update the compiler and associated tooling.  We will be sure to document these changes and the code they affect.

The Road to 1.0

We are planning the last milestones to get us to 1.0.  Each of these releases will be driven by quality, and we will ship each update when we’re confident we’ve addressed the key issues needed to enable development teams that depend on TypeScript to confidently move forward.  These milestones are also covered in our updated roadmap.


The focus of 0.9.5 is resolving user-reported issues and setting a high quality bar.  This is also when we expect to have the 1.0 TypeScript Spec candidate ready.  This spec candidate will detail the complete TypeScript 1.0 language, and we’ll also document what parts of the implementation still need to be completed to finish alignment as well as enumerate the breaking changes from the previous version.


The 1.0RC includes fixes to any remaining reliability issues and completes the last of the compiler alignment with the 1.0 language spec.


We ship 1.0!  At this point we will be both aligned with the spec and ready to fully support development long-term by maintaining backward compatibility in each future release.

We have a clear picture of the road ahead to 1.0, and we’re looking forward to completing this work, making each release leading up to 1.0 even more reliable and robust than the last.  If you’d like to help us out, you can get the latest ‘develop’ source to keep up to date with the changes, and report any issues you find.  Lastly, but certainly not least, a big “thank you!” to the TypeScript community who has helped us make TypeScript what it is today.

Leave a Comment
  • Please add 6 and 6 and type the answer here:
  • Post
  • Still no sound type system subset?

  • TypeScript is great, but given the number of high-risk design problems, I feel uneasy about blanket promises wrt backwards compatibility at this early stage.

    Some of these problems are outside your control, eg, you will need to align with ES6 modules, and with other aspects of ES6 that refuse to settle quickly. Other problems deliberately have approximate solutions now, to simplify implementation, usually at type system boundaries. If you promise your users to maintain backwards compatibility to the current state, you may have difficulties filling the gaps and improving the language later. Evolving JS is difficult enough, exactly because no-one dares "breaking the web" - you don't want to give yourself additional compatibility constraints.

    Why not use markup in the TS language spec to spell out which parts can already be considered stable (guaranteed backwards compatibility) and which parts should be considered at risk (to further design improvements)? That would give your team and your users a contract to work with. Tying it all wholesale to a release version may be more marketable than practical.

    A lot of what makes TypeScript great is that it has opened a promising avenue for evolving JS without modifying it in incompatible ways. To me, keeping open that promise for evolution is more important than backwards compatibility to the current, early-stage design choices.

  • @Anton

    We don't have plans to create two versions of the language.  With TypeScript, we're focusing the type system on giving users a high degree of usefulness.  The error messages and intellisense it gives you should be helpful and let you develop software more quickly and efficiently.  We also don't want the type system to get in the way when using patterns common to JavaScript, like treating arrays as co- or contra-variant.  


    We're keeping a close eye on ES6 as the ECMAScript committee wraps up the design, including modules.  We've been intentionally pretty conservative syntax-wise on the TypeScript side to make sure there is "space" to continue to evolve TypeScript with new ECMAScript standards.  This will be an on-going process, and one that we do with the TypeScript and ECMAScript communities.

    Mitigation strategies like you mentioned, to mark parts of the spec as subject to change if the corresponding ECMAScript portions are yet complete, are on possible avenue.  Still, our goal here is to be able to have a design where people can build large applications using TypeScript, and be able to upgrade their tooling without large amounts of changes to their source.  

  • I just wished that you guys showed some love for the customers still in Visual Studio 2010 land...

  • I think Typescript is headed in the right direction.  However, why didn't Microsoft just try to put C# into the browser natively as another option instead of JavaScript and hoping other browsers/devices follow suit?  I think a lot of people would love to have C# natively in the browser.

  • This is great news - thanks for the update Jonathan.

    I was wondering if you knew if the TypeScript support that currently exists for Visual Studio 2012 will be maintained going forwards given that Visual Studio 2013 has shipped?

    My hope is "yes" because developers are not always free in the enterprise environment to move to the latest version of Visual Studio.  It sounds like this situation is compounded with the Visual Studio 2013 release because it has a installation dependency on IE 10.  And unfortunately most enterprise environments I'm aware of don't appear to be willing to move beyond IE 9 for now.  

    My fear is that the TypeScript plugin will only be supported for the latest version of Visual Studio and in a corporate environment it may no longer be possible to use TypeScript.  Please say it isn't so! - I'd be very sad to have to move back to native JavaScript and lose the benefits that TypeScript has given us.

  • Thanks Jonathan.  I expect that everyone using TypeScript is looking forward to the reliability improvements coming in 0.9.5.   Having to navigate some breaking changes will be well worth it if the result is a much more stable development experience and language spec going forward.  So much work has been done by the team since was released that I'm not even sure if feedback on that version is of much use anymore - hoping 0.9.5 is around the corner.  Hang in there TypeScript team!

  • I know this is more appropriate for the Windows Phone team but I would kill for the ability to build NATIVE Windows Phone 8 apps in Typescript.

  • @jim I'll assume you're not trolling and I'll answer anyway. The people you speak of who would "like C# natively in the browser" are not the target audience here. You miss the point, methinks.

  • Awesome news, guys! Really looking forward to 1.0.

    FYI, I'm speaking on TypeScript at Twin Cities Code Camp this weekend (http://twincitiescodecamp.com). I'm also using TypeScript in my startup company (http://bitshuva.com)

    You guys are onto something awesome with TS - keep up the great work!

  • @Oisin

    I totally get what Typescript is doing and its great.  And maybe this is not the right forum for my question, but why hasn't Microsoft pushed their more modern language instead of putting a "niceness" on top of JavaScript?  C# is just a more modern language and would love to know why they didn't push for that.

  • You know how there is Python tools for Visual Studio in a free integrated package. I would like a similar package for Typescript as well. or a way to install typescript in PTVS integrated. Python and javascript are used often for web development.

  • IMHO, TypeScript is suffering the same thing grunt did initially by wanting to be installed globally and forcing a single version across a machine.  He talks about it a bit in this podcast:


    The approach he went with was to abstract out a grunt-cli global package that just deferred to the one installed locally.  In his case, it was grunt 0.3 / 0.4 / 0.5 breaking changes causing lots of user pain.

    I really would like TypeScript to do the same, so that our existing TypeScript 0.8.3 code compiled with the TypeScript 0.8.3 version (just npm install typescript@0.8.3), 0.9.x code compiles with 0.9.x, etc.

    TypeScript is way too early and with WAY too much future potential to start painting yourselves into the back-compat corner like this.

    Now, this certainly makes the VS tooling potentially trickier, but I think figuring out the versioning / SxS story now and letting people just stick with whatever version works for them is better for the users, and better for the future of TypeScript. :)

  • I've only used Typescript for a few small hobby projects. There were lots of problems with the compiler and the Visual Studio plugin, but the language itself is fantastic.

    I don't like Microsoft but in the world of programming languages it definitely got the best setup. C# blows away Java and Typescript is surely preferable to Dart. Never mind Objective-C. I never understood how an ecosystem like the appstore was built on somethin like Objective-C.

  • @jim, how can you 'put C# in the browser' when you don't control the browser (or all of them). Javascript is in the browser. C# is not. Would the user get to a page where they are asked to download c# (ala download silverlight, oh wait there's a newer version download it again, now restart browser, oh we still don't detect it, download again, oh forget it, we give up on silverlight nobody is willing to keep download it)

Page 1 of 3 (42 items) 123