Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing TypeScript 2.0 Beta

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

71–80 of 95 posts

Re: Announcing TypeScript 2.0 Beta

#71

Post by WorldMaker »

neals wrote: post #41

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?

In the past I've used TS with AMD/RequireJS. These days I've been using TS with JSPM and SystemJS, with various combinations of Babel in the mix and JSPM/System bundler.

I have projects that configure SystemJS to use TS itself as the only ES2015/TS transpiler (and thus no emit necessary in development, let the browser compile it, which makes for a fairly nice rebuild). You can even use TS directly as your bundler in this case if all you want to bundle are your TS sources as it supports the SystemJS registration format.

I also have some projects that still use Babel as a transpiler and TS emitting ES2015+JSX to it (still in the JSPM/SystemJS stack). I've particularly needed this because TSX is great but it's support for non-React TSX emission is still somewhat lacking in my opinion versus what easily works in Babel.

Re: Announcing TypeScript 2.0 Beta

#72

Post by extrapickles »

out_of_protocol wrote: post #34

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

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);

Re: Announcing TypeScript 2.0 Beta

#73

Post by WorldMaker »

jameslk wrote: post #15

> 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-f...

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.

Re: Announcing TypeScript 2.0 Beta

#74

Post by hiou »

out_of_protocol wrote: post #34

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

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.

Re: Announcing TypeScript 2.0 Beta

#75

Post by rattray »

bcherny wrote: post #25
rattray wrote: post #20

Earlier quoted context omitted.

Agreed – this may now be my top reason not to use TypeScript (followed by inadequate inference / support for gradual typing, differences from Babel, and a few random features), which I would otherwise very much like to use.

This is a poor reason to not use TS. If in the unlikely worst case scenario the TS team drops/renames the ! syntax at some point, given that these are compile time checks, you will just manually go through a list of compile time errors and fix the issues one by one. More likely scenarios: - They will make the change in a backwards-compatible way - They will release a jscodeshift script to do the upgrade for you - Etc…

Okay, fair. Perhaps I overreacted.

I think the general idea of adding syntax outside of declarations really rubs me the wrong way, but perhaps it shouldn't.

Re: Announcing TypeScript 2.0 Beta

#76

Post by shados »

ihsw wrote: post #27
spriggan3 wrote: post #10

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 decor…

Do you have the same complaints about optional parameters too? let x = (id: number, name?: string) => { return; }; Is it abuse to use interfaces as well? They are not present in vanilla JS. How about React's move away from React.createClass({}) to ES6 classes extending React.Component? Do they abuse classes? Async/await is coming too and it will turn JS on its head, does eschewing callbacks for async functions also c…

You're right, it was never meant to just be annotations+ES6. Though when you talk to someone about TypeScript, they'll argue until they're blue in the face that its just "ES6 with types". I guess you can argue semantics here, but don't be too surprise people will argue back that way.

Re: Announcing TypeScript 2.0 Beta

#77

Post by acjohnson55 »

out_of_protocol wrote: post #34

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

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.

Re: Announcing TypeScript 2.0 Beta

#78

Post by invaliduser »

lomnakkus wrote: post #70
iamdanfox wrote: post #59

Earlier quoted context omitted.

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…

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 adven…

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.

Re: Announcing TypeScript 2.0 Beta

#79

Post by nightski »

shados wrote: post #76
ihsw wrote: post #27

Earlier quoted context omitted.

Do you have the same complaints about optional parameters too? let x = (id: number, name?: string) => { return; }; Is it abuse to use interfaces as well? They are not present in vanilla JS. How about React's move away from React.createClass({}) to ES6 classes extending React.Component? Do they abuse classes? Async/await is coming too and it will turn JS on its head, does eschewing callbacks for async functions also c…

You're right, it was never meant to just be annotations+ES6. Though when you talk to someone about TypeScript, they'll argue until they're blue in the face that its just "ES6 with types". I guess you can argue semantics here, but don't be too surprise people will argue back that way.

Well it depends how you use it also. To them it really could be ES6 with annotations.

Re: Announcing TypeScript 2.0 Beta

#80

Post by Matthias247 »

Crespyl wrote: post #51
out_of_protocol wrote: post #34

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

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".

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.

Post reply on HN