11 ms·

Announcing TypeScript 1.7

208 points by runesoerensen 11y ago

pluma 11y ago
TypeScript isn't competing with Flow, it's also competing with Babel. I still don't understand why MS keeps wasting energy on implementing ES.next features in their transpiler when there's already an established modular open source solution available. I understand why it started that way but even FB stopped using their own transpiler (JSX) once Babel gained traction.
- lukasm 11y ago
  because TypeScript is a super set of ES.
  - pluma 11y ago
    That would have been an argument when Babel was still 6to5. Babel supports all kinds of extensions to ES including ES proposals and extensions like JSX or type annotations.
- MasterScrat 11y ago
  > I still don't understand why MS keeps wasting energy on implementing ES.next features in their transpiler when there's already an established modular open source solution available. Isn't this like asking why there still are people "wasting energy" on promise libraries now that several well-established ones exist? Isn't it good for us developers to have more choice?
  - pluma 11y ago
    The problem is that using TypeScript locks you into TSC. TypeScript solves one fairly specific problem: adding type annotations and static type checking to JavaScript. In this regard it competes with Flow. But unlike Flow it ships its own transpiler. So if you want support for any new feature you have to wait for the TypeScript team to implement it or you have to abandon TypeScript altogether. Compare this to how Facebook dealt with JSX. JSX solved one fairly specific problem: adding syntactic sugar for nested `React.createElement` calls. Facebook used to provide their own JSX transpiler with support for various experimental features. This had the same problems as using TSC does now. So instead they just replaced their transpiler with Babel using the JSX plugin. In other words, no matter what new features other plugins add to Babel in the future, JSX only has to deal with transpiling JSX. It's not about diversity, it's about separation of concerns. TSC is for TypeScript primarily but it makes things messy by adding all kinds of unrelated crap it has to support to compete with Babel. That creates a lot of potential for subtle differences and bugs. I'm not talking about the features TypeScript adds, specifically. The ES proposals are likely going to end up in the ES standard eventually (unless they are dropped in which case you likely don't want to be using them anymore anyway), translating "future ES" to "current ES" (or "previous ES" as most Babel plugins produce code that works fine in ES3 environments) is an entirely separate problem from translating "proprietary extension X" (like JSX or TS) to some flavour of ES. But that's the crux of the problem, really: TS isn't intended to be an extension to ES. It's conceived as an entirely separate language that just shares a common subset. It diverged after ES5 and carried on separately. It belongs in the same category as CoffeeScript or LiveScript or ClojureScript, not the same category as JSX or Flow.
    - jbrantly 11y ago
      You don't actually have to use the transpiler features of TypeScript if you set `--target` appropriately. And Flow has the same problems regarding language features. Flow doesn't just magically understand all JS features now and forever. When new stuff comes out it has to be added to Flow, same with TypeScript. Edit: To be clear though, I agree with you about the TS transpiler. I think TypeScript's strength is in its static type checking, not in its transpiling.
- Keats 11y ago
  You can use TypeScript just for the types and hand the es6 files to Babel after. Also TypeScript existed before Babel and there are some features not supported by Babel (modules, public/private). See this issue for more details https://github.com/Microsoft/TypeScript/issues/1641 https://github.com/Microsoft/TypeScript/issues/1641
  - pluma 11y ago
    That issue is back from when Babel was still called 6to5. Babel didn't support JSX, decorators or type annotations. Now it does. Babel 6 is even more modular, lending itself even more to extension than Babel 5 did before. There's nothing stopping MS from adding TS extensions to Babel.
    - Keats 11y ago
      I'm guessing Microsoft is not keen on starting from scratch for no visible benefits for them. You could try opening another issue to see if they changed their minds though
