14 ms·

Announcing TypeScript 2.1

503 points by DanRosenwasser 10y ago

koolba 10y ago
So can I finally banish babel from my build steps?
- saosebastiao 10y ago
  I did while 2.1 was an RC. It has worked flawlessly and I haven't looked back. Build and minification is still a pain though...
  - jiaweihli 10y ago
    Try webpack, it's fast and the configuration is nearly declarative. You can also create a separate build task to run a smoke test by directly calling the ts compiler to compile your code (skipping pre- and post- build steps). This was a lot faster than I expected.
- kevinsd 10y ago
  The post did not mention anything about babel (or whether it is still needed). Any pointers?
- WorldMaker 10y ago
  I think I'm still waiting hopefully on an answer to supporting more automatic polyfill imports before banishing babel entirely. (Though the big one has been an Object.assign polyfill and certainly object spread removes a lot of the need for that.) I also would need to straighten out some things with how I'm handling TSX I think.
seattle_spring 10y ago
Seems like all of the new features have been available in Flow for quite a while now.
- manojlds 10y ago
  Flow is not a language
  - tomatsu 10y ago
    https://flowtype.org/ https://flowtype.org/ function bar(x): string { That's not JavaScript.
    - thejameskyle 10y ago
      If that's too much you can also do: function bar(x) /* : string */ { No compiling necessary
  - ygra 10y ago
    I'm fairly sure it has a grammar.
- raphinou 10y ago
  Typescript seems to get a lot more attention (at least on HN). How does Flow progress? How is the community around it? I'm curious to know more as an external to both projects.
- icholy 10y ago
  The new type system features are: keyof, lookup types, and mapped types. Does flow have even one of these?
  - seattle_spring 10y ago
    $Keys<> for keyof, $MapObj<> for mapped types. They are sorely missing lookup types though.
    - curveship 10y ago
      I can't seem to find any info online about $MapObj<>? I searched the docs, google ... nuthin'. Am I just missing something?
n0us 10y ago
I have been waiting for object rest and spread for ages. Thank you to the maintainers for working hard on this feature.
- k__ 10y ago
  Same here. I already used it exessively in JavaScript to prevent mutations and missed it a bit in TypeScript.
ihsw 10y ago
Async/await support for most browsers and node-0.12+ is definitely a welcome feature, callback hell and tripping over promise chains is definitely one of the most painful experience in TS development IMO.
ng12 10y ago
Hurrah for object spreads! Time to go grepping for calls to _.default and _.extend.
- WorldMaker 10y ago
  Also, Object.assign
  - Sankozi 10y ago
    Unfortunately newThing = {...thing, propertyName: value} Will always compile, even if propertyName is invalid. The only advantage over Object.assign I see is IDE support (at least in Intellij IDEA). I will still use: newThing = Object.assign({}, thing); newThing.propertyName = value; This will not compile if propertyName is invalid and is IDE friendly.
    - WorldMaker 10y ago
      You should be able to add a type requirement and get the error you are expecting. Instead of this: let newThing = { ...thing, propertyName: value } // type of newThing would be deduced: TypeOfThing & { propertyName: TypeOfValue } If you add the type requirement the compiler should balk on the propertyName: let newThing: TypeOfThing = { ...thing, propertyName: value } ETA: You'd have the same lack of compiler error if you were instead using: let newThing = Object.assign({}, thing, { propertyName: value }) Because Object.assign will also build intersection types by default.
tjbarbour 10y ago
" We spread ourselves thin, but this is the moment you’ve been awaiting – TypeScript 2.1 is here! "
- nojvek 10y ago
  I read that first and I was like "o_O". After reading the rest I was "O_O". Nice pun.
msoad 10y ago
We are using async await with 2.1 rc and it works flawlessly. I also love the keyof, with that we can remove tons of "any" types from our code base. Amazing work TypeScript team! This release has been a lot of work!
zdragnar 10y ago
It's interesting to me that all of the initial reactions I've seen to this announcement have been around the introduction of async and object spread, which are available with babel, but the typescript specific features such as mapped types are completely ignored. I don't really have any particular meaning behind that observation, only that it tickled my funny bone a little bit.
- nozzlegear 10y ago
  For me, I'm excited because this announcement means I can finally remove Babel from my compile process and just rely on TypeScript to do all of the magic for me.
- DanRosenwasser 10y ago
  TypeScript PM here - the reason for that is that when we implement a feature in TypeScript, we take lengths to ensure that it is typed appropriately and that its performance characteristics are reasonable. That means that when using object rest/spread, we didn't want to just ship an experience where type type is effectively `any`, leading users to be frustrated if they make an error. With async/await, we had to rewrite our emit pipeline, which meant that we needed to keep parity in both output as well as time to emit. The investment has shown, and TypeScript is still extremely fast. We're always willing to think about different approaches, but those are some of the rationales here.
  - vyrotek 10y ago
    As a long-time .NET dev... Thank You for Async/Await in TypeScript.
    - mattmanser 10y ago
      async/await in C# is pretty nasty and usually overused and overhyped for nothing but downside. It screws debugging, it screws call stacks, it dictates you to write bad code and it's just plain complicated. It infects your code up and down the stack and every new method MS now releases seems to be .SomethingAsync(). I likened it today to having a garden hose in a Victorian sewer but then declaring the sewer is the bottle neck, async/await to the rescue! Most people use it in totally inappropriate scenarios, for no good reason but adding a load of complexity to your code and debugging. But your sewer is now even bigger! Look at how you can throw that hose around! I was working on a code base where the old developers had started going async/await for 'performance reasons'. Cue me ripping it all out, actually fixing the performance problems and downsizing the client from a P1 to a S1 in azure with 3x the load and vastly better page load speeds. It's almost always a premature optimisation. My opinion is don't ever use it unless you actually know what the specific bottleneck is that async/await will fix and you actually need it. async/await in javascript is actually useful.
hashhar 10y ago
Really happy with the development pace. I started using it by contributing to VSCode and was very pleased with the great tooling and sane language and syntactic sugar.
ohstopitu 10y ago
I recently started using TS instead of JS and I've been loving it. I find errors much earlier and while the tooling could be a bit better, I honestly find it less exhausting than keeping up with Babel.
timruffles 10y ago
If you still haven't given TypeScript a go as a Javascripter, now is a great time to do so. Whether you end up adopting it or not, it's interesting to get the types out of your mind and into the code. The first time you feel the speed/confidence of refactoring with accurate 'Find usages', you'll decide if the undeniable overhead of types is worth it.
- g00gler 10y ago
  I have to second Mr.timruffles. After using TS in a couple of projects I grew to miss it when I couldn't use it. If you don't like the C#-ness of Typescript, try using Facebook's flow. Typing isn't a magic bullet, typescript isn't even type safe, but it sure makes development easier and your apps more stable.
  - eklavya 10y ago
    "Typing isn't a magic bullet, ..., but it sure makes development easier and your apps more stable." That right there is the whole essence of typed programming :)
    - stcredzero 10y ago
      Going one level deeper, the underlying truism is that computers make better bean counters than people, even programmers. Type systems are good insofar as they free up cognitive resources of the programmer. Conversely, type systems are bad when they make programmers burn attention resources without enough return. (This is a difficult thing for people to evaluate, because sometimes the "return" from a type system can pay off many years later.) Again, it all comes down to cost-benefit. A new, modern 21st century language should be designed with the above in mind. The type system should make the resulting apps more stable, stay out of the way of coders reading code and writing new code, yet enable powerful tooling that doesn't need a heavyweight background process running a O(n^4) algorithm to collate meta-level information to enable all the IDE features. (Ideally, the tooling should be able to parse everything it needs to parse at some small multiple of the time it takes to read the source files off the drive.) Again, it's all about cost-benefit! "Elegance" or popularity with tech hipsters be damned, what's the cost, and what does it get you? (The nickel-and-dime costs of waiting around for lugubrious and unresponsive tools not only add up, they operate with some huge multiplier effect.)
haapanen 10y ago
Awesome! Been waiting for this for a long time! It's pretty interesting how much code gets generated for just async function() {} :)
jensvdh 10y ago
Typescript is a game changer for any serious project. Never going back to plain JS.
- edblarney 10y ago
  Concur. I am basically 'anti religious' when it comes to software. So many people argue back and forth about this or that, and 80% of arguments are academic and effete (this is what I mean be 'religious'). But I'm a big supporter of TS because I believe 'it makes sense' on almost every level. I'm not a 'big supporter' of many things at all, if any. I understand the limitations, and that it enforces some things for which we may want more flexibility ... but overall, I have to say I can't think of any reason ever to use JS again. My hope is that V8 etc. build engines to run TS directly as opposed to having to transpile.
  - deleted 10y ago
    [deleted]
