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

71–80 of 93 posts

Re: Announcing TypeScript 1.7

#71

Post by tkubacki »

ahoge wrote: post #20
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'l…

WOW ! this code is impressive - do you have more examples like this?

Re: Announcing TypeScript 1.7

#72

Post by Keats »

haberman wrote: post #26
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…

How is this different from using Facebook Flow? I have been using Flow on a JavaScript project, along with Babel for ES6, and enjoying the experience quite a lot.

We compared Flow and Typescript for our projects, you can see the articles https://blog.wearewizards.io/flow-and-typescript-part-1-flow and https://blog.wearewizards.io/flow-and-typescript-part-2-type...

TL;DR: Flow inference is super nice but community and tooling is lacking compared to TypeScript imo so we ended up using TS

Re: Announcing TypeScript 1.7

#73

Post by sjrd »

Arnavion wrote: post #4
lukasm wrote: post #3

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

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

> It won't work if each method returns a new instance, such as methods of immutable collections.

TS' this type does not allow that either. You have to return `this`, and nothing else.

This can be explained by inheritance. If you extend a class with a method returning a `this` type, but not returning `this`, somehow you should be forced to override that method. But you probably don't want that.

Also, the `this` type introduced by TS is basically equivalent to Scala's `this.type`.

Re: Announcing TypeScript 1.7

#74

Post by castell »

ebbv wrote: post #24

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…

I upvoted you, because you are right.

We would be better off, adding optional typing to JavaScript 6/7. They already added "class" syntactic sugar thanks to them.

Dart and TypeScript just divide the devs and open code base. It's like finding a great project on Github only to figure out it coded in language XY.

Re: Announcing TypeScript 1.7

#75

Post by Keats »

pluma wrote: post #62

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.

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

Re: Announcing TypeScript 1.7

#76

Post by pluma »

lukasm wrote: post #65
pluma wrote: post #62

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.

because TypeScript is a super set of ES.

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.

Re: Announcing TypeScript 1.7

#77

Post by pluma »

Keats wrote: post #75
pluma wrote: post #62

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.

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

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.

Re: Announcing TypeScript 1.7

#78

Post by pluma »

MasterScrat wrote: post #66
pluma wrote: post #62

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.

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

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.

Re: Announcing TypeScript 1.7

#79

Post by Keats »

pluma wrote: post #77
Keats wrote: post #75

Earlier quoted context omitted.

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

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.

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

Re: Announcing TypeScript 1.7

#80

Post by jbrantly »

pluma wrote: post #78
MasterScrat wrote: post #66

Earlier quoted context omitted.

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

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

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.

Post reply on HN