Bahamut 11y ago
Awesome work by the TypeScript team - they have been moving very fast to improve TypeScript over the course of this year, and I am impressed by the amount of effort Microsoft has poured into this. Using TS now is pretty nice, and has already paid dividends at work in catching some subtle bugs
lukasm 11y ago
Polymorphic this Typing seems like a major change with many possible corner cases. I think Dart .. operator is a better solution newModel.setupBase().setupAdvanced(); becomes newModel..setupBase()..setupAdvanced();
- Arnavion 11y ago
  That assumes setupBase(), etc are either void-returning or return the this-instance (newModel). It won't work if each method returns a new instance, such as methods of immutable collections. Edit: Since this is hard to google for, this is called the "cascade operator". The given example is equivalent to: newModel.setupBase(); newModel.setupAdvanced(); That is, it ignores the result of the method and runs the remaining part of the statement with the LHS of the operator.
  - mythz 11y ago
    > That assumes setupBase(), etc are either void-returning or return the this-instance (newModel). This is Incorrect, it doesn't assume anything. Dart's method cascades just returns the receiver, it doesn't matter what the method returns, it's value is ignored and receiver is returned instead. http://news.dartlang.org/2012/02/method-cascades-in-dart-posted-by-gilad.html http://news.dartlang.org/2012/02/method-cascades-in-dart-pos... Since the return value is ignored, it's only useful for methods with side-effects.
    - spion 11y ago
      It assumes you have a stateful, side-effectful API when you could instead have an API that returns new immutable objects of the same type
      - spankalee 11y ago
        In that case instead of cascades you just use regular invocation.
    - Arnavion 11y ago
carterehsmith 11y ago
To me, this appears to be the way to go. Javascript + Typescript. Rather than deciding on weak (dynamic) typing vs strong typing, you pick both - incremental typing, as allowed by Typescript. Want to bang up a quick solution, as in MVP? Use bare-bones Javascript, it is all valid Typescript. So you get dynamic typing. And if you do not care about strong typing, you can just stop right there. But if you, some day, for whatever reason, decide that you feel like strong typing: good - you do not need to rewrite your app in a different language - just go back to your code and add some type info, here and there, at your leisure. As you do that, you get all the benefits of static typing, ie compiler showing you obvious type-related errors, correct keyword-completion, exact refactorings, etc etc. Looks like the best of both worlds.
- TazeTSchnitzel 11y ago
  Can TypeScript do runtime enforcement at the boundaries between typed and untyped code, though?
  - swax 11y ago
    No, and you wouldn't want the overhead. You can turn on warnings though if you want to make sure all your code is typed on compile. After compiling all type definitions are stripped and you're left with plain javascript.
    - msoad 11y ago
      How do you enable warnings?
      - DCoder 11y ago
        swax is probably referring to the compiler option "noImplicitAny", which can literally turn variables whose type is not explicitly specified and cannot be inferred from their declaration as errors, instead of assuming they have the transparent `any` type.
  - marcoperaza 11y ago