nojvek 10y ago
Would be so cool if the js engines ignored types like python3. Then I could just write Typescript and run it on node/browser
- tomatsu 10y ago
  That would work except for enums. That's the one simple thing the engine actually has to do.
  - nojvek 10y ago
    JS should just really support enums. Its such a great feature of a core language. I wonder if there is any ES proposal for enums.
- josteink 10y ago
  Got a link to more info on that python thing? Sounds interesting.
  - WorldMaker 10y ago
    The PEP on it: https://www.python.org/dev/peps/pep-3107/ https://www.python.org/dev/peps/pep-3107/ Basically, Python 3 added syntax for annotations, but most of the syntax is make sure it parses like code expressions would, then ignore whatever those code expressions are.
libria 10y ago
I like the functionality of let merged = { ...foo, ...bar, ...baz }; But I've come to understand ... as variadic parameters in C++, Java and Go. Wish they'd used another token.
- patates 10y ago
  It depends on the context. In JS variadic parameters are also supported. This is like complaining they confusingly use curly braces around function bodies while you got used to them surrounding object declarations :)
- tomatsu 10y ago
  Spread (for arrays) was added with ES6. This just adds that kind of thing for objects (ES2017). let a = [1, 2, 3]; Math.max(...a); // 3 If you use that operator in parameters, it's rest (i.e. variadic stuff). function sum(...numbers) { return numbers.reduce((a, b) => a + b, 0); } sum(1, 2, 3, 4, 5); // 15
- WorldMaker 10y ago
  JS admits that ... is two operators ("spread" and "rest"), but that they are essential related/cousins (dual in mathematics terminology) and it works well for both of them to look the same. Rest is the variadic case: function myFunction(a, b, ...rest) { } But rest can also be used for destructuring, such as: let [a, b, ...rest] = ['a', 'b', 'c', 'd'] Or let { a, b, ...rest } = { a: 'a', b: 'b', c: 'c', d: 'd' } In this case it's a extra-bang-for-the-buck expansion of variadic parameters into something more generally useful: tearing apart lists (and now objects). From that light, spread is the "structuring" side of rest, in the left-hand/right-hand world of destructuring/structuring.
jasonallen 10y ago
Feels like Typescript is building (or has built up?) more momentum than Flow.
- treve 10y ago
  I don't think Typescript has ever not been bigger, but could be wrong here.
- Vekz 10y ago
  Its true and unfortunate. Typescript is the new Coffeescript. It splits the ecosystem. Flow is a progressive enhancement and improves the ecosystem. Typescript has had more push in the mindshare marketing from Microsoft.
  - wereHamster 10y ago
    TypeScript doesn't split the community any more than Flow does. TypeScript remains very close to ES2016/2017, syntax-wise, with the only major difference being type annotations, but you have those with flow as well. Anybody who can read JavaScript can read TypeScript.
    - thejameskyle 10y ago
      Flow tries to integrate with the existing ecosystem as much as possible. By taking advantage of Babel, ESLint, Atom, etc. With Flow you don't even have to opt-in to a new syntax. You can just use comments: function foo(val /* : boolean */) /* : string */ {} Using really powerful inference you can also write much fewer types. If you have well types libraries [you sometimes don't need types in your code at all](https://medium.com/@thejameskyle/flow-mapping-an-object-373d64c44592 https://medium.com/@thejameskyle/flow-mapping-an-object-373d...).
      - josteink 10y ago
        > With Flow you don't even have to opt-in to a new syntax. You can just use comments: So you use a opt-in comment-based syntax instead of a opt-in non-comment based one for type-annotations. Hardly a big difference. > Using really powerful inference you can also write much fewer types I'm just going to assume you didn't know typescript does this too. Typescript is nice. You should give it a try once. You may end up surprised:)
euroclydon 10y ago
One thing I never understood with Babel is which features are shimmed in the output JS and which features are re-implemented? What I means is: I didn't know how to tell Babel which browsers I was targeting, and I'm pretty sure that some of their feature implementations do not feature test the platform before activating, since they were so compiled in. Is that the case? Also, do you have to tell TypeScript your target runtime for it to it to use it's ES3 async/await logic vs. it's ES2015 (which uses generators), or does it automatically figure it out?
- hzoo 10y ago
  You might be interested in https://github.com/babel/babel-preset-env https://github.com/babel/babel-preset-env :D. (I'm working on it so let me know if you have questions)
- pimterry 10y ago
  You do tell TypeScript which runtime you're targeting, and that's how it decides how to compile it. You either set `target` in your tsconfig.json, or you provide `--target` on the command line. Docs: https://www.typescriptlang.org/docs/handbook/compiler-options.html https://www.typescriptlang.org/docs/handbook/compiler-option...
- mhink 10y ago
  They're getting better at describing which features are shimmed, but the easiest way to check is by running a single plugin on a bit of code and seeing for yourself. For instance, I decided just now to check if `transform-object-rest-spread` included an Object.assign polyfill (because spread syntax transpiles to Object.assign behind the scenes.) With the following input: var foo = { x: 1, y: 2 }; var bar = { a: 3, b: 4, ...foo }; var baz = new Promise(function(resolve, reject) { resolve("quux"); }); I get the following output var _extends = Object.assign || function (target) { for (var i = 1; i < arguments.length; i++) { var source = arguments[i]; for (var key in source) { if (Object.prototype.hasOwnProperty.call(source, key)) { target[key] = source[key]; } } } return target; }; var foo = { x: 1, y: 2 }; var bar = _extends({ a: 10, b: 11 }, foo); var baz = new Promise(function(resolve, reject) { resolve("quux"); }); The problem here, (to borrow phrasing from the docs) is that "Babel uses very small helpers for common functions such as _extend. By default this will be added to every file that requires it. This duplication is sometimes unnecessary, especially when your application is spread out over multiple files." To solve this problem, many people use the `transform-runtime` plugin [1] as well. To put it shortly, it replaces inline helper functions (like _extends in the example above) with imports from an adapter module called 'babel-runtime', which itself exposes the relevant polyfills (regenerator[2] and core-js[3]). With `transform-runtime`, I get the following: import _Promise from "babel-runtime/core-js/promise"; import _extends from "babel-runtime/helpers/extends"; var foo = { x: 1, y: 2 }; var bar = _extends({ a: 10, b: 11 }, foo); var baz = new _Promise(function (resolve, reject) { resolve("foo"); }); Notice that the Promise implementation was polyfilled as well. > I didn't know how to tell Babel which browsers I was targeting... You might *really like babel-preset-env[4], a new project they just launched. Basically, you give it a set of browser targets (much like autoprefixer) and it works out exactly which plugins you need to support the latest (currently es2015, I think) version of javascript. Hope that helps! Sorry for going on a Babel-related spiel in a Typescript thread, couldn't help myself. ;) 1: http://babeljs.io/docs/plugins/transform-runtime/#technical-details http://babeljs.io/docs/plugins/transform-runtime/#technical-... 2: https://facebook.github.io/regenerator/ https://facebook.github.io/regenerator/ 3: https://github.com/zloirock/core-js https://github.com/zloirock/core-js 4: https://github.com/babel/babel-preset-env https://github.com/babel/babel-preset-env
mwcampbell 10y ago
Any plans to add C#-like extension methods to TypeScript? Or is there a way to achieve the same thing already? I know that a previous suggestion to add extension methods was closed as out of scope. But maybe it's time to revisit that, since TypeScript is now doing significant code transformations for downlevel await support.
- patates 10y ago
  JavaScript already allows you to do something very similar to extension methods by extending prototypes. OTOH, a function accepting an object which implements a specific interface as a parameter will make your code much more easier to extend, instead of modifying the prototype of a concrete class.
- tomatsu 10y ago
  The bind operator (::) would allow you to write "virtual methods". https://github.com/tc39/proposal-bind-operator https://github.com/tc39/proposal-bind-operator (stage 0)
- RyanCavanaugh 10y ago
  It's not possible to add extension methods to TS in a way that would be usable in practice. https://github.com/Microsoft/TypeScript/issues/9 https://github.com/Microsoft/TypeScript/issues/9 has a long discussion of the problems with trying to do this.
smrtinsert 10y ago
Incredible release. Was definitely waiting for the spread/rest improvements as well as being curious about the async stuff. TypeScript continues to be for me the clear winner of the alt.js languages.
crudbug 10y ago
Coming from Java land, TS is a life saver for front-end development. Any plans for .NET Core / CLR backend ? I think, this will be the silver bullet. TS types should be able to generate statically compiled bytecode => native binary ?
- dsp1234 10y ago
  You can create TypeScript models from C# already. TypeLITE[0] will generate TS models using T4 templates. TypeWriter[1] is a visual studio extension that regenerates TS models whenever you save a file. [0] - http://type.litesolutions.net/ http://type.litesolutions.net/ [1] - https://frhagn.github.io/Typewriter/ https://frhagn.github.io/Typewriter/
ausjke 10y ago
Been a Linux developer for ages C# was never my taste, I'm still a bit Microsoft-hatred as of now(Visual Studio Code is the only item I adopted for JS development, the rest languages I still use vi/Geany). How tightly TS is related to C#? That has been the main reason I had not tried TS seriously so far. Don't want to have anything to do with C#. I know...
- ygra 10y ago
  They are not related at all, except in who is their original designer. However, if you are really so fundamentally opposed to anything and everything a certain language represents then you've got to hate a lot of languages for a really, really petty reason.
  - ausjke 10y ago
    For the record I embrace all new stuff except for two, that is Microsoft at-large and systemd.
    - pitaj 10y ago
      Oracle should probably on that list
      - ausjke 10y ago
        YES!!! However my projects so far have not had anything to do with it yet, and will never be.
- tomatsu 10y ago
  > How tightly TS is related to C#? TS is a superset of ES6+. So, not much. Dart is closer to C#, I'd say. C# is a well-designed language, though. You can't say that about the first iterations of JS and none of its baggage was ever dropped for the sake of maintaining backwards compatibility. TS gently pushes you in a more modern direction, which means that those JS issues matter much less in practice. It works pretty well. It does what it's supposed to do; it makes working on larger projects much more manageable. If you write a lot of JS, I highly recommend to check it out.
aj0strow 10y ago
The easier imports solves my biggest issue with migrating an existing project over. I'd say TypeScript is "ready" now. The last feature I'd want is an easy way to map nested json into classes rather than interfaces. Anyone know how?
- ubertaco 10y ago
  An approach I've seen is to have each class extend from some abstract base class (I know, OO blech) that looks like this: abstract class AbstractClassObject { constructor(json?: any){ if (json){ this.updateFromJSON(json) } } public updateFromJSON = (json: any): this => { Object.assign(this, json); return this; } } That gives you the "magic" just by extending the base, while also allowing custom behavior for a given class (by overriding updateFromJSON).
  - wereHamster 10y ago
    That only works for primitive types. As soon as you start using classes and sumtypes then you need an explicit parser. I wrote one for a client about a year ago. It took a lot of effort but well worth it.
  - aj0strow 10y ago
    Yeah but assigning doesn't really work for nested classes. class Post { id: string; user: User; // <- should be typeof User } I was hoping for something like Golang json.Unmarshal.
ggregoire 10y ago
> Object Rest & Spread Great news! That will finally fix the syntax errors in VSCode. :) https://github.com/Microsoft/vscode/issues/1974 https://github.com/Microsoft/vscode/issues/1974 https://github.com/Microsoft/vscode/issues/3804 https://github.com/Microsoft/vscode/issues/3804
polskibus 10y ago
Still no VS 2013 support? We're stuck on 1.8 for a while. It would be great if they supported VS 2013 at least until they release 2017.
- eropple 10y ago
  So this is totally a hack, but have you tried changing the manifest in the VSIX (it's just a zip file) and seeing if it installs?
  - polskibus 10y ago
    The official installer seems to be an exe, not a vsix, moreover VS2015 requires update 3 so there's probably more to it than just a manifest hack.
    - eropple 10y ago
      Ah, bummer. Just a thought. =(
avitzurel 10y ago
I'm getting a 404 on this. Anyone else?
- avitzurel 10y ago
  nvm. After a couple of tries it's working again
netcraft 10y ago
another anecdote - ive been using TS2.1 for the last month on three interconnected projects - a rest api, an express app and also for client side code in that express app - it has been a great experience. async/await is a godsend and @types/ makes what used to be a terrible process much more streamlined and easy. If you have to write JS, typescript is the best way ive ever found.
garysieling 10y ago
TypeScript is great. I built https://www.findlectures.com https://www.findlectures.com over a year, starting in plain Javascript. Once the codebase was large enough that got stuck I added TypeScript, and it's been great for isolating defects. It's nice paired with React (vs PropTypes) because the checking happens a lot earlier and is much richer.
- mads 10y ago
  Nice site. I know what I will be doing tonight, when I arrive home. Thanks :)
  - garysieling 10y ago
    Awesome. Feel free to contact me if you have questions/ideas or if you find anything you really like :)
