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

61–70 of 95 posts

Re: Announcing TypeScript 2.0 Beta

#61

Post by tracker1 »

bsimpson wrote: post #28

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

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.

Re: Announcing TypeScript 2.0 Beta

#62

Post by z3t4 »

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

Re: Announcing TypeScript 2.0 Beta

#64

Post by tracker1 »

sepeth wrote: post #17

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

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.

Re: Announcing TypeScript 2.0 Beta

#65

Post by tomduncalf »

jsheard wrote: post #12
jensvdh wrote: post #5

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!

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.

If anyone is interested in this setup, I wrote a blog post recently about setting up Typescript with Webpack and React which describes how to set it up so that the Typescript output passes through Babel: http://blog.tomduncalf.com/posts/setting-up-typescript-and-r...

Re: Announcing TypeScript 2.0 Beta

#66

Post by tomduncalf »

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?

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-r... if you're interested to try the set up out.

Re: Announcing TypeScript 2.0 Beta

#67

Post by SigmundA »

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

Re: Announcing TypeScript 2.0 Beta

#68

Post by WorldMaker »

knocte wrote: post #3

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

I appreciate Typescript remaining opt-in for all of these things (as that seems a clear goal of the project, --noImplicitAny has been like that since very early on), but it would be nice to have some sort of intentional signifier flag --maximumStrictness or whatever you want to call it that does a rolling opt-in to all the strictest checks as new ones are invented.

Re: Announcing TypeScript 2.0 Beta

#69

Post by whatever_dude »

bsimpson wrote: post #28

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

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

Re: Announcing TypeScript 2.0 Beta

#70

Post by lomnakkus »

iamdanfox wrote: post #59
MichaelGG wrote: post #55

Earlier quoted context omitted.

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?

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

(Aside: I'm moderately disappointed the 'fabulousness' was not in my Chromium's spell checker dictionary. It is now.)

Post reply on HN