9 ms·

Announcing TypeScript 2.0 Beta

359 points by DanRosenwasser 10y ago

out_of_protocol 10y ago
Explain please, why anybody would want both null AND undefined?
- recursive 10y ago
  They'd want it indirectly, because they want to use or target javascript, which has always had both. There's very little reason why someone would have a primary goal of using both.
- Crespyl 10y ago
  Similar to why you would want to have both false and 0; it is possible to have a situation in which you wish to define something as explicitly being null. I do think it's a little weird, but it's useful to be able to say that "this key exists and its value is null" as opposed to "there is no such key".
  - SigmundA 10y ago
    I usually find it useful in API's, When you send object across undefined means no value was sent, null is a null value sent. That is the difference between not changing a value and changing it to null.
  - Matthias247 10y ago
    I thought about that too, but this breaks down once you realize that setting obj.key = undefined; will mutate an object into something which is neither "the key exists and its value is null" nor "there is no such key". The difference can e.g. bite you in things that iterate over the keys of an object or function that do that internally (like deepEquals implementations). I guess in TS2 there would now also be a difference between a field defined as key: string | null | undefined and a field defined as key?: string | null | undefined, because the first one requires setting the key to one of the values on initialization and the other one not.
- extrapickles 10y ago
  It can be useful when calling a function and you want to say "I don't care about parameter X" when null can be an otherwise valid value for that parameter. I've also found it useful when a function needs to indicate it failed but is in a situation where exceptions are not useful. This is code where the consumer of the function can throw its own much more useful exception or can try to recover from the function failing (eg: it can try and fix the fault). This helps people avoid using exceptions for flow control of the application and lets exceptions be truly exceptional. Examples: //3rd party code could dictate 'bar' be in the spot that it is function needsUndef(foo, bar, other){ if(bar === undefined) bar = expensive_query(); //rest of code } needsUndef(42, cachedResultExpensiveQuery, something); needsUndef(42, undefined, something); and: foo = getFromDisk(foo_path); if(foo === undefined) foo = getFromNetwork(last_resort); is much nicer than: try{ foo = getFromDisk(foo_path); }catch(ex){ //Yes, I know you can filter exceptions, but what if someone forgets or sets too wide //of a net? foo = getFromNetwork(last_resort); } or: if(path_isValid(foo_path) && canReadFromPath(foo_path)) foo = getFromDisk(foo_path); else foo = getFromNetwork(last_resort);
  - kilotaras 10y ago
    For second case most people use options in language that have them.
- hiou 10y ago
  undefined typically means it has yet to be defined whereas null means it does not have a proper value set. For example I use null where there is an exception an cannot set a variable to a sane value. When I see null it means a value could not be set or that it was intentionally unset. undefined means it was never set in the first place.
- acjohnson55 10y ago
  It's supposed to represent intention. Since all functions in JS are variadic, there has to be a way to differentiate between a parameter not being passed and an "empty" value that is explicitly passed. Technically, you should never explicitly assign `undefined` to anything yourself, but you can propagate it.
neals 10y ago
So how are you guys building TS for web apps? I've been using VS Code, putting classes into namespaces and it builds with commonJS, which I concatenate into a single file that I load into a website. That last part is in need of change because you're not supposed to concatenate commonJS. So how have you been delivering your code to the browser?
- salehenrahman 10y ago
  I'm currently using a "TypeScript loader" for either Webpack or Browserify. If that seems too much, the other option is to output the compiled code as AMD modules [1]. But I have not tried it myself. Regardless, the option is still there, and, IMO, it seems like a painless transition away from concatenation. http://stackoverflow.com/a/36320145/538570 http://stackoverflow.com/a/36320145/538570