k__ 10y ago
Are there any plans to catch something like this: function f(x: any): T { return x }
- pimterry 10y ago
  That would defeat the point of 'any', right? It's for variables that you want to allow to do anything (including be a T) without the compiler complaining. If you don't want that behaviour, don't given x 'any' type. In that case there I'd probably use '{}' instead, and then use type guards (https://www.typescriptlang.org/docs/handbook/advanced-types.html#type-guards-and-differentiating-types https://www.typescriptlang.org/docs/handbook/advanced-types.... to convince TypeScript that it's a T (whatever that means).
  - k__ 10y ago
    tslint has a rule to prohibit the use of any. maybe this is worth an option for tsc
    - pimterry 10y ago
      Maybe, but I think there's a lot of cases where you want to be able to use 'any' explicitly. Tsc does already have noImplicitAny, so you have to have opted in to this behaviour.
co_dh 10y ago
I feel that the lookup types and mapped types are dependent types, am I right?
Noseshine 10y ago
Question: Is it possible to have a setup with TypeScript where it is guaranteed that no code changes occur other than removal of the type information? I started using Flow, found what it can and can't do and would like to try TypeScript. But only if I can have "types-only", I don't want my code "translated" in any way. I'm writing for the latest node.js version and not for x different browsers, I want to use exactly what that version supports and have no code-changing steps. With Flow I use flow-remove-types (https://github.com/leebyron/flow-remove-types https://github.com/leebyron/flow-remove-types) to remove the types. It leaves spaces where there was type-related code and doesn't touch the code itself.
- seanmcdirmid 10y ago
  TypeScript seems to have been very religious about following "Bracha's law" (types shouldn't effect program semantics), and I'm unaware of any translations they do beyond supporting some new features on previous platforms (e.g. classes on pre-es6). It is kind of annoying sometimes actually, in that typescript can't support niceties like operator overloading or extension methods because that would require de-sugaring.
- RyanCavanaugh 10y ago
  TypeScript and Flow have the same behavior with regard to removing types, and TypeScript and Babel have the same behavior with regard to downleveling ES6+ code to ES5- If you target ES6 with TypeScript and only write ES6-compliant code (plus types), you won't get any downleveling of features, so your code will always be the same as you wrote it (other than the removal of types). If you use TS-specific features like 'enum' or 'namespace', there will necessarily be some rewriting of your code to turn it into usable JS, but those features are entirely optional.
- TAForObvReasons 10y ago
  With flow you can do one better: type comments! https://flowtype.org/blog/2015/02/20/Flow-Comments.html https://flowtype.org/blog/2015/02/20/Flow-Comments.html You actually wrap the type annotations in comments and flow will recognize them. You can use the source with the type comments in your browser! As an example, the flow checker will read the annotations from `function f(n/:number/, s/:string/) { ... }` but since they are commented in the source code your JS engine ignores them. This is amazing for typing existing code, since at every step you are merely inserting comments into your code. And your existing minification step will strip them out :)
yulaow 10y ago
Anyone knows any good resources to learn typescript? The tutorials on the official site are really... bad. Like I would not even call them tutorials.
- stupidcar 10y ago
  I really like the video courses on egghead.io: https://egghead.io/technologies/typescript https://egghead.io/technologies/typescript You do have to pay for some of them, but there's some free ones as well.
jtmarmon 10y ago
Can someone comment on the difference in reliability between using typescript and a natively statically typed language like haskell or scala? Is there any? Or is the type safety really as good when you use ts
- jiaweihli 10y ago
  I haven't worked too much with Haskell, but I've spent some time with Scala - they have pretty advanced type systems. Typescript can't match them 100%, but it's getting there. e.g. It doesn't have type variance, but it does have f-bounded polymorphism (which is unheard of in most mainstream languages). The language is powerful enough to build your own constructs. I maintain a Typescript library[1] that emulates Scala options/trys/futures. For day-to-day work, Typescript is a joy to work with. I describe it to others as the child of Scala and Ruby - pretty powerful type system but with a large community. [1] https://github.com/jiaweihli/monapt https://github.com/jiaweihli/monapt
- virtualwhys 10y ago
  They're different things, TS is a transpiler while Haskell (GHCJS) and Scala (Scala.js) compile respective host languages to javascript. In a perfect world you'd go with the latter, but there's overhead involved (relatively slow compilation and large generated binaries) that is mostly absent in TS. Also worth noting that TS' community is gigantic in comparison to that of Scala.js and GHCJS.
  - jtmarmon 10y ago
    I was asking about the native languages themselves and their typesystems, not the compile-to-js versions of those languages. Regardless, I don't see much of a difference between TS -> JS and haskell->JS and scala -> JS. It's all from one language to another. the fact that TS is still considered a form of javascript is kind of irrelevant other than for semantics
    - virtualwhys 10y ago
      > I was asking about the native languages themselves and their typesystems, not the compile-to-js versions of those languages. Are they different? If language X can be expressed in its entirety as language Y then we can speak about X and Y interchangeably -- that's literally the point: full interop between client and server. Anyway, there's a world of difference between TS and GHCJS, Scala.js, Clojurescript, Js_of_ocaml, etc. One speaks javascript, the others speak both. As for reliability, in so far as TS is typed it will provide the compile time guarantees that its type system provides; not surprisingly the same goes for Scala.js, GHCJS, etc. So, the decision point probably hinges more on aforementioned overhead, size of community, and tooling than language/type system features/power. If it were otherwise we'd have seen a huge uptick by now wrt adoption rates for the compile-to-js languages. Maybe that will change in future but for now the big players drive the javascript bus...
edblarney 10y ago
After trying TS, I basically never want to write JS again. I know that 'OO' and 'typing' is not the solution to everything ... but aside from all the nice things you can do in TS ... the 'enforced architecture' of OO-ish paradigms, combined with typing, and essential obfuscation of the prototype paradigm ... has cut the time to development in half. I can hardly think of a reason to use JS now that TS exists. Of course - there are some reasons, in some specific situations, but by and large, TS is the future.
- woah 10y ago
  What OO does typescript have that js doesn't?
  - edblarney 10y ago
    + Member access private/protected + Static members (theoretically exist in JS, but much cleaner and 'compiler aware' in TS) + Interfaces When I write JS, I end up with closures within closures within closures. When I write TS, I find myself sticking to much cleaner abstraction. I end up (having to) create classes, and usually it's for the better.
    - woah 10y ago
      A class is a pretty bad abstraction to try to fit the world into. It might work for some things, but it usually results in a lot of ceremony, and a lot of concepts in your program that exist only to service the abstraction. It's useful in JS for some special cases, but being forced into it is just going to make your code verbose and complicated for no reason. I'll stick to Flow for now.
      - DanRosenwasser 10y ago
        For the record, you're not forced into it at all. I'll mention that in the TypeScript compiler, we use very few classes at all - it's mostly written in a function-oriented style. TypeScript tries not to impose any sort of restrictions on coding style.
edblarney 10y ago
Dear TS authors: Thank you (!) for your amazing contributions. TS is the best new thing in tech. That said: Your linguistic genius is way ahead of the tooling. I feel as though some of these 'new and cool' 2.1 things are a little bit intellectual, maybe useful in some cases ... But getting TS to work in the real world, the various build configurations, tool-chains etc. - it's still clumsy. It was difficult to grasp the difference between AMD and other paradigms. I still have problems with circular dependencies, or rather, things happening before modules are loaded. Here's one pain point: Creating a static attribute on a class and initializing it right there, as in: class A { static b:B = new B(); } Means that 'new B()' will get executed right when that module is loaded, possibly before the module containing B is loaded. It's ugly, mechanical - but it's not a 'fine point'. I think these are the kinds of issues which are more likely to hold people back, as opposed to the lack of some rather fancy new paradigms such as 'Mapped Types'. Anyhow, keep up the good work. Lovin't it.
- thejameskyle 10y ago
  > Creating a static attribute on a class and initializing it right there, as in: class A { static b:B = new B(); } That is how the ECMAScript spec is designed. And TypeScript _should_ follow the spec.
  - edblarney 10y ago
    Yes, it needs to be created 'right there' - but not in the context of other modules loads. I doubt that a strict interpretation requires that it does so before other modules are loaded. I suggest that 'right there' , i.e. the execution context can be delayed until mods are loaded. One could argue that all modules could be loaded before execution context. In Java, for example, you do not have this problem and yet, in Java we would say the attribute is initialized 'right there' as well. Obviously, when I say 'loaded' I don't mean 'executed'. In any event, it's a problem.
- WorldMaker 10y ago
  Your pain point sounds like a runtime problem with your module loader. You may want to investigate your module loader's issue tracker. (I recommend SystemJS [and jspm] over AMD these days, for what that is worth. It handles module loading quite well including all the complexity of circular dependencies that ES2015 specced and TS supports.) «I feel as though some of these 'new and cool' 2.1 things are a little bit intellectual, maybe useful in some cases ...» async/await and object spread should be useful in quite a lot of places. The other "intellectual" additions are immediately useful indirectly because they were built to support object spread (so that object spread types make sense), even if you don't wind up using the directly (because you aren't writing complicated type definition files for instance). Even then, you might find a bunch of uses for the types Partial<T> (partial objects) and Readonly<T> (shallowly frozen objects).
lacampbell 10y ago
How does the development cycle work? With plain JS I load up my html page in browser (chrome) and head to the console to check for errors in the JS. Then I do user testing. Can type-script be debugged by a browser on a source code level - ie not on a transpiled level? If not, I am not sure if it's worth it. And I say that as someone who is a huge fan of explicit optional typing.
- jhchen 10y ago
  In theory source maps is the answer but personally this has only worked some of the time. When it does work though it is magical and exactly answers your question of debugging in the browser at the source level.
- autogol 10y ago
  The development cycle is basicaly this: write Typescript code in a .ts file, transpile to a .js file, load .js into html. Transpiling can be handled by the IDE or by a build tool like gulp. For example, IntelliJ Webstorm has a built-in file watcher that tracks changes to .ts files and transpiles accordingly. Typescript can be debugged on a source code level, using source-maps. Webstorm and VS Code have built-in or plugin solutions. I heard some people complaining about issues, but i had a pretty smooth experience so far.
- WorldMaker 10y ago
  There is typically a quick transpile process in the IDE/toolchain of your choice. Most browser dev tools now support sourcemaps quite well which means that debugging shows the TS source and breakpoints are set directly there and typically show error stacktraces with your TS files. Another option is to load Typescript in your browser and let it transpile directly in the browser. Sourcemaps in this case are a bit more iffy in their browser support, but it can be an option for a quick debug cycle if you wanted to try something like that. Not particularly the fastest idea for a production app, though.
euroclydon 10y ago
The proposal for async/await is education, to say the least. The specs for modern and older browser/js-engines are in there. Turns out they implement two case statements, and handle every possible control structure. https://github.com/Microsoft/TypeScript/issues/1664 https://github.com/Microsoft/TypeScript/issues/1664
boubiyeah 10y ago
Congratulation to the TS team. We are happily using it at work, it's such a tremendous upgrade over javascript, while keeping the entire ecosystem at hand.
time4tea 10y ago
The noImplicitAny flag just doesn't make sense. You changed the new default behaviour to be the thing you don't recommend?
- mohamedhegazy 10y ago
  `--noImplicitAny` is the recommended flag. It is not set by default to ease the use on JS code bases. The new changes makes `--noImplicitAny` require less type annotations; where the compiler can figure out the type of a variable through following the control flow.
tkubacki 10y ago
Dart 1.21 is out today too - with generic methods support news.dartlang.org
daxfohl 10y ago
Seems like a great foundation to build something like F# type providers on top of.
voltagex_ 10y ago
What's the future of TypeScript in Visual Studio (not Code)? I've got a project that just silently fails to build in VS - no errors, no warnings, build successful - but no output. It seems like the Typescript tools inside VS2015 (even with the latest update) just aren't ready.
thewhitetulip 10y ago
I recently started learning JS, and now I am confused between TS and babel. Can anyone give me a reason why I should use either of the two and when I should use either of the two?
- pitaj 10y ago
  TS adds a complete static type-checking system, and also will compile down your bleeding-edge JS language features into supported syntax. Babel will do the second part.
  - thewhitetulip 10y ago
    Thank you!
ken47 10y ago
I've been using Typescript for over a year, and the amount of improvement in that relatively short time span has been incredible. With 2.1, Typescript shows no signs of slowing down.

503 points by DanRosenwasser 10y ago

koolba 10y ago

So can I finally banish babel from my build steps?

saosebastiao 10y ago
I did while 2.1 was an RC. It has worked flawlessly and I haven't looked back. Build and minification is still a pain though...
- jiaweihli 10y ago
  Try webpack, it's fast and the configuration is nearly declarative. You can also create a separate build task to run a smoke test by directly calling the ts compiler to compile your code (skipping pre- and post- build steps). This was a lot faster than I expected.
kevinsd 10y ago
The post did not mention anything about babel (or whether it is still needed). Any pointers?
WorldMaker 10y ago
I think I'm still waiting hopefully on an answer to supporting more automatic polyfill imports before banishing babel entirely. (Though the big one has been an Object.assign polyfill and certainly object spread removes a lot of the need for that.) I also would need to straighten out some things with how I'm handling TSX I think.

seattle_spring 10y ago

Seems like all of the new features have been available in Flow for quite a while now.

manojlds 10y ago
Flow is not a language
- tomatsu 10y ago
  https://flowtype.org/ https://flowtype.org/ function bar(x): string { That's not JavaScript.
  - thejameskyle 10y ago
    If that's too much you can also do: function bar(x) /* : string */ { No compiling necessary
- ygra 10y ago
  I'm fairly sure it has a grammar.
raphinou 10y ago
Typescript seems to get a lot more attention (at least on HN). How does Flow progress? How is the community around it? I'm curious to know more as an external to both projects.
icholy 10y ago
The new type system features are: keyof, lookup types, and mapped types. Does flow have even one of these?
- seattle_spring 10y ago
  $Keys<> for keyof, $MapObj<> for mapped types. They are sorely missing lookup types though.
  - curveship 10y ago
    I can't seem to find any info online about $MapObj<>? I searched the docs, google ... nuthin'. Am I just missing something?

n0us 10y ago

I have been waiting for object rest and spread for ages. Thank you to the maintainers for working hard on this feature.

k__ 10y ago
Same here. I already used it exessively in JavaScript to prevent mutations and missed it a bit in TypeScript.

ihsw 10y ago

Async/await support for most browsers and node-0.12+ is definitely a welcome feature, callback hell and tripping over promise chains is definitely one of the most painful experience in TS development IMO.

ng12 10y ago

Hurrah for object spreads! Time to go grepping for calls to _.default and _.extend.

WorldMaker 10y ago
Also, Object.assign
- Sankozi 10y ago
  Unfortunately newThing = {...thing, propertyName: value} Will always compile, even if propertyName is invalid. The only advantage over Object.assign I see is IDE support (at least in Intellij IDEA). I will still use: newThing = Object.assign({}, thing); newThing.propertyName = value; This will not compile if propertyName is invalid and is IDE friendly.
  - WorldMaker 10y ago
    You should be able to add a type requirement and get the error you are expecting. Instead of this: let newThing = { ...thing, propertyName: value } // type of newThing would be deduced: TypeOfThing & { propertyName: TypeOfValue } If you add the type requirement the compiler should balk on the propertyName: let newThing: TypeOfThing = { ...thing, propertyName: value } ETA: You'd have the same lack of compiler error if you were instead using: let newThing = Object.assign({}, thing, { propertyName: value }) Because Object.assign will also build intersection types by default.

tjbarbour 10y ago

" We spread ourselves thin, but this is the moment you’ve been awaiting – TypeScript 2.1 is here! "

nojvek 10y ago
I read that first and I was like "o_O". After reading the rest I was "O_O". Nice pun.

msoad 10y ago

We are using async await with 2.1 rc and it works flawlessly. I also love the keyof, with that we can remove tons of "any" types from our code base. Amazing work TypeScript team! This release has been a lot of work!

zdragnar 10y ago

It's interesting to me that all of the initial reactions I've seen to this announcement have been around the introduction of async and object spread, which are available with babel, but the typescript specific features such as mapped types are completely ignored. I don't really have any particular meaning behind that observation, only that it tickled my funny bone a little bit.

nozzlegear 10y ago
For me, I'm excited because this announcement means I can finally remove Babel from my compile process and just rely on TypeScript to do all of the magic for me.
DanRosenwasser 10y ago
TypeScript PM here - the reason for that is that when we implement a feature in TypeScript, we take lengths to ensure that it is typed appropriately and that its performance characteristics are reasonable. That means that when using object rest/spread, we didn't want to just ship an experience where type type is effectively `any`, leading users to be frustrated if they make an error. With async/await, we had to rewrite our emit pipeline, which meant that we needed to keep parity in both output as well as time to emit. The investment has shown, and TypeScript is still extremely fast. We're always willing to think about different approaches, but those are some of the rationales here.
- vyrotek 10y ago
  As a long-time .NET dev... Thank You for Async/Await in TypeScript.
  - mattmanser 10y ago
    async/await in C# is pretty nasty and usually overused and overhyped for nothing but downside. It screws debugging, it screws call stacks, it dictates you to write bad code and it's just plain complicated. It infects your code up and down the stack and every new method MS now releases seems to be .SomethingAsync(). I likened it today to having a garden hose in a Victorian sewer but then declaring the sewer is the bottle neck, async/await to the rescue! Most people use it in totally inappropriate scenarios, for no good reason but adding a load of complexity to your code and debugging. But your sewer is now even bigger! Look at how you can throw that hose around! I was working on a code base where the old developers had started going async/await for 'performance reasons'. Cue me ripping it all out, actually fixing the performance problems and downsizing the client from a P1 to a S1 in azure with 3x the load and vastly better page load speeds. It's almost always a premature optimisation. My opinion is don't ever use it unless you actually know what the specific bottleneck is that async/await will fix and you actually need it. async/await in javascript is actually useful.

hashhar 10y ago

Really happy with the development pace. I started using it by contributing to VSCode and was very pleased with the great tooling and sane language and syntactic sugar.

ohstopitu 10y ago

I recently started using TS instead of JS and I've been loving it. I find errors much earlier and while the tooling could be a bit better, I honestly find it less exhausting than keeping up with Babel.

timruffles 10y ago

If you still haven't given TypeScript a go as a Javascripter, now is a great time to do so. Whether you end up adopting it or not, it's interesting to get the types out of your mind and into the code. The first time you feel the speed/confidence of refactoring with accurate 'Find usages', you'll decide if the undeniable overhead of types is worth it.

g00gler 10y ago
I have to second Mr.timruffles. After using TS in a couple of projects I grew to miss it when I couldn't use it. If you don't like the C#-ness of Typescript, try using Facebook's flow. Typing isn't a magic bullet, typescript isn't even type safe, but it sure makes development easier and your apps more stable.
- eklavya 10y ago
  "Typing isn't a magic bullet, ..., but it sure makes development easier and your apps more stable." That right there is the whole essence of typed programming :)
  - stcredzero 10y ago
    Going one level deeper, the underlying truism is that computers make better bean counters than people, even programmers. Type systems are good insofar as they free up cognitive resources of the programmer. Conversely, type systems are bad when they make programmers burn attention resources without enough return. (This is a difficult thing for people to evaluate, because sometimes the "return" from a type system can pay off many years later.) Again, it all comes down to cost-benefit. A new, modern 21st century language should be designed with the above in mind. The type system should make the resulting apps more stable, stay out of the way of coders reading code and writing new code, yet enable powerful tooling that doesn't need a heavyweight background process running a O(n^4) algorithm to collate meta-level information to enable all the IDE features. (Ideally, the tooling should be able to parse everything it needs to parse at some small multiple of the time it takes to read the source files off the drive.) Again, it's all about cost-benefit! "Elegance" or popularity with tech hipsters be damned, what's the cost, and what does it get you? (The nickel-and-dime costs of waiting around for lugubrious and unresponsive tools not only add up, they operate with some huge multiplier effect.)

haapanen 10y ago

Awesome! Been waiting for this for a long time! It's pretty interesting how much code gets generated for just async function() {} :)

jensvdh 10y ago

Typescript is a game changer for any serious project. Never going back to plain JS.

edblarney 10y ago
Concur. I am basically 'anti religious' when it comes to software. So many people argue back and forth about this or that, and 80% of arguments are academic and effete (this is what I mean be 'religious'). But I'm a big supporter of TS because I believe 'it makes sense' on almost every level. I'm not a 'big supporter' of many things at all, if any. I understand the limitations, and that it enforces some things for which we may want more flexibility ... but overall, I have to say I can't think of any reason ever to use JS again. My hope is that V8 etc. build engines to run TS directly as opposed to having to transpile.
- deleted 10y ago
  [deleted]

nojvek 10y ago

Would be so cool if the js engines ignored types like python3. Then I could just write Typescript and run it on node/browser

tomatsu 10y ago
That would work except for enums. That's the one simple thing the engine actually has to do.
- nojvek 10y ago
  JS should just really support enums. Its such a great feature of a core language. I wonder if there is any ES proposal for enums.
josteink 10y ago
Got a link to more info on that python thing? Sounds interesting.
- WorldMaker 10y ago
  The PEP on it: https://www.python.org/dev/peps/pep-3107/ https://www.python.org/dev/peps/pep-3107/ Basically, Python 3 added syntax for annotations, but most of the syntax is make sure it parses like code expressions would, then ignore whatever those code expressions are.

libria 10y ago

I like the functionality of let merged = { ...foo, ...bar, ...baz }; But I've come to understand ... as variadic parameters in C++, Java and Go. Wish they'd used another token.

patates 10y ago
It depends on the context. In JS variadic parameters are also supported. This is like complaining they confusingly use curly braces around function bodies while you got used to them surrounding object declarations :)
tomatsu 10y ago
Spread (for arrays) was added with ES6. This just adds that kind of thing for objects (ES2017). let a = [1, 2, 3]; Math.max(...a); // 3 If you use that operator in parameters, it's rest (i.e. variadic stuff). function sum(...numbers) { return numbers.reduce((a, b) => a + b, 0); } sum(1, 2, 3, 4, 5); // 15
WorldMaker 10y ago
JS admits that ... is two operators ("spread" and "rest"), but that they are essential related/cousins (dual in mathematics terminology) and it works well for both of them to look the same. Rest is the variadic case: function myFunction(a, b, ...rest) { } But rest can also be used for destructuring, such as: let [a, b, ...rest] = ['a', 'b', 'c', 'd'] Or let { a, b, ...rest } = { a: 'a', b: 'b', c: 'c', d: 'd' } In this case it's a extra-bang-for-the-buck expansion of variadic parameters into something more generally useful: tearing apart lists (and now objects). From that light, spread is the "structuring" side of rest, in the left-hand/right-hand world of destructuring/structuring.

jasonallen 10y ago

Feels like Typescript is building (or has built up?) more momentum than Flow.

treve 10y ago
I don't think Typescript has ever not been bigger, but could be wrong here.
Vekz 10y ago
Its true and unfortunate. Typescript is the new Coffeescript. It splits the ecosystem. Flow is a progressive enhancement and improves the ecosystem. Typescript has had more push in the mindshare marketing from Microsoft.
- wereHamster 10y ago
  TypeScript doesn't split the community any more than Flow does. TypeScript remains very close to ES2016/2017, syntax-wise, with the only major difference being type annotations, but you have those with flow as well. Anybody who can read JavaScript can read TypeScript.
  - thejameskyle 10y ago
    Flow tries to integrate with the existing ecosystem as much as possible. By taking advantage of Babel, ESLint, Atom, etc. With Flow you don't even have to opt-in to a new syntax. You can just use comments: function foo(val /* : boolean */) /* : string */ {} Using really powerful inference you can also write much fewer types. If you have well types libraries [you sometimes don't need types in your code at all](https://medium.com/@thejameskyle/flow-mapping-an-object-373d64c44592 https://medium.com/@thejameskyle/flow-mapping-an-object-373d...).
    - josteink 10y ago
      > With Flow you don't even have to opt-in to a new syntax. You can just use comments: So you use a opt-in comment-based syntax instead of a opt-in non-comment based one for type-annotations. Hardly a big difference. > Using really powerful inference you can also write much fewer types I'm just going to assume you didn't know typescript does this too. Typescript is nice. You should give it a try once. You may end up surprised:)

euroclydon 10y ago

One thing I never understood with Babel is which features are shimmed in the output JS and which features are re-implemented? What I means is: I didn't know how to tell Babel which browsers I was targeting, and I'm pretty sure that some of their feature implementations do not feature test the platform before activating, since they were so compiled in. Is that the case? Also, do you have to tell TypeScript your target runtime for it to it to use it's ES3 async/await logic vs. it's ES2015 (which uses generators), or does it automatically figure it out?

hzoo 10y ago
You might be interested in https://github.com/babel/babel-preset-env https://github.com/babel/babel-preset-env :D. (I'm working on it so let me know if you have questions)
pimterry 10y ago
You do tell TypeScript which runtime you're targeting, and that's how it decides how to compile it. You either set `target` in your tsconfig.json, or you provide `--target` on the command line. Docs: https://www.typescriptlang.org/docs/handbook/compiler-options.html https://www.typescriptlang.org/docs/handbook/compiler-option...
mhink 10y ago
They're getting better at describing which features are shimmed, but the easiest way to check is by running a single plugin on a bit of code and seeing for yourself. For instance, I decided just now to check if `transform-object-rest-spread` included an Object.assign polyfill (because spread syntax transpiles to Object.assign behind the scenes.) With the following input: var foo = { x: 1, y: 2 }; var bar = { a: 3, b: 4, ...foo }; var baz = new Promise(function(resolve, reject) { resolve("quux"); }); I get the following output var _extends = Object.assign || function (target) { for (var i = 1; i < arguments.length; i++) { var source = arguments[i]; for (var key in source) { if (Object.prototype.hasOwnProperty.call(source, key)) { target[key] = source[key]; } } } return target; }; var foo = { x: 1, y: 2 }; var bar = _extends({ a: 10, b: 11 }, foo); var baz = new Promise(function(resolve, reject) { resolve("quux"); }); The problem here, (to borrow phrasing from the docs) is that "Babel uses very small helpers for common functions such as _extend. By default this will be added to every file that requires it. This duplication is sometimes unnecessary, especially when your application is spread out over multiple files." To solve this problem, many people use the `transform-runtime` plugin [1] as well. To put it shortly, it replaces inline helper functions (like _extends in the example above) with imports from an adapter module called 'babel-runtime', which itself exposes the relevant polyfills (regenerator[2] and core-js[3]). With `transform-runtime`, I get the following: import _Promise from "babel-runtime/core-js/promise"; import _extends from "babel-runtime/helpers/extends"; var foo = { x: 1, y: 2 }; var bar = _extends({ a: 10, b: 11 }, foo); var baz = new _Promise(function (resolve, reject) { resolve("foo"); }); Notice that the Promise implementation was polyfilled as well. > I didn't know how to tell Babel which browsers I was targeting... You might *really like babel-preset-env[4], a new project they just launched. Basically, you give it a set of browser targets (much like autoprefixer) and it works out exactly which plugins you need to support the latest (currently es2015, I think) version of javascript. Hope that helps! Sorry for going on a Babel-related spiel in a Typescript thread, couldn't help myself. ;) 1: http://babeljs.io/docs/plugins/transform-runtime/#technical-details http://babeljs.io/docs/plugins/transform-runtime/#technical-... 2: https://facebook.github.io/regenerator/ https://facebook.github.io/regenerator/ 3: https://github.com/zloirock/core-js https://github.com/zloirock/core-js 4: https://github.com/babel/babel-preset-env https://github.com/babel/babel-preset-env

mwcampbell 10y ago

Any plans to add C#-like extension methods to TypeScript? Or is there a way to achieve the same thing already? I know that a previous suggestion to add extension methods was closed as out of scope. But maybe it's time to revisit that, since TypeScript is now doing significant code transformations for downlevel await support.

patates 10y ago
JavaScript already allows you to do something very similar to extension methods by extending prototypes. OTOH, a function accepting an object which implements a specific interface as a parameter will make your code much more easier to extend, instead of modifying the prototype of a concrete class.
tomatsu 10y ago
The bind operator (::) would allow you to write "virtual methods". https://github.com/tc39/proposal-bind-operator https://github.com/tc39/proposal-bind-operator (stage 0)
RyanCavanaugh 10y ago
It's not possible to add extension methods to TS in a way that would be usable in practice. https://github.com/Microsoft/TypeScript/issues/9 https://github.com/Microsoft/TypeScript/issues/9 has a long discussion of the problems with trying to do this.

smrtinsert 10y ago

Incredible release. Was definitely waiting for the spread/rest improvements as well as being curious about the async stuff. TypeScript continues to be for me the clear winner of the alt.js languages.

crudbug 10y ago

Coming from Java land, TS is a life saver for front-end development. Any plans for .NET Core / CLR backend ? I think, this will be the silver bullet. TS types should be able to generate statically compiled bytecode => native binary ?

dsp1234 10y ago
You can create TypeScript models from C# already. TypeLITE[0] will generate TS models using T4 templates. TypeWriter[1] is a visual studio extension that regenerates TS models whenever you save a file. [0] - http://type.litesolutions.net/ http://type.litesolutions.net/ [1] - https://frhagn.github.io/Typewriter/ https://frhagn.github.io/Typewriter/

ausjke 10y ago

Been a Linux developer for ages C# was never my taste, I'm still a bit Microsoft-hatred as of now(Visual Studio Code is the only item I adopted for JS development, the rest languages I still use vi/Geany). How tightly TS is related to C#? That has been the main reason I had not tried TS seriously so far. Don't want to have anything to do with C#. I know...

ygra 10y ago
They are not related at all, except in who is their original designer. However, if you are really so fundamentally opposed to anything and everything a certain language represents then you've got to hate a lot of languages for a really, really petty reason.
- ausjke 10y ago
  For the record I embrace all new stuff except for two, that is Microsoft at-large and systemd.
  - pitaj 10y ago
    Oracle should probably on that list
    - ausjke 10y ago
      YES!!! However my projects so far have not had anything to do with it yet, and will never be.
tomatsu 10y ago
> How tightly TS is related to C#? TS is a superset of ES6+. So, not much. Dart is closer to C#, I'd say. C# is a well-designed language, though. You can't say that about the first iterations of JS and none of its baggage was ever dropped for the sake of maintaining backwards compatibility. TS gently pushes you in a more modern direction, which means that those JS issues matter much less in practice. It works pretty well. It does what it's supposed to do; it makes working on larger projects much more manageable. If you write a lot of JS, I highly recommend to check it out.

aj0strow 10y ago

The easier imports solves my biggest issue with migrating an existing project over. I'd say TypeScript is "ready" now. The last feature I'd want is an easy way to map nested json into classes rather than interfaces. Anyone know how?

ubertaco 10y ago
An approach I've seen is to have each class extend from some abstract base class (I know, OO blech) that looks like this: abstract class AbstractClassObject { constructor(json?: any){ if (json){ this.updateFromJSON(json) } } public updateFromJSON = (json: any): this => { Object.assign(this, json); return this; } } That gives you the "magic" just by extending the base, while also allowing custom behavior for a given class (by overriding updateFromJSON).
- wereHamster 10y ago
  That only works for primitive types. As soon as you start using classes and sumtypes then you need an explicit parser. I wrote one for a client about a year ago. It took a lot of effort but well worth it.
- aj0strow 10y ago
  Yeah but assigning doesn't really work for nested classes. class Post { id: string; user: User; // <- should be typeof User } I was hoping for something like Golang json.Unmarshal.

ggregoire 10y ago

> Object Rest & Spread Great news! That will finally fix the syntax errors in VSCode. :) https://github.com/Microsoft/vscode/issues/1974 https://github.com/Microsoft/vscode/issues/1974 https://github.com/Microsoft/vscode/issues/3804 https://github.com/Microsoft/vscode/issues/3804

