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

Announcing TypeScript 1.7

blogs.msdn.com

Post reply on HN
Print view View original

11–20 of 93 posts

Re: Announcing TypeScript 1.7

#11

Post by TazeTSchnitzel »

Arnavion wrote: post #9
TazeTSchnitzel wrote: post #6

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

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.

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.

Re: Announcing TypeScript 1.7

#12

Post by wildmusings »

TazeTSchnitzel wrote: post #7
carterehsmith wrote: post #5

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…

Can TypeScript do runtime enforcement at the boundaries between typed and untyped code, though?

This is a neat idea. Even with a significant perf hit, it could be used during development, testing, and debugging. You should propose this to the Typescript team! https://github.com/Microsoft/TypeScript/issues

Re: Announcing TypeScript 1.7

#13

Post by TazeTSchnitzel »

wildmusings wrote: post #12
TazeTSchnitzel wrote: post #7

Earlier quoted context omitted.

Can TypeScript do runtime enforcement at the boundaries between typed and untyped code, though?

This is a neat idea. Even with a significant perf hit, it could be used during development, testing, and debugging. You should propose this to the Typescript team! https://github.com/Microsoft/TypeScript/issues

I recall some paper from people who had already implemented it.

Edit: It might have been this one: http://research.microsoft.com/apps/pubs/?id=224900

Re: Announcing TypeScript 1.7

#14

Post by dfabulich »

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

Re: Announcing TypeScript 1.7

#15

Post by pspeter3 »

TazeTSchnitzel wrote: post #7
carterehsmith wrote: post #5

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…

Can TypeScript do runtime enforcement at the boundaries between typed and untyped code, though?

You can add type safe guards which uses reflection at runtime.

Re: Announcing TypeScript 1.7

#16

Post by richdougherty »

TazeTSchnitzel wrote: post #7
carterehsmith wrote: post #5

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…

Can TypeScript do runtime enforcement at the boundaries between typed and untyped code, though?

Something like this?

"Safe TypeScript: Safe and Efficient Gradual Typing for TypeScript"

http://research.microsoft.com/apps/video/default.aspx?id=226...

Re: Announcing TypeScript 1.7

#17

Post by TazeTSchnitzel »

richdougherty wrote: post #16
TazeTSchnitzel wrote: post #7

Earlier quoted context omitted.

Can TypeScript do runtime enforcement at the boundaries between typed and untyped code, though?

Something like this? "Safe TypeScript: Safe and Efficient Gradual Typing for TypeScript" http://research.microsoft.com/apps/video/default.aspx?id=226...

That was precisely the paper I was thinking of.

Re: Announcing TypeScript 1.7

#18

Post by ahoge »

dfabulich wrote: post #14

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

Edge 13 does support generators.

http://kangax.github.io/compat-table/es6/

Re: Announcing TypeScript 1.7

#19

Post by yesimahuman »

carterehsmith wrote: post #5

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…

We've been using it over at Ionic, and that's exactly what we've found as well. Types are great...but they're overhead that most apps don't need on day one. When you just want to get something up and running you can skip them. Once you dig in and really build out the application, you can add them and get a bunch of great benefits (type safety, autocompletion, "free" API documentation, etc.).

On top of that, tsc is possibly the fastest/easiest to use transpiler out there, which helps.

Re: Announcing TypeScript 1.7

#20

Post by ahoge »

carterehsmith wrote: post #5

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…

> Want to bang up a quick solution, as in MVP? Use bare-bones Javascript

Actually, adding the bare minimum of type annotations (fields & function signatures) and type casts (e.g. casting whatever you get from querySelector into the concrete type of element) results in fewer key presses, because you can auto-complete everything and because you get additional machine-assistance like call tips and type checks.

So, you'll be actually faster if you add some types. Type inference does cover quite a lot. In practice, you'll need very few annotations and casts.

This Dart demo, for example, only needed a single type cast to be fully typed:

https://dartpad.dartlang.org/e23e4d137570c652591e

Post reply on HN