- stupidcar 10y ago
  We're experimenting with using TypeScript 2.0 for compilation, and webpack 2 for bundling. You can configure TypeScript 2.0 to compile most TS/ES6 syntax to ES5, but to leave the module statements (e.g. import and exports) as ES6. Webpack can then analyse your ES6 module tree and perform "tree shaking", a form of dead code elimination where unused modules are excluded from the compiled bundle. This will become increasingly useful as more libraries are authored in ES6 / TypeScript, as it will allow you to import the whole of a framework like Angular or React, but only ship the parts of it that you actually use in your application.
  - stupidcar 10y ago
    And I wanted to add that, while webpack can appear a little intimidating at first, it's actually very easy to setup, and in many ways much simpler than the kind of jerry-rigged concatenation and minification workflows we used to build with Gulp and Grunt.
- tomduncalf 10y ago
  I've been using Typescript with Webpack (and Babel) for the last 9 months or so and in general been very happy with it, I'd highly recommend it as you get all the Webpack and Babel goodness (hot module reloading for React, async/await, the option to use Babel plugins etc.) on top of Typescript. I've written a step by step guide to setting up Typescript, Webpack and React at http://blog.tomduncalf.com/posts/setting-up-typescript-and-react/ http://blog.tomduncalf.com/posts/setting-up-typescript-and-r... if you're interested to try the set up out.