polskibus 10y ago

Still no VS 2013 support? We're stuck on 1.8 for a while. It would be great if they supported VS 2013 at least until they release 2017.

eropple 10y ago
So this is totally a hack, but have you tried changing the manifest in the VSIX (it's just a zip file) and seeing if it installs?
- polskibus 10y ago
  The official installer seems to be an exe, not a vsix, moreover VS2015 requires update 3 so there's probably more to it than just a manifest hack.
  - eropple 10y ago
    Ah, bummer. Just a thought. =(

avitzurel 10y ago

I'm getting a 404 on this. Anyone else?

avitzurel 10y ago
nvm. After a couple of tries it's working again

netcraft 10y ago

another anecdote - ive been using TS2.1 for the last month on three interconnected projects - a rest api, an express app and also for client side code in that express app - it has been a great experience. async/await is a godsend and @types/ makes what used to be a terrible process much more streamlined and easy. If you have to write JS, typescript is the best way ive ever found.

garysieling 10y ago

TypeScript is great. I built https://www.findlectures.com https://www.findlectures.com over a year, starting in plain Javascript. Once the codebase was large enough that got stuck I added TypeScript, and it's been great for isolating defects. It's nice paired with React (vs PropTypes) because the checking happens a lot earlier and is much richer.

mads 10y ago
Nice site. I know what I will be doing tonight, when I arrive home. Thanks :)
- garysieling 10y ago
  Awesome. Feel free to contact me if you have questions/ideas or if you find anything you really like :)