TazeTSchnitzel 11y ago
> This type can be used in classes and interfaces to represent some type that is a subtype of the containing type (rather than the containing type itself) Could that not be achieved by having covariant return types instead?
- Arnavion 11y ago
  Sure, but that would require every subtype to override every method of the base type with a narrower return type, and do nothing except delegate to the base type in the body. It would be tedious boilerplate. Since the base type's implementation already returns `this`, it makes sense to be able to annotate the method as returning `this` and get the benefit automatically.
  - deleted 11y ago
    [deleted]
  - TazeTSchnitzel 11y ago
    Ah, yes, that's a problem. In PHP, there's been some debate as to whether or not to support `static` (similar in function to TypeScript's `this`) as a return type, and that's one of the arguments in favour.
dfabulich 11y ago
I missed it when I first read the blog post, so I figure it's worth emphasizing: the new async/await support is only available on JavaScript engines that already support "function*" generator functions: Node 4, Firefox, and Chrome, but not Safari or IE/Edge. Supporting async/await in ES5/ES3 is on the roadmap for TypeScript v2.0. https://github.com/Microsoft/TypeScript/wiki/roadmap https://github.com/Microsoft/TypeScript/wiki/roadmap
- ahoge 11y ago
  Edge 13 does support generators. http://kangax.github.io/compat-table/es6/ http://kangax.github.io/compat-table/es6/
- scanr 11y ago
  You could also have a TypeScript to babel to ES5 workflow e.g.: http://gurustop.net/blog/2015/10/27/babel-typescript-compiler-gulp http://gurustop.net/blog/2015/10/27/babel-typescript-compile...
netcraft 11y ago
Can you compile TS from inside of JS or TS? something like `babel.transformFile`, that gives you back the compiled code?
- freditup 11y ago
  Yes, you can: https://github.com/Microsoft/TypeScript/wiki/Using-the-Language-Service-API https://github.com/Microsoft/TypeScript/wiki/Using-the-Langu...
  - DCoder 11y ago
    There are some subtle behavioural differences between the Language Service and the regular compiler, for example: https://github.com/Microsoft/TypeScript/issues/5243 https://github.com/Microsoft/TypeScript/issues/5243
    - freditup 11y ago
      Good clarification. Perhaps the compiler API is the better choice here? I'm not fully aware of the differences / divisions between the two. https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API https://github.com/Microsoft/TypeScript/wiki/Using-the-Compi...
      - DCoder 11y ago
        Interesting, I honestly don't know if that makes a difference.
trevordev 11y ago
Typescript has became my favorite language. The option of having types when you need them is great and the addition of async/await make working with promises a lot nicer. Ever since I've been able to use experimental features and get es6 support with typescript I've never looked back. The only thing lacking now is the tooling. The atom-typescript plugin is the best I've found but I would love to see better integration with other editors. Can't wait to see what comes to typescript next!
- wluu 11y ago
  One of the atom-typescript guys (basarat) has built his own typescript focused editor: http://www.typescriptbuilder.com http://www.typescriptbuilder.com It's built entirely in Typescript and is not based on the Electron shell. Why they built it is mentioned here https://github.com/TypeScriptBuilder/tsb/blob/master/docs/contributing/why.md https://github.com/TypeScriptBuilder/tsb/blob/master/docs/co...
- aozgaa 11y ago
  I can't speak to atom, but have you considered Visual Studio Code? That and VS2015 are tightly integrated with the TypeScript compiler and language service (provides autocomplete, type hinting, go-to definition, etc.). For sublime, there is a plugin actively developed by Microsoft [1]. For vim, the plugin YouCompleteMe provide autocomplete [2]. Also, I haven't tried it, but there's an Emacs-mode, apparently [3]. There are also numerous other alternatives I'm unfamiliar with. Hope this helps! [1] https://github.com/Microsoft/TypeScript-Sublime-Plugin https://github.com/Microsoft/TypeScript-Sublime-Plugin [2] http://valloric.github.io/YouCompleteMe/#intro http://valloric.github.io/YouCompleteMe/#intro [3] https://github.com/aki2o/emacs-tss https://github.com/aki2o/emacs-tss
  - MasterScrat 11y ago
    WebStorm (IntelliJ) support is really good as well.
    - drinchev 11y ago
ebbv 11y ago
I remember when MicroSoft tried to make it's own superscript of JS and people said "Hey this is a bad idea. Standards are a thing for a reason and we should all stick to them." That argument was correct then and it's correct now, IMHO. Where is the objection in 2015? Is it just people are so desensitized by other companies attempts to make JS replacements (that for now compile to JS) that another one just doesn't bug anyone? I realize the temptation for big companies like Microsoft with thousands of devs to roll their own, but when every big company abandons standards to focus on their own little alcove we all suffer. And yeah, I realize you can frame it as they haven't abandoned the standard because TypeScript compiles to JS and yada, yada. But I disagree. If instead of focusing on TypeScript which you can only take advantage of by working in TypeScript, they focused on libraries for JS that we could all use, I think we'd all be better off. And that goes for all large corporations that decide to roll their own solutions instead of sticking to standards. Which is not to say JS can never be replaced, I'd say it's long overdue for replacement. But that's never going to happen by every big company rolling their own thing. Everybody has to come together.
- trimbo 11y ago
  > But that's never going to happen by every big company rolling their own thing. Everybody has to come together. Google has ditched their own and rolled their efforts into Typescript. http://techcrunch.com/2015/03/05/microsoft-and-google-collaborate-on-typescript-hell-has-not-frozen-over-yet/ http://techcrunch.com/2015/03/05/microsoft-and-google-collab...
- dangoor 11y ago
  There are quite a few differences from the old "JScript" days. First of all: TypeScript is liberally licensed open source. JScript was totally proprietary. Another aspect is that TypeScript is seeking to be a strict superset of JavaScript that evolves as JavaScript does (something that wasn't really happening in the JScript days) and is focused on specifically providing static types and tooling for types in JS. It's not a general "embrace, extend, extinguish" kind of thing at all, but rather a very targeted tool. TypeScript is really one of the most JavaScript-y languages that compile to JS. Most of the compile-to-JS languages are more radical divergences from JS. JS is not going to be replaced (though WebAssembly[1] will likely become an additional compile target), but compile-to-JS is going to continue to grow in popularity. Already, many people are compiling future-JS to present-day-JS. The browser vendors have found that the standards evolve best when people can actually write code against the standards before the standards are hardened. Compile-to-JS tools help with that. If optional static types and type inference become very popular via TypeScript and Flow, JS itself may evolve to support those features and then we'll have that standard. Microsoft is a better player on the web today than they have ever been before. [1]: https://github.com/WebAssembly/design https://github.com/WebAssembly/design
tlarkworthy 11y ago
Polymorphic this is really useful for the 'cannot reference a type twice in the type list' issue you get when doing generics. Since learning it I have used it many times. It's solves many issues like typing a clone method. Awesome addition!
MasterScrat 11y ago
Tangential question: which IDE are you using for TypeScript? I'm quite happy with WebStorm on OSX but I am wondering if a switch to Visual Studio may be worth it.
Nitramp 11y ago
We're super happy with TypeScript in Angular, it's working great for us, and having the option (!) to easily use it will be great for Angular users. A note on all the praise for type inference: local type inference is super cool as it saves on a lot of boiler plate (`Foo foo = new Foo(); // foo` anyone?). But global type inference, i.e. across function and module boundaries, has its drawbacks. Apart from performance cost, the most important is IMHO understandability. If you don't have explicit types across module boundaries, it can easily become hard to decide just what a type is supposed to be, e.g. if your code doesn't compile, but the compiler cannot tell you which part of it is wrong, because all the types are inferred. That can easily lead to "wall of text" C++ compiler style error messages. Same if some new library version changes type inference patterns, your code might suddenly break in surprising and hard to understand ways. I think TypeScript's (& Go's) choice of local type inference is a good mix of less boilerplate and good understandability, together with gradual typing via `any`.
hokkos 11y ago
That's great but is there any ES6 minification tool that handle ES6 ? Because last time I checked uglify didn't handle generators (and I assume by async to ES6 target they transform it to generators).
- flyingmutant 11y ago
  There is http://rollupjs.org/ http://rollupjs.org/, which is quite young though.
  - hokkos 11y ago
    It uses babel, so it uses regenerator ( https://github.com/facebook/regenerator https://github.com/facebook/regenerator ) and then uglify probably. It will be great when typescript can do it natively because it knows at lot more before the being translated to javascript : https://github.com/Microsoft/TypeScript/issues/8 https://github.com/Microsoft/TypeScript/issues/8
stewbrew 11y ago
I'd like to see a thorough comparison of typescript, haxe, scala.js, and also gopherjs. Which (statically typed) language/compiler provides the best experience for developers who want to develop "native" programs (I include here jvm and node) and javascript for the web with one language using the same libraries?
- astrafoo 11y ago
  http://www.scala-js.org/ http://www.scala-js.org/ has a nice comparison between JavaScript, ECMAScript 6, TypeScript and Scala. I'm not sure there is much substance to develop "native" programs in TypeScript/Haxe/... they don't have an ecosystem outside the web, while Scala has tons of mature libraries, access to all the Java stuff ever written, and runs on the best, mature, well-supported, high-performance runtime you can get.
  - stewbrew 11y ago
    ts has the node ecosystem, and haxe provides easy access to node/pyton/c++/java libs. gopherjs is able to compile a significant amount of the go standard lib -- I don't know if this is true for arbitrary go libs too. Thanks for the reference.

208 points by runesoerensen 11y ago

pluma 11y ago

TypeScript isn't competing with Flow, it's also competing with Babel. I still don't understand why MS keeps wasting energy on implementing ES.next features in their transpiler when there's already an established modular open source solution available. I understand why it started that way but even FB stopped using their own transpiler (JSX) once Babel gained traction.

lukasm 11y ago
because TypeScript is a super set of ES.
- pluma 11y ago
  That would have been an argument when Babel was still 6to5. Babel supports all kinds of extensions to ES including ES proposals and extensions like JSX or type annotations.
MasterScrat 11y ago
> I still don't understand why MS keeps wasting energy on implementing ES.next features in their transpiler when there's already an established modular open source solution available. Isn't this like asking why there still are people "wasting energy" on promise libraries now that several well-established ones exist? Isn't it good for us developers to have more choice?
- pluma 11y ago
  The problem is that using TypeScript locks you into TSC. TypeScript solves one fairly specific problem: adding type annotations and static type checking to JavaScript. In this regard it competes with Flow. But unlike Flow it ships its own transpiler. So if you want support for any new feature you have to wait for the TypeScript team to implement it or you have to abandon TypeScript altogether. Compare this to how Facebook dealt with JSX. JSX solved one fairly specific problem: adding syntactic sugar for nested `React.createElement` calls. Facebook used to provide their own JSX transpiler with support for various experimental features. This had the same problems as using TSC does now. So instead they just replaced their transpiler with Babel using the JSX plugin. In other words, no matter what new features other plugins add to Babel in the future, JSX only has to deal with transpiling JSX. It's not about diversity, it's about separation of concerns. TSC is for TypeScript primarily but it makes things messy by adding all kinds of unrelated crap it has to support to compete with Babel. That creates a lot of potential for subtle differences and bugs. I'm not talking about the features TypeScript adds, specifically. The ES proposals are likely going to end up in the ES standard eventually (unless they are dropped in which case you likely don't want to be using them anymore anyway), translating "future ES" to "current ES" (or "previous ES" as most Babel plugins produce code that works fine in ES3 environments) is an entirely separate problem from translating "proprietary extension X" (like JSX or TS) to some flavour of ES. But that's the crux of the problem, really: TS isn't intended to be an extension to ES. It's conceived as an entirely separate language that just shares a common subset. It diverged after ES5 and carried on separately. It belongs in the same category as CoffeeScript or LiveScript or ClojureScript, not the same category as JSX or Flow.
  - jbrantly 11y ago
    You don't actually have to use the transpiler features of TypeScript if you set `--target` appropriately. And Flow has the same problems regarding language features. Flow doesn't just magically understand all JS features now and forever. When new stuff comes out it has to be added to Flow, same with TypeScript. Edit: To be clear though, I agree with you about the TS transpiler. I think TypeScript's strength is in its static type checking, not in its transpiling.
Keats 11y ago
You can use TypeScript just for the types and hand the es6 files to Babel after. Also TypeScript existed before Babel and there are some features not supported by Babel (modules, public/private). See this issue for more details https://github.com/Microsoft/TypeScript/issues/1641 https://github.com/Microsoft/TypeScript/issues/1641
- pluma 11y ago
  That issue is back from when Babel was still called 6to5. Babel didn't support JSX, decorators or type annotations. Now it does. Babel 6 is even more modular, lending itself even more to extension than Babel 5 did before. There's nothing stopping MS from adding TS extensions to Babel.
  - Keats 11y ago
    I'm guessing Microsoft is not keen on starting from scratch for no visible benefits for them. You could try opening another issue to see if they changed their minds though

Bahamut 11y ago

Awesome work by the TypeScript team - they have been moving very fast to improve TypeScript over the course of this year, and I am impressed by the amount of effort Microsoft has poured into this. Using TS now is pretty nice, and has already paid dividends at work in catching some subtle bugs

lukasm 11y ago

Polymorphic this Typing seems like a major change with many possible corner cases. I think Dart .. operator is a better solution newModel.setupBase().setupAdvanced(); becomes newModel..setupBase()..setupAdvanced();

Arnavion 11y ago
That assumes setupBase(), etc are either void-returning or return the this-instance (newModel). It won't work if each method returns a new instance, such as methods of immutable collections. Edit: Since this is hard to google for, this is called the "cascade operator". The given example is equivalent to: newModel.setupBase(); newModel.setupAdvanced(); That is, it ignores the result of the method and runs the remaining part of the statement with the LHS of the operator.
- mythz 11y ago
  > That assumes setupBase(), etc are either void-returning or return the this-instance (newModel). This is Incorrect, it doesn't assume anything. Dart's method cascades just returns the receiver, it doesn't matter what the method returns, it's value is ignored and receiver is returned instead. http://news.dartlang.org/2012/02/method-cascades-in-dart-posted-by-gilad.html http://news.dartlang.org/2012/02/method-cascades-in-dart-pos... Since the return value is ignored, it's only useful for methods with side-effects.
  - spion 11y ago
    It assumes you have a stateful, side-effectful API when you could instead have an API that returns new immutable objects of the same type
    - spankalee 11y ago
      In that case instead of cascades you just use regular invocation.
  - Arnavion 11y ago

carterehsmith 11y ago

To me, this appears to be the way to go. Javascript + Typescript. Rather than deciding on weak (dynamic) typing vs strong typing, you pick both - incremental typing, as allowed by Typescript. Want to bang up a quick solution, as in MVP? Use bare-bones Javascript, it is all valid Typescript. So you get dynamic typing. And if you do not care about strong typing, you can just stop right there. But if you, some day, for whatever reason, decide that you feel like strong typing: good - you do not need to rewrite your app in a different language - just go back to your code and add some type info, here and there, at your leisure. As you do that, you get all the benefits of static typing, ie compiler showing you obvious type-related errors, correct keyword-completion, exact refactorings, etc etc. Looks like the best of both worlds.

TazeTSchnitzel 11y ago
Can TypeScript do runtime enforcement at the boundaries between typed and untyped code, though?
- swax 11y ago
  No, and you wouldn't want the overhead. You can turn on warnings though if you want to make sure all your code is typed on compile. After compiling all type definitions are stripped and you're left with plain javascript.
  - msoad 11y ago
    How do you enable warnings?
    - DCoder 11y ago
      swax is probably referring to the compiler option "noImplicitAny", which can literally turn variables whose type is not explicitly specified and cannot be inferred from their declaration as errors, instead of assuming they have the transparent `any` type.
- marcoperaza 11y ago

TazeTSchnitzel 11y ago

> This type can be used in classes and interfaces to represent some type that is a subtype of the containing type (rather than the containing type itself) Could that not be achieved by having covariant return types instead?

Arnavion 11y ago
Sure, but that would require every subtype to override every method of the base type with a narrower return type, and do nothing except delegate to the base type in the body. It would be tedious boilerplate. Since the base type's implementation already returns `this`, it makes sense to be able to annotate the method as returning `this` and get the benefit automatically.
- deleted 11y ago
  [deleted]
- TazeTSchnitzel 11y ago
  Ah, yes, that's a problem. In PHP, there's been some debate as to whether or not to support `static` (similar in function to TypeScript's `this`) as a return type, and that's one of the arguments in favour.

dfabulich 11y ago

I missed it when I first read the blog post, so I figure it's worth emphasizing: the new async/await support is only available on JavaScript engines that already support "function*" generator functions: Node 4, Firefox, and Chrome, but not Safari or IE/Edge. Supporting async/await in ES5/ES3 is on the roadmap for TypeScript v2.0. https://github.com/Microsoft/TypeScript/wiki/roadmap https://github.com/Microsoft/TypeScript/wiki/roadmap

ahoge 11y ago
Edge 13 does support generators. http://kangax.github.io/compat-table/es6/ http://kangax.github.io/compat-table/es6/
scanr 11y ago
You could also have a TypeScript to babel to ES5 workflow e.g.: http://gurustop.net/blog/2015/10/27/babel-typescript-compiler-gulp http://gurustop.net/blog/2015/10/27/babel-typescript-compile...

netcraft 11y ago

Can you compile TS from inside of JS or TS? something like `babel.transformFile`, that gives you back the compiled code?

freditup 11y ago
Yes, you can: https://github.com/Microsoft/TypeScript/wiki/Using-the-Language-Service-API https://github.com/Microsoft/TypeScript/wiki/Using-the-Langu...
- DCoder 11y ago
  There are some subtle behavioural differences between the Language Service and the regular compiler, for example: https://github.com/Microsoft/TypeScript/issues/5243 https://github.com/Microsoft/TypeScript/issues/5243
  - freditup 11y ago
    Good clarification. Perhaps the compiler API is the better choice here? I'm not fully aware of the differences / divisions between the two. https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API https://github.com/Microsoft/TypeScript/wiki/Using-the-Compi...
    - DCoder 11y ago
      Interesting, I honestly don't know if that makes a difference.

trevordev 11y ago

Typescript has became my favorite language. The option of having types when you need them is great and the addition of async/await make working with promises a lot nicer. Ever since I've been able to use experimental features and get es6 support with typescript I've never looked back. The only thing lacking now is the tooling. The atom-typescript plugin is the best I've found but I would love to see better integration with other editors. Can't wait to see what comes to typescript next!

wluu 11y ago
One of the atom-typescript guys (basarat) has built his own typescript focused editor: http://www.typescriptbuilder.com http://www.typescriptbuilder.com It's built entirely in Typescript and is not based on the Electron shell. Why they built it is mentioned here https://github.com/TypeScriptBuilder/tsb/blob/master/docs/contributing/why.md https://github.com/TypeScriptBuilder/tsb/blob/master/docs/co...
aozgaa 11y ago
I can't speak to atom, but have you considered Visual Studio Code? That and VS2015 are tightly integrated with the TypeScript compiler and language service (provides autocomplete, type hinting, go-to definition, etc.). For sublime, there is a plugin actively developed by Microsoft [1]. For vim, the plugin YouCompleteMe provide autocomplete [2]. Also, I haven't tried it, but there's an Emacs-mode, apparently [3]. There are also numerous other alternatives I'm unfamiliar with. Hope this helps! [1] https://github.com/Microsoft/TypeScript-Sublime-Plugin https://github.com/Microsoft/TypeScript-Sublime-Plugin [2] http://valloric.github.io/YouCompleteMe/#intro http://valloric.github.io/YouCompleteMe/#intro [3] https://github.com/aki2o/emacs-tss https://github.com/aki2o/emacs-tss
- MasterScrat 11y ago
  WebStorm (IntelliJ) support is really good as well.
  - drinchev 11y ago

ebbv 11y ago

I remember when MicroSoft tried to make it's own superscript of JS and people said "Hey this is a bad idea. Standards are a thing for a reason and we should all stick to them." That argument was correct then and it's correct now, IMHO. Where is the objection in 2015? Is it just people are so desensitized by other companies attempts to make JS replacements (that for now compile to JS) that another one just doesn't bug anyone? I realize the temptation for big companies like Microsoft with thousands of devs to roll their own, but when every big company abandons standards to focus on their own little alcove we all suffer. And yeah, I realize you can frame it as they haven't abandoned the standard because TypeScript compiles to JS and yada, yada. But I disagree. If instead of focusing on TypeScript which you can only take advantage of by working in TypeScript, they focused on libraries for JS that we could all use, I think we'd all be better off. And that goes for all large corporations that decide to roll their own solutions instead of sticking to standards. Which is not to say JS can never be replaced, I'd say it's long overdue for replacement. But that's never going to happen by every big company rolling their own thing. Everybody has to come together.

trimbo 11y ago
> But that's never going to happen by every big company rolling their own thing. Everybody has to come together. Google has ditched their own and rolled their efforts into Typescript. http://techcrunch.com/2015/03/05/microsoft-and-google-collaborate-on-typescript-hell-has-not-frozen-over-yet/ http://techcrunch.com/2015/03/05/microsoft-and-google-collab...
dangoor 11y ago
There are quite a few differences from the old "JScript" days. First of all: TypeScript is liberally licensed open source. JScript was totally proprietary. Another aspect is that TypeScript is seeking to be a strict superset of JavaScript that evolves as JavaScript does (something that wasn't really happening in the JScript days) and is focused on specifically providing static types and tooling for types in JS. It's not a general "embrace, extend, extinguish" kind of thing at all, but rather a very targeted tool. TypeScript is really one of the most JavaScript-y languages that compile to JS. Most of the compile-to-JS languages are more radical divergences from JS. JS is not going to be replaced (though WebAssembly[1] will likely become an additional compile target), but compile-to-JS is going to continue to grow in popularity. Already, many people are compiling future-JS to present-day-JS. The browser vendors have found that the standards evolve best when people can actually write code against the standards before the standards are hardened. Compile-to-JS tools help with that. If optional static types and type inference become very popular via TypeScript and Flow, JS itself may evolve to support those features and then we'll have that standard. Microsoft is a better player on the web today than they have ever been before. [1]: https://github.com/WebAssembly/design https://github.com/WebAssembly/design

tlarkworthy 11y ago

Polymorphic this is really useful for the 'cannot reference a type twice in the type list' issue you get when doing generics. Since learning it I have used it many times. It's solves many issues like typing a clone method. Awesome addition!

MasterScrat 11y ago

Tangential question: which IDE are you using for TypeScript? I'm quite happy with WebStorm on OSX but I am wondering if a switch to Visual Studio may be worth it.

Nitramp 11y ago

We're super happy with TypeScript in Angular, it's working great for us, and having the option (!) to easily use it will be great for Angular users. A note on all the praise for type inference: local type inference is super cool as it saves on a lot of boiler plate (`Foo foo = new Foo(); // foo` anyone?). But global type inference, i.e. across function and module boundaries, has its drawbacks. Apart from performance cost, the most important is IMHO understandability. If you don't have explicit types across module boundaries, it can easily become hard to decide just what a type is supposed to be, e.g. if your code doesn't compile, but the compiler cannot tell you which part of it is wrong, because all the types are inferred. That can easily lead to "wall of text" C++ compiler style error messages. Same if some new library version changes type inference patterns, your code might suddenly break in surprising and hard to understand ways. I think TypeScript's (& Go's) choice of local type inference is a good mix of less boilerplate and good understandability, together with gradual typing via `any`.

hokkos 11y ago

That's great but is there any ES6 minification tool that handle ES6 ? Because last time I checked uglify didn't handle generators (and I assume by async to ES6 target they transform it to generators).

flyingmutant 11y ago
There is http://rollupjs.org/ http://rollupjs.org/, which is quite young though.
- hokkos 11y ago
  It uses babel, so it uses regenerator ( https://github.com/facebook/regenerator https://github.com/facebook/regenerator ) and then uglify probably. It will be great when typescript can do it natively because it knows at lot more before the being translated to javascript : https://github.com/Microsoft/TypeScript/issues/8 https://github.com/Microsoft/TypeScript/issues/8

stewbrew 11y ago

I'd like to see a thorough comparison of typescript, haxe, scala.js, and also gopherjs. Which (statically typed) language/compiler provides the best experience for developers who want to develop "native" programs (I include here jvm and node) and javascript for the web with one language using the same libraries?

astrafoo 11y ago
http://www.scala-js.org/ http://www.scala-js.org/ has a nice comparison between JavaScript, ECMAScript 6, TypeScript and Scala. I'm not sure there is much substance to develop "native" programs in TypeScript/Haxe/... they don't have an ecosystem outside the web, while Scala has tons of mature libraries, access to all the Java stuff ever written, and runs on the best, mature, well-supported, high-performance runtime you can get.
- stewbrew 11y ago
  ts has the node ecosystem, and haxe provides easy access to node/pyton/c++/java libs. gopherjs is able to compile a significant amount of the go standard lib -- I don't know if this is true for arbitrary go libs too. Thanks for the reference.