ken47 10y ago
Another interesting addition is discriminated union types: https://github.com/Microsoft/TypeScript/pull/9163 https://github.com/Microsoft/TypeScript/pull/9163 This will greatly facilitate a more functional style of programming.
- MichaelGG 10y ago
  Union types without destructuring/pattern matching seems really strange, doesn't it? Special casing a certain property name and converting types based on a string comparison?
  - iamdanfox 10y ago
    It's definitely not as elegant as Scala or Haskell, but I think their justification is very reasonable. The current implementation is maximally compatible with existing usages of tagged unions (e.g. Redux actions), because it allows you to choose whatever discriminant you like ('type', 'kind', whatever). Keeping very close to JS seems to be a core tenet of TypeScript and is quite valuable in my opinion. It means they can adopt new ECMAScript syntax without clashes and also ensures that newbies have a smaller learning curve. Also, they can always add in some syntactic sugar later if they want to!
    - lomnakkus 10y ago
      Yeah, the key here is JS-compatibility. Unfortunately, that does mean that TypeScript is sort of a dead end in terms of how far you can go wrt. the fabulousness of your code. (Of course, once everything is statically typed you'll have a much easier time just converting everything to $OTHER_STATICALLY_TYPED_FRONTEND_LANGUAGE, perhaps Scala.js, perhaps PureScript, perhaps js_of_ocaml, perhaps even GHCJS if you're adventurous. (Aside: I'm moderately disappointed the 'fabulousness' was not in my Chromium's spell checker dictionary. It is now.)
      - invaliduser 10y ago
        If by «fabulousness» you mean in terms of static typing, the language may not meet your expectations, but it seems to me it's a bit harsh to say it's a dead-end, considering it's on par with many other languages, and still improving. Also, sorry if you meant something else, «fabulousness» is a very subjective term, not unlike «elegant» (as in «elegant code»), and because it does not have a specific and commonly shared meaning (what is fabulous to you may not by fabulous to others), it's not something I'm very comfortable discussing, although I think I have understood what you meant by it, but with a low level of certainty.
statictype 10y ago
The control-flow analysis of types is very clever. I've been slowly switching away from Coffeescript to Typescript and have been mostly happy with it. Only thing I still struggle with is grappling the namespace/modules mess in Javascript that's been inherited by Typescript.
- nathancahill 10y ago
  Is it inherited from JS though? I was under the impression that Typescript was doing their own thing (like /// <reference)
  - DougBTX 10y ago
    TypeScript picked up a few features that were ultimately removed from JS at the draft spec stage, AFAIK the xml style references were never in a JS spec, but the convention has been around a while. TS also supports import etc.
    - nathancahill 10y ago
      The thing that bugs me the most is the inconsistent implementation of default imports with ES6. Makes it hard to work with a lot of libraries.
knocte 10y ago
> In TypeScript 2.0, the new --strictNullChecks flag changes that. string just means string and number means number. This is great. However, it would be nice to know if this feature will become opt-out in the future instead of opt-in. In theory, if you're a TS user (as opposed to JS) it's because you want these nice features _by default_.
- hockeybias 10y ago
  Agreed!
- oblio 10y ago
  Wouldn't that break third party libraries? You'd also need a compiler flag to enable it only for your own code.
  - kagia 10y ago
    I feel that typescript being only 2.0, should be in a position to break things once in a while. If you pay too much attention to keeping legacy code 'alive' you end up complicating matters with either compiler-flags all over the place or redundant API's i.e win32 api (old+new+newer versions of the same function).
    - cakoose 10y ago
      The fact that the flag is global could actually slow down adoption of the new type system. Let's say I want to use the new type system, but some library I depend on hasn't been updated. If I enable the new type system, I'll get both false positives and negatives when type checking. If a library writer updated to the new type system, they'd break compatibility with callers that haven't updated. The safest option would be to maintain two almost-identical copies of the library -- one for the old type system and one for the new one. A better option would be to allow specifying the type system mode at the top of each file (like "use strict"). This allows me to use the new type system even if not all my libraries have updated yet. This also allows libraries writers to use the new type system features without breaking existing users.
jensvdh 10y ago
This is fantastic. Kind of gutted they delayed Async/Await until Typescript 2.1 releases. That's the one killer feature I'm missing. Typescript has been nothing short but amazing though!
- jsheard 10y ago
  In the meantime you can use async with TypeScripts ES6 emitter, which transforms async into generators, then run the output through Babel to transform the generators into plain old ES3/ES5. It's messy but it works.
  - moosingin3space 10y ago
    How hard is it to automate this and what impact on build times does it have?
    - Derander 10y ago
      It's not hard to automate with raw gulp or webpack, but it does add a significant amount of time to compilation. It roughly doubled our incremental compile times. My team decided it wasn't worth it, but it's possible that a cleverer person could decrease the overhead.
      - moosingin3space 10y ago
        I ask because I'm debating between trialing TypeScript or Elm for a personal project (I primarily work in Rust and Go on the backend/infrastructure), and iteration times are important when trying to get a frontend UI "just right".
        jsheard 10y ago
        You could just use TypeScripts ES6 output directly during development, using a browser that supports ES6 natively, then add Babel to the build chain for public builds that need to work on older browsers.
deleted 10y ago
[deleted]
spriggan3 10y ago
let lowerCased = strs!.map(s => s.toLowerCase()); I'm not a big fan of this, it's really starting to change JS semantics. It's not just type annotations anymore + ES6 . It's starting to look like its own language. Some might like that, I do not. They should be a bit more cautious before introducing these features. What if Ecmascript in the future uses ! as an operator for a totally unrelated purpose ? It's like decorators, they are not in the spec, there is no plan yet to officially had them to the spec, yet, Angular2 which is written in Typescript abuse them. What if in 2 years they are introduced in ES2019 with different semantics ? How Typescript is going to handle that too ?
- johnfn 10y ago
  This post is full of misplaced FUD. > It's not just type annotations anymore + ES6 How not? ! is just an inline type coercion. > What if Ecmascript in the future uses ! as an operator for a totally unrelated purpose ? This seems unlikely because ! is already an operator in JS. But really, this argument could be made against any operator TS uses. What if ES introduces : as an operator? Or if they introduce some sort of ambiguity with the other myriad type definitions? This is not a new issue, and you shouldn't let null checks drive you away from the language. In any case, both null checks and decorators are behind flags. The decorators flag is literally called "experimental decorators". So it's not like the TS team is pretending that it's going to be stable forever.
  - h_r 10y ago
    >! is just an inline type coercion. Are you sure about that? It sounds more like a signal to the compiler to "trust me, I know what I'm doing" and would blow up if you passed undefined anyway. Maybe the author didn't explain it very well. That is, not a type coercion so much as a hint to not bother checking this access.
    - johnfn 10y ago
      When would code with ! ever compile differently than code without ! ?
jameslk 10y ago
> This release includes plenty of new features, such as our new workflow for getting .d.ts files[0] Does this mean that using Typings is no longer necessary, or is there some additional benefits that Typings still offers? 0. https://blogs.msdn.microsoft.com/typescript/2016/06/15/the-future-of-declaration-files/ https://blogs.msdn.microsoft.com/typescript/2016/06/15/the-f...
- ken47 10y ago
  Typings is only necessary when you cannot find the d.ts files from http://microsoft.github.io/TypeSearch/ http://microsoft.github.io/TypeSearch/.
- renke1 10y ago
  Also, for me it's still unclear how versioning is handled. It always seems like you have to use the latest version of the .d.ts and hope it works with your actual package version.
  - DanRosenwasser 10y ago
    `.d.ts` packages should align on major.minor version numbers, so you'll be able to snap to a version and update appropriately.
- WorldMaker 10y ago
  Typings is still useful for .d.ts files on package repositories other than NPM (such as directly from GitHub, Bitbucket, etc). Even then, for the moment it has more flexibility for NPM typings than Typescript on its own. Plus, it's still somewhat nice to keep your type definition dependencies in a separate typings.json rather than mixed in with package.json dependencies.
sepeth 10y ago
"Non-nullable Types" This is the first filter I check when I am deciding to learn a programming language these days. Almost all real world code I saw have had random null checks everywhere.
- tracker1 10y ago
  It's one thing I don't like as much in JS, are those times where a number is a valid input, or a string that is a number, but not null, undefined or other types of values.
bsimpson 10y ago
> In 2.0, we’ve started using control flow analysis to better understand what a type has to be at a given location. Sounds like Flow. Curious to see how they converge/diverge over time. I know there are people who hate the tooling spaghetti that modern JS development involves, but I appreciate that I can plug Flow into a babel/webpack stack and have it just do the error checking. I also have high hopes for things like tree shaking and its ilk that control flow analyzers (Flow, and now TypeScript) will bring to JS going forward. I'm sure you could have Babel just do the experimental transforms and pipe the result into TypeScript, but having two separate sugar/transformation systems seems not-great.
- tracker1 10y ago
  It seems to me since babel6, that flow could be a plugin/extension for babel, and the rest of what typescript offers could simply expand on that... I'd love to see a bit of convergence in this space as well. Then again, I was hoping the same thing with webpack, then we get rollup, etc... it's interesting, though hard to make some choices while staying pragmatic.
- whatever_dude 10y ago
  > I also have high hopes for things like tree shaking They're really starting to put their efforts behind control flow analysis. They already did a little bit of that before (with type guards), but it seems they're really serious about it now. 2.0 also adds verification for unused declarations with `--noUnusedLocals` and `--noUnusedParameters`, so I want to believe they're moving towards tree shaking.
deleted 10y ago
[deleted]
spankalee 10y ago
There are a _lot_ more features than non-nullable types: https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in...
nachtigall 10y ago
> null and undefined are two of the most common sources of bugs in JavaScript. Before TypeScript 2.0, null and undefined were in the domain of every type. So true. Happy to see this. Makes me think of how Rust works.
z3t4 10y ago
Never make clever use of undefined in JavaScript, as it will always result in a bug when someone decided to be a good citizen and gives the variable a value at the same time it's declared. Always be explicit, like var foo=-1; if(foo!=-1) instead of only var foo; if(foo). It will also help the optimizer
hjalle 10y ago
Id love too see partial classes.. It would be so helpful combined with generated classes. Do anyone know any alternative to partial classes with the same functionality as partials in C#?
- purplerabbit 10y ago
  Check out this: http://justinfagnani.com/2015/12/21/real-mixins-with-javascript-classes/ http://justinfagnani.com/2015/12/21/real-mixins-with-javascr... Might provide you with some functionality you're looking for. Since TypeScript is an es6 superset, I'm assuming this will work in that context.
washwash 10y ago
好

359 points by DanRosenwasser 10y ago

out_of_protocol 10y ago

Explain please, why anybody would want both null AND undefined?

recursive 10y ago
They'd want it indirectly, because they want to use or target javascript, which has always had both. There's very little reason why someone would have a primary goal of using both.
Crespyl 10y ago
Similar to why you would want to have both false and 0; it is possible to have a situation in which you wish to define something as explicitly being null. I do think it's a little weird, but it's useful to be able to say that "this key exists and its value is null" as opposed to "there is no such key".
- SigmundA 10y ago
  I usually find it useful in API's, When you send object across undefined means no value was sent, null is a null value sent. That is the difference between not changing a value and changing it to null.
- Matthias247 10y ago
  I thought about that too, but this breaks down once you realize that setting obj.key = undefined; will mutate an object into something which is neither "the key exists and its value is null" nor "there is no such key". The difference can e.g. bite you in things that iterate over the keys of an object or function that do that internally (like deepEquals implementations). I guess in TS2 there would now also be a difference between a field defined as key: string | null | undefined and a field defined as key?: string | null | undefined, because the first one requires setting the key to one of the values on initialization and the other one not.
extrapickles 10y ago
It can be useful when calling a function and you want to say "I don't care about parameter X" when null can be an otherwise valid value for that parameter. I've also found it useful when a function needs to indicate it failed but is in a situation where exceptions are not useful. This is code where the consumer of the function can throw its own much more useful exception or can try to recover from the function failing (eg: it can try and fix the fault). This helps people avoid using exceptions for flow control of the application and lets exceptions be truly exceptional. Examples: //3rd party code could dictate 'bar' be in the spot that it is function needsUndef(foo, bar, other){ if(bar === undefined) bar = expensive_query(); //rest of code } needsUndef(42, cachedResultExpensiveQuery, something); needsUndef(42, undefined, something); and: foo = getFromDisk(foo_path); if(foo === undefined) foo = getFromNetwork(last_resort); is much nicer than: try{ foo = getFromDisk(foo_path); }catch(ex){ //Yes, I know you can filter exceptions, but what if someone forgets or sets too wide //of a net? foo = getFromNetwork(last_resort); } or: if(path_isValid(foo_path) && canReadFromPath(foo_path)) foo = getFromDisk(foo_path); else foo = getFromNetwork(last_resort);
- kilotaras 10y ago
  For second case most people use options in language that have them.
hiou 10y ago
undefined typically means it has yet to be defined whereas null means it does not have a proper value set. For example I use null where there is an exception an cannot set a variable to a sane value. When I see null it means a value could not be set or that it was intentionally unset. undefined means it was never set in the first place.
acjohnson55 10y ago
It's supposed to represent intention. Since all functions in JS are variadic, there has to be a way to differentiate between a parameter not being passed and an "empty" value that is explicitly passed. Technically, you should never explicitly assign `undefined` to anything yourself, but you can propagate it.

neals 10y ago

So how are you guys building TS for web apps? I've been using VS Code, putting classes into namespaces and it builds with commonJS, which I concatenate into a single file that I load into a website. That last part is in need of change because you're not supposed to concatenate commonJS. So how have you been delivering your code to the browser?

salehenrahman 10y ago
I'm currently using a "TypeScript loader" for either Webpack or Browserify. If that seems too much, the other option is to output the compiled code as AMD modules [1]. But I have not tried it myself. Regardless, the option is still there, and, IMO, it seems like a painless transition away from concatenation. http://stackoverflow.com/a/36320145/538570 http://stackoverflow.com/a/36320145/538570
stupidcar 10y ago
We're experimenting with using TypeScript 2.0 for compilation, and webpack 2 for bundling. You can configure TypeScript 2.0 to compile most TS/ES6 syntax to ES5, but to leave the module statements (e.g. import and exports) as ES6. Webpack can then analyse your ES6 module tree and perform "tree shaking", a form of dead code elimination where unused modules are excluded from the compiled bundle. This will become increasingly useful as more libraries are authored in ES6 / TypeScript, as it will allow you to import the whole of a framework like Angular or React, but only ship the parts of it that you actually use in your application.
- stupidcar 10y ago
  And I wanted to add that, while webpack can appear a little intimidating at first, it's actually very easy to setup, and in many ways much simpler than the kind of jerry-rigged concatenation and minification workflows we used to build with Gulp and Grunt.
tomduncalf 10y ago
I've been using Typescript with Webpack (and Babel) for the last 9 months or so and in general been very happy with it, I'd highly recommend it as you get all the Webpack and Babel goodness (hot module reloading for React, async/await, the option to use Babel plugins etc.) on top of Typescript. I've written a step by step guide to setting up Typescript, Webpack and React at http://blog.tomduncalf.com/posts/setting-up-typescript-and-react/ http://blog.tomduncalf.com/posts/setting-up-typescript-and-r... if you're interested to try the set up out.

ken47 10y ago

Another interesting addition is discriminated union types: https://github.com/Microsoft/TypeScript/pull/9163 https://github.com/Microsoft/TypeScript/pull/9163 This will greatly facilitate a more functional style of programming.

MichaelGG 10y ago
Union types without destructuring/pattern matching seems really strange, doesn't it? Special casing a certain property name and converting types based on a string comparison?
- iamdanfox 10y ago
  It's definitely not as elegant as Scala or Haskell, but I think their justification is very reasonable. The current implementation is maximally compatible with existing usages of tagged unions (e.g. Redux actions), because it allows you to choose whatever discriminant you like ('type', 'kind', whatever). Keeping very close to JS seems to be a core tenet of TypeScript and is quite valuable in my opinion. It means they can adopt new ECMAScript syntax without clashes and also ensures that newbies have a smaller learning curve. Also, they can always add in some syntactic sugar later if they want to!
  - lomnakkus 10y ago
    Yeah, the key here is JS-compatibility. Unfortunately, that does mean that TypeScript is sort of a dead end in terms of how far you can go wrt. the fabulousness of your code. (Of course, once everything is statically typed you'll have a much easier time just converting everything to $OTHER_STATICALLY_TYPED_FRONTEND_LANGUAGE, perhaps Scala.js, perhaps PureScript, perhaps js_of_ocaml, perhaps even GHCJS if you're adventurous. (Aside: I'm moderately disappointed the 'fabulousness' was not in my Chromium's spell checker dictionary. It is now.)
    - invaliduser 10y ago
      If by «fabulousness» you mean in terms of static typing, the language may not meet your expectations, but it seems to me it's a bit harsh to say it's a dead-end, considering it's on par with many other languages, and still improving. Also, sorry if you meant something else, «fabulousness» is a very subjective term, not unlike «elegant» (as in «elegant code»), and because it does not have a specific and commonly shared meaning (what is fabulous to you may not by fabulous to others), it's not something I'm very comfortable discussing, although I think I have understood what you meant by it, but with a low level of certainty.

statictype 10y ago

The control-flow analysis of types is very clever. I've been slowly switching away from Coffeescript to Typescript and have been mostly happy with it. Only thing I still struggle with is grappling the namespace/modules mess in Javascript that's been inherited by Typescript.

nathancahill 10y ago
Is it inherited from JS though? I was under the impression that Typescript was doing their own thing (like /// <reference)
- DougBTX 10y ago
  TypeScript picked up a few features that were ultimately removed from JS at the draft spec stage, AFAIK the xml style references were never in a JS spec, but the convention has been around a while. TS also supports import etc.
  - nathancahill 10y ago
    The thing that bugs me the most is the inconsistent implementation of default imports with ES6. Makes it hard to work with a lot of libraries.

knocte 10y ago

> In TypeScript 2.0, the new --strictNullChecks flag changes that. string just means string and number means number. This is great. However, it would be nice to know if this feature will become opt-out in the future instead of opt-in. In theory, if you're a TS user (as opposed to JS) it's because you want these nice features _by default_.

hockeybias 10y ago
Agreed!
oblio 10y ago
Wouldn't that break third party libraries? You'd also need a compiler flag to enable it only for your own code.
- kagia 10y ago
  I feel that typescript being only 2.0, should be in a position to break things once in a while. If you pay too much attention to keeping legacy code 'alive' you end up complicating matters with either compiler-flags all over the place or redundant API's i.e win32 api (old+new+newer versions of the same function).
  - cakoose 10y ago
    The fact that the flag is global could actually slow down adoption of the new type system. Let's say I want to use the new type system, but some library I depend on hasn't been updated. If I enable the new type system, I'll get both false positives and negatives when type checking. If a library writer updated to the new type system, they'd break compatibility with callers that haven't updated. The safest option would be to maintain two almost-identical copies of the library -- one for the old type system and one for the new one. A better option would be to allow specifying the type system mode at the top of each file (like "use strict"). This allows me to use the new type system even if not all my libraries have updated yet. This also allows libraries writers to use the new type system features without breaking existing users.

jensvdh 10y ago

This is fantastic. Kind of gutted they delayed Async/Await until Typescript 2.1 releases. That's the one killer feature I'm missing. Typescript has been nothing short but amazing though!

jsheard 10y ago
In the meantime you can use async with TypeScripts ES6 emitter, which transforms async into generators, then run the output through Babel to transform the generators into plain old ES3/ES5. It's messy but it works.
- moosingin3space 10y ago
  How hard is it to automate this and what impact on build times does it have?
  - Derander 10y ago
    It's not hard to automate with raw gulp or webpack, but it does add a significant amount of time to compilation. It roughly doubled our incremental compile times. My team decided it wasn't worth it, but it's possible that a cleverer person could decrease the overhead.
    - moosingin3space 10y ago
      I ask because I'm debating between trialing TypeScript or Elm for a personal project (I primarily work in Rust and Go on the backend/infrastructure), and iteration times are important when trying to get a frontend UI "just right".
      - jsheard 10y ago
        You could just use TypeScripts ES6 output directly during development, using a browser that supports ES6 natively, then add Babel to the build chain for public builds that need to work on older browsers.

deleted 10y ago

[deleted]

spriggan3 10y ago

let lowerCased = strs!.map(s => s.toLowerCase()); I'm not a big fan of this, it's really starting to change JS semantics. It's not just type annotations anymore + ES6 . It's starting to look like its own language. Some might like that, I do not. They should be a bit more cautious before introducing these features. What if Ecmascript in the future uses ! as an operator for a totally unrelated purpose ? It's like decorators, they are not in the spec, there is no plan yet to officially had them to the spec, yet, Angular2 which is written in Typescript abuse them. What if in 2 years they are introduced in ES2019 with different semantics ? How Typescript is going to handle that too ?

johnfn 10y ago
This post is full of misplaced FUD. > It's not just type annotations anymore + ES6 How not? ! is just an inline type coercion. > What if Ecmascript in the future uses ! as an operator for a totally unrelated purpose ? This seems unlikely because ! is already an operator in JS. But really, this argument could be made against any operator TS uses. What if ES introduces : as an operator? Or if they introduce some sort of ambiguity with the other myriad type definitions? This is not a new issue, and you shouldn't let null checks drive you away from the language. In any case, both null checks and decorators are behind flags. The decorators flag is literally called "experimental decorators". So it's not like the TS team is pretending that it's going to be stable forever.
- h_r 10y ago
  >! is just an inline type coercion. Are you sure about that? It sounds more like a signal to the compiler to "trust me, I know what I'm doing" and would blow up if you passed undefined anyway. Maybe the author didn't explain it very well. That is, not a type coercion so much as a hint to not bother checking this access.
  - johnfn 10y ago
    When would code with ! ever compile differently than code without ! ?

jameslk 10y ago

> This release includes plenty of new features, such as our new workflow for getting .d.ts files[0] Does this mean that using Typings is no longer necessary, or is there some additional benefits that Typings still offers? 0. https://blogs.msdn.microsoft.com/typescript/2016/06/15/the-future-of-declaration-files/ https://blogs.msdn.microsoft.com/typescript/2016/06/15/the-f...

ken47 10y ago
Typings is only necessary when you cannot find the d.ts files from http://microsoft.github.io/TypeSearch/ http://microsoft.github.io/TypeSearch/.
renke1 10y ago
Also, for me it's still unclear how versioning is handled. It always seems like you have to use the latest version of the .d.ts and hope it works with your actual package version.
- DanRosenwasser 10y ago
  `.d.ts` packages should align on major.minor version numbers, so you'll be able to snap to a version and update appropriately.
WorldMaker 10y ago
Typings is still useful for .d.ts files on package repositories other than NPM (such as directly from GitHub, Bitbucket, etc). Even then, for the moment it has more flexibility for NPM typings than Typescript on its own. Plus, it's still somewhat nice to keep your type definition dependencies in a separate typings.json rather than mixed in with package.json dependencies.

sepeth 10y ago

"Non-nullable Types" This is the first filter I check when I am deciding to learn a programming language these days. Almost all real world code I saw have had random null checks everywhere.

tracker1 10y ago
It's one thing I don't like as much in JS, are those times where a number is a valid input, or a string that is a number, but not null, undefined or other types of values.

bsimpson 10y ago

> In 2.0, we’ve started using control flow analysis to better understand what a type has to be at a given location. Sounds like Flow. Curious to see how they converge/diverge over time. I know there are people who hate the tooling spaghetti that modern JS development involves, but I appreciate that I can plug Flow into a babel/webpack stack and have it just do the error checking. I also have high hopes for things like tree shaking and its ilk that control flow analyzers (Flow, and now TypeScript) will bring to JS going forward. I'm sure you could have Babel just do the experimental transforms and pipe the result into TypeScript, but having two separate sugar/transformation systems seems not-great.

tracker1 10y ago
It seems to me since babel6, that flow could be a plugin/extension for babel, and the rest of what typescript offers could simply expand on that... I'd love to see a bit of convergence in this space as well. Then again, I was hoping the same thing with webpack, then we get rollup, etc... it's interesting, though hard to make some choices while staying pragmatic.
whatever_dude 10y ago
> I also have high hopes for things like tree shaking They're really starting to put their efforts behind control flow analysis. They already did a little bit of that before (with type guards), but it seems they're really serious about it now. 2.0 also adds verification for unused declarations with `--noUnusedLocals` and `--noUnusedParameters`, so I want to believe they're moving towards tree shaking.

deleted 10y ago

[deleted]

spankalee 10y ago

There are a _lot_ more features than non-nullable types: https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in...

nachtigall 10y ago

> null and undefined are two of the most common sources of bugs in JavaScript. Before TypeScript 2.0, null and undefined were in the domain of every type. So true. Happy to see this. Makes me think of how Rust works.

z3t4 10y ago

Never make clever use of undefined in JavaScript, as it will always result in a bug when someone decided to be a good citizen and gives the variable a value at the same time it's declared. Always be explicit, like var foo=-1; if(foo!=-1) instead of only var foo; if(foo). It will also help the optimizer

hjalle 10y ago

Id love too see partial classes.. It would be so helpful combined with generated classes. Do anyone know any alternative to partial classes with the same functionality as partials in C#?

purplerabbit 10y ago
Check out this: http://justinfagnani.com/2015/12/21/real-mixins-with-javascript-classes/ http://justinfagnani.com/2015/12/21/real-mixins-with-javascr... Might provide you with some functionality you're looking for. Since TypeScript is an es6 superset, I'm assuming this will work in that context.

washwash 10y ago

好