k__ 10y ago

Are there any plans to catch something like this: function f(x: any): T { return x }

pimterry 10y ago
That would defeat the point of 'any', right? It's for variables that you want to allow to do anything (including be a T) without the compiler complaining. If you don't want that behaviour, don't given x 'any' type. In that case there I'd probably use '{}' instead, and then use type guards (https://www.typescriptlang.org/docs/handbook/advanced-types.html#type-guards-and-differentiating-types https://www.typescriptlang.org/docs/handbook/advanced-types.... to convince TypeScript that it's a T (whatever that means).
- k__ 10y ago
  tslint has a rule to prohibit the use of any. maybe this is worth an option for tsc
  - pimterry 10y ago
    Maybe, but I think there's a lot of cases where you want to be able to use 'any' explicitly. Tsc does already have noImplicitAny, so you have to have opted in to this behaviour.

co_dh 10y ago

I feel that the lookup types and mapped types are dependent types, am I right?

Noseshine 10y ago

Question: Is it possible to have a setup with TypeScript where it is guaranteed that no code changes occur other than removal of the type information? I started using Flow, found what it can and can't do and would like to try TypeScript. But only if I can have "types-only", I don't want my code "translated" in any way. I'm writing for the latest node.js version and not for x different browsers, I want to use exactly what that version supports and have no code-changing steps. With Flow I use flow-remove-types (https://github.com/leebyron/flow-remove-types https://github.com/leebyron/flow-remove-types) to remove the types. It leaves spaces where there was type-related code and doesn't touch the code itself.

seanmcdirmid 10y ago
TypeScript seems to have been very religious about following "Bracha's law" (types shouldn't effect program semantics), and I'm unaware of any translations they do beyond supporting some new features on previous platforms (e.g. classes on pre-es6). It is kind of annoying sometimes actually, in that typescript can't support niceties like operator overloading or extension methods because that would require de-sugaring.
RyanCavanaugh 10y ago
TypeScript and Flow have the same behavior with regard to removing types, and TypeScript and Babel have the same behavior with regard to downleveling ES6+ code to ES5- If you target ES6 with TypeScript and only write ES6-compliant code (plus types), you won't get any downleveling of features, so your code will always be the same as you wrote it (other than the removal of types). If you use TS-specific features like 'enum' or 'namespace', there will necessarily be some rewriting of your code to turn it into usable JS, but those features are entirely optional.
TAForObvReasons 10y ago
With flow you can do one better: type comments! https://flowtype.org/blog/2015/02/20/Flow-Comments.html https://flowtype.org/blog/2015/02/20/Flow-Comments.html You actually wrap the type annotations in comments and flow will recognize them. You can use the source with the type comments in your browser! As an example, the flow checker will read the annotations from `function f(n/:number/, s/:string/) { ... }` but since they are commented in the source code your JS engine ignores them. This is amazing for typing existing code, since at every step you are merely inserting comments into your code. And your existing minification step will strip them out :)

yulaow 10y ago

Anyone knows any good resources to learn typescript? The tutorials on the official site are really... bad. Like I would not even call them tutorials.

stupidcar 10y ago
I really like the video courses on egghead.io: https://egghead.io/technologies/typescript https://egghead.io/technologies/typescript You do have to pay for some of them, but there's some free ones as well.

jtmarmon 10y ago

Can someone comment on the difference in reliability between using typescript and a natively statically typed language like haskell or scala? Is there any? Or is the type safety really as good when you use ts

jiaweihli 10y ago
I haven't worked too much with Haskell, but I've spent some time with Scala - they have pretty advanced type systems. Typescript can't match them 100%, but it's getting there. e.g. It doesn't have type variance, but it does have f-bounded polymorphism (which is unheard of in most mainstream languages). The language is powerful enough to build your own constructs. I maintain a Typescript library[1] that emulates Scala options/trys/futures. For day-to-day work, Typescript is a joy to work with. I describe it to others as the child of Scala and Ruby - pretty powerful type system but with a large community. [1] https://github.com/jiaweihli/monapt https://github.com/jiaweihli/monapt
virtualwhys 10y ago
They're different things, TS is a transpiler while Haskell (GHCJS) and Scala (Scala.js) compile respective host languages to javascript. In a perfect world you'd go with the latter, but there's overhead involved (relatively slow compilation and large generated binaries) that is mostly absent in TS. Also worth noting that TS' community is gigantic in comparison to that of Scala.js and GHCJS.
- jtmarmon 10y ago
  I was asking about the native languages themselves and their typesystems, not the compile-to-js versions of those languages. Regardless, I don't see much of a difference between TS -> JS and haskell->JS and scala -> JS. It's all from one language to another. the fact that TS is still considered a form of javascript is kind of irrelevant other than for semantics
  - virtualwhys 10y ago
    > I was asking about the native languages themselves and their typesystems, not the compile-to-js versions of those languages. Are they different? If language X can be expressed in its entirety as language Y then we can speak about X and Y interchangeably -- that's literally the point: full interop between client and server. Anyway, there's a world of difference between TS and GHCJS, Scala.js, Clojurescript, Js_of_ocaml, etc. One speaks javascript, the others speak both. As for reliability, in so far as TS is typed it will provide the compile time guarantees that its type system provides; not surprisingly the same goes for Scala.js, GHCJS, etc. So, the decision point probably hinges more on aforementioned overhead, size of community, and tooling than language/type system features/power. If it were otherwise we'd have seen a huge uptick by now wrt adoption rates for the compile-to-js languages. Maybe that will change in future but for now the big players drive the javascript bus...

edblarney 10y ago

After trying TS, I basically never want to write JS again. I know that 'OO' and 'typing' is not the solution to everything ... but aside from all the nice things you can do in TS ... the 'enforced architecture' of OO-ish paradigms, combined with typing, and essential obfuscation of the prototype paradigm ... has cut the time to development in half. I can hardly think of a reason to use JS now that TS exists. Of course - there are some reasons, in some specific situations, but by and large, TS is the future.

woah 10y ago
What OO does typescript have that js doesn't?
- edblarney 10y ago
  + Member access private/protected + Static members (theoretically exist in JS, but much cleaner and 'compiler aware' in TS) + Interfaces When I write JS, I end up with closures within closures within closures. When I write TS, I find myself sticking to much cleaner abstraction. I end up (having to) create classes, and usually it's for the better.
  - woah 10y ago
    A class is a pretty bad abstraction to try to fit the world into. It might work for some things, but it usually results in a lot of ceremony, and a lot of concepts in your program that exist only to service the abstraction. It's useful in JS for some special cases, but being forced into it is just going to make your code verbose and complicated for no reason. I'll stick to Flow for now.
    - DanRosenwasser 10y ago
      For the record, you're not forced into it at all. I'll mention that in the TypeScript compiler, we use very few classes at all - it's mostly written in a function-oriented style. TypeScript tries not to impose any sort of restrictions on coding style.

edblarney 10y ago

Dear TS authors: Thank you (!) for your amazing contributions. TS is the best new thing in tech. That said: Your linguistic genius is way ahead of the tooling. I feel as though some of these 'new and cool' 2.1 things are a little bit intellectual, maybe useful in some cases ... But getting TS to work in the real world, the various build configurations, tool-chains etc. - it's still clumsy. It was difficult to grasp the difference between AMD and other paradigms. I still have problems with circular dependencies, or rather, things happening before modules are loaded. Here's one pain point: Creating a static attribute on a class and initializing it right there, as in: class A { static b:B = new B(); } Means that 'new B()' will get executed right when that module is loaded, possibly before the module containing B is loaded. It's ugly, mechanical - but it's not a 'fine point'. I think these are the kinds of issues which are more likely to hold people back, as opposed to the lack of some rather fancy new paradigms such as 'Mapped Types'. Anyhow, keep up the good work. Lovin't it.

thejameskyle 10y ago
> Creating a static attribute on a class and initializing it right there, as in: class A { static b:B = new B(); } That is how the ECMAScript spec is designed. And TypeScript _should_ follow the spec.
- edblarney 10y ago
  Yes, it needs to be created 'right there' - but not in the context of other modules loads. I doubt that a strict interpretation requires that it does so before other modules are loaded. I suggest that 'right there' , i.e. the execution context can be delayed until mods are loaded. One could argue that all modules could be loaded before execution context. In Java, for example, you do not have this problem and yet, in Java we would say the attribute is initialized 'right there' as well. Obviously, when I say 'loaded' I don't mean 'executed'. In any event, it's a problem.
WorldMaker 10y ago
Your pain point sounds like a runtime problem with your module loader. You may want to investigate your module loader's issue tracker. (I recommend SystemJS [and jspm] over AMD these days, for what that is worth. It handles module loading quite well including all the complexity of circular dependencies that ES2015 specced and TS supports.) «I feel as though some of these 'new and cool' 2.1 things are a little bit intellectual, maybe useful in some cases ...» async/await and object spread should be useful in quite a lot of places. The other "intellectual" additions are immediately useful indirectly because they were built to support object spread (so that object spread types make sense), even if you don't wind up using the directly (because you aren't writing complicated type definition files for instance). Even then, you might find a bunch of uses for the types Partial<T> (partial objects) and Readonly<T> (shallowly frozen objects).

lacampbell 10y ago

How does the development cycle work? With plain JS I load up my html page in browser (chrome) and head to the console to check for errors in the JS. Then I do user testing. Can type-script be debugged by a browser on a source code level - ie not on a transpiled level? If not, I am not sure if it's worth it. And I say that as someone who is a huge fan of explicit optional typing.

jhchen 10y ago
In theory source maps is the answer but personally this has only worked some of the time. When it does work though it is magical and exactly answers your question of debugging in the browser at the source level.
autogol 10y ago
The development cycle is basicaly this: write Typescript code in a .ts file, transpile to a .js file, load .js into html. Transpiling can be handled by the IDE or by a build tool like gulp. For example, IntelliJ Webstorm has a built-in file watcher that tracks changes to .ts files and transpiles accordingly. Typescript can be debugged on a source code level, using source-maps. Webstorm and VS Code have built-in or plugin solutions. I heard some people complaining about issues, but i had a pretty smooth experience so far.
WorldMaker 10y ago
There is typically a quick transpile process in the IDE/toolchain of your choice. Most browser dev tools now support sourcemaps quite well which means that debugging shows the TS source and breakpoints are set directly there and typically show error stacktraces with your TS files. Another option is to load Typescript in your browser and let it transpile directly in the browser. Sourcemaps in this case are a bit more iffy in their browser support, but it can be an option for a quick debug cycle if you wanted to try something like that. Not particularly the fastest idea for a production app, though.

euroclydon 10y ago

The proposal for async/await is education, to say the least. The specs for modern and older browser/js-engines are in there. Turns out they implement two case statements, and handle every possible control structure. https://github.com/Microsoft/TypeScript/issues/1664 https://github.com/Microsoft/TypeScript/issues/1664

boubiyeah 10y ago

Congratulation to the TS team. We are happily using it at work, it's such a tremendous upgrade over javascript, while keeping the entire ecosystem at hand.

time4tea 10y ago

The noImplicitAny flag just doesn't make sense. You changed the new default behaviour to be the thing you don't recommend?

mohamedhegazy 10y ago
`--noImplicitAny` is the recommended flag. It is not set by default to ease the use on JS code bases. The new changes makes `--noImplicitAny` require less type annotations; where the compiler can figure out the type of a variable through following the control flow.

tkubacki 10y ago

Dart 1.21 is out today too - with generic methods support news.dartlang.org

daxfohl 10y ago

Seems like a great foundation to build something like F# type providers on top of.

voltagex_ 10y ago

What's the future of TypeScript in Visual Studio (not Code)? I've got a project that just silently fails to build in VS - no errors, no warnings, build successful - but no output. It seems like the Typescript tools inside VS2015 (even with the latest update) just aren't ready.

thewhitetulip 10y ago

I recently started learning JS, and now I am confused between TS and babel. Can anyone give me a reason why I should use either of the two and when I should use either of the two?

pitaj 10y ago
TS adds a complete static type-checking system, and also will compile down your bleeding-edge JS language features into supported syntax. Babel will do the second part.
- thewhitetulip 10y ago
  Thank you!

ken47 10y ago

I've been using Typescript for over a year, and the amount of improvement in that relatively short time span has been incredible. With 2.1, Typescript shows no signs of slowing down.