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

Announcing TypeScript 2.2

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

51–60 of 123 posts

Re: Announcing TypeScript 2.2

#51

Post by Rapzid »

MehdiHK wrote: post #43
dangoor wrote: post #33

Earlier quoted context omitted.

TypeScript compiles to JS in a straightforward manner as well. If you wanted to move away from TS, you could simply have the TS compiler compile to ES6 and you're done.

But that'd still be transpiled code, right? After getting rid of flow it will be exactly same minus the type annotations. Same cannot be said about typescript considering various language features and syntactic sugar TS offers. Will it run? Yes. Will it feel that it was written by me? That depends.

Your equivalence with transpiling coffeescript is false. TS doesn't really have "syntactic sugars". Just about everything in it(less the types of course) is pretty far along in the ES adoption process. There are a couple exceptions like decorators that are called out in a very visible manner.

If you target ES6 your code may look identical. Even much of the ES5 down leveling produced code that looks like a person wrote it.

I converted a 10k line coffeescript project(with async/await !) to JS and then TypeScript. The similarities are so far apart they might as well be in different dimensions. But, if you don't want to take a rando posters word for it, it's pretty easy to make a little sample project and see if the output is to your liking.

Re: Announcing TypeScript 2.2

#52

Post by treehau5 »

Nemcue wrote: post #24
treehau5 wrote: post #21

I know this probably comes up each typescript thread, but I still cannot figure out why I should use TS instead of flow + es6, and maintaining the typing definitions always discourages me as it's one more thing that needs to be kept up to date. Am I working on old information here?

Why would flow + es6 be better?

- You are writing javascript, not typescript.

- When typescript came out, I was an early adopter, and a lot of it's touted benefits were the class-like syntax and constructors to make it more palatable to enterprise shops (not for me, but it was easier to sell to higher ups), this is mostly a moot point now.

- flow can be attached to any codebase as the codebase stands easily. It is, I have found, difficult to bring TS into an existing project.

- flow fits nicely into existing popular js tooling, mainly babel and react.

- no risk of vendor lock in. Maybe TS compiles to pure 100% syntactically correct javascript today, maybe it doesn't in the future. It isn't javascript, so I won't know.

Re: Announcing TypeScript 2.2

#53

Post by treehau5 »

whatever_dude wrote: post #39
treehau5 wrote: post #29

Earlier quoted context omitted.

Also, you can progressively opt in to add typing information, while still getting most of the benefits without.

The same can be done with TypeScript. Type inference has been added to it in 2015.

Awesome, did not know this.

Re: Announcing TypeScript 2.2

#54

Post by whatever_dude »

MehdiHK wrote: post #43
dangoor wrote: post #33

Earlier quoted context omitted.

TypeScript compiles to JS in a straightforward manner as well. If you wanted to move away from TS, you could simply have the TS compiler compile to ES6 and you're done.

But that'd still be transpiled code, right? After getting rid of flow it will be exactly same minus the type annotations. Same cannot be said about typescript considering various language features and syntactic sugar TS offers. Will it run? Yes. Will it feel that it was written by me? That depends.

> Same cannot be said about typescript considering various language features and syntactic sugar TS offers

I think you're vastly misinterpreting what TS is.

It's not anything like CoffeeScript. It's JS plus types and a few other features like Interfaces or advanced ECMAScript features when targetting older versions of the standard.

If you strip away types by exporting to your ECMAScript target of choice, you'll get real JavaScript with the same style as it was written in TypeScript.

It's exactly the same thing you'd get with Flow in that sense. The only additional code you'd get would be for polyfills, but a) those are minimal and b) those will only appear if you export to an older ECMAScript version than the one you wrote it in.

There is no vendor lock.

Re: Announcing TypeScript 2.2

#55

Post by icholy »

MehdiHK wrote: post #27
Nemcue wrote: post #24

Earlier quoted context omitted.

Why would flow + es6 be better?

Avoid vendor locking. Someday in near future if you don't like flow anymore, you can just strip all type annotations with Babel and move on. You are not risking ending up like coffeescript.

> Avoid vendor locking.

It's open source.

> you can just strip all type annotations with Babel and move on.

Are you implying that this isn't possible with TypeScript?

Re: Announcing TypeScript 2.2

#56

Post by whatever_dude »

treehau5 wrote: post #52
Nemcue wrote: post #24

Earlier quoted context omitted.

Why would flow + es6 be better?

- You are writing javascript, not typescript. - When typescript came out, I was an early adopter, and a lot of it's touted benefits were the class-like syntax and constructors to make it more palatable to enterprise shops (not for me, but it was easier to sell to higher ups), this is mostly a moot point now. - flow can be attached to any codebase as the codebase stands easily. It is, I have found, difficult to bring…

At the risk of probably repeating myself, allow me to give my $0.02:

> - You are writing javascript, not typescript.

Flow's and TypeScript's distance to JS world are the same, and are very similar in most cases. If you want to add type to one, it's the same as in the other. The only difference here is the file extension, since TS tends to like .ts/.tsx.

> - When typescript came out, I was an early adopter, and a lot of it's touted benefits were the class-like syntax and constructors to make it more palatable to enterprise shops (not for me, but it was easier to sell to higher ups), this is mostly a moot point now.

True, although IMO the greatest feature of TS is making your code stronger, not compiling things that are already part of some ECMAScript version.

>- flow can be attached to any codebase as the codebase stands easily. It is, I have found, difficult to bring TS into an existing project.

True, with TS it's more of a lateral move rather than drops here and there.

>- flow fits nicely into existing popular js tooling, mainly babel and react.

TS works just as well; better, IMO, because dev tools (editors, linters) have better TS support in my experience. Writing React in JS to me makes me feel like I'm using Notepad since there's so much TS helps me with that is lost when using a purely dynamic language.

>- no risk of vendor lock in. Maybe TS compiles to pure 100% syntactically correct javascript today, maybe it doesn't in the future. It isn't javascript, so I won't know.

It does compile to pure JS so ejecting TS is easy; it's trying to follow future standards and proposed changes, not create something different; the project is open source. There is no vendor lock in.

Re: Announcing TypeScript 2.2

#57

Post by shados »

treehau5 wrote: post #21

I know this probably comes up each typescript thread, but I still cannot figure out why I should use TS instead of flow + es6, and maintaining the typing definitions always discourages me as it's one more thing that needs to be kept up to date. Am I working on old information here?

I've done some average sized projects in Flow and in TypeScript, and it's a lot more subtle IMO than most people would have it (especially people who only tried one, or only tried both cursively)

TypeScript absolutely has the better tooling. It's not even -close-. It's a little tricky though because a lot of FE devs these days use VIM or Sublime with a few plugins and a linter running in a terminal is as far as it goes, so explaining the importance of proper refactoring tool and semantic search is tough (no, using grep/ag/ack is not enough in a large code base, no matter how good you are with them).

On the other hand, the Flow checker is a lot more interesting, with more advanced call site analysis, and the type inference follows types a lot further (where you can type an entire file without any annotations, though Flow does require them on exports if you want imports in other files to be typed). That means functions with no annotations are much more frequently type checked and it's more useful during prototyping.

Flow is also a bit more careful about putting on the C#/Java lipstick (neither Flow nor TypeScript are actually java/C#-like, being much more functional and using structural typing as first class citizens, but TypeScript definitely LOOK the part to the untrained eyes, which makes developers used with those languages try to use the same patterns and heavily abuse classes instead of union types, etc. In Flow it's less of an issue).

Flow definitely causes a lot more surprises: call site analysis means error messages can be more confusing, and certain cases like inaccessible code path can cause some surprising scenarios.

flow-typed has many less type definitions, but they're generally higher quality. TypeScript's type definitions I found are very, very poor, as a relic of the days where versioning was an issue and many have not been fixed. You also have issues with useStrictNull not having been there all along causing problems. TypeScript however benefits heavily from having more libraries being native TypeScript, which is better than having good type definitions.

Finally, while TypeScript's tooling is vastly superior, Flow has the benefit of being parsable by Babel via Babylon, making large parts of the ecosystem a lot more Flow friendly. This came up recently with the amazing Prettier project being a non-starter for TypeScript users.

I've been hopping between vanilla JS, Flow and TypeScript continually...and no matter which one I use, I wish I was using another.

Re: Announcing TypeScript 2.2

#58

Post by SquareWheel »

kakarot wrote: post #49
XaspR8d wrote: post #42

Earlier quoted context omitted.

For passersby who were confused like I was: IntelliJ Community Edition has absolutely no support for Javascript or Typescript, which is not noted clearly in the help docs. You apparently need Ultimate Edition to get it. I was real excited that I could finally use the same IDE for front-end and back-end too... :/

The price gets lower each year for the first few years you renew your license. My company pays for my license but I think it's hella worth it and I'd pay it on my own if I had to. I avoid VS like the plague and I've never really felt at home in an IDE until I started using IntelliJ. It's the only thing that was able to get me off of Notepad++

I also avoid VS, but VSCode is nothing at all like its big brother. It's actually very quick and lean.

If you're interested in TypeScript at all, the two were made for each other. I'd suggest giving it a try.

Just note it's closer to a text editor with IDE functionality, rather than a full-blown IDE itself.

Re: Announcing TypeScript 2.2

#59

Post by shados »

whatever_dude wrote: post #56
treehau5 wrote: post #52

Earlier quoted context omitted.

- You are writing javascript, not typescript. - When typescript came out, I was an early adopter, and a lot of it's touted benefits were the class-like syntax and constructors to make it more palatable to enterprise shops (not for me, but it was easier to sell to higher ups), this is mostly a moot point now. - flow can be attached to any codebase as the codebase stands easily. It is, I have found, difficult to bring…

At the risk of probably repeating myself, allow me to give my $0.02: > - You are writing javascript, not typescript. Flow's and TypeScript's distance to JS world are the same, and are very similar in most cases. If you want to add type to one, it's the same as in the other. The only difference here is the file extension, since TS tends to like .ts/.tsx. > - When typescript came out, I was an early adopter, and a lot…

There's a few subtle things here. Flow does support annotating types with comments, and can type check React's flowtypes, so you actually can get a fair bit without a compiler at all. In practice, no one does that, so you're still right, but it's worth nothing.

And it's worth noting that TypeScript having its own parser vs the rest of the world using Babel is a pain in the rear. See the time it took for ESLint (having to us TSLint in the meantime), now Prettier, having to use TypeScript with an ES6 target and piping the output in Babel to get proper plugin support, the difference between webpack's resolution mechanism and the one used by TypeScript in tools (an issue Flow also shares), and so on.

Some features like enums (omg, TS enums die die die) namespaces, decorators, and the old module system are also pretty awkward when blending with modern javascript. Makes you want to add lint rules to prevent them from being used.

Re: Announcing TypeScript 2.2

#60

Post by shados »

Touche wrote: post #47
davesnothere wrote: post #30

Earlier quoted context omitted.

One reason flow might be considered "better" (context is key) is that it plays well with the babel ecosystem, letting one pick and choose their language features.

Picking and choosing language features via babel plugins (many of which will never become part of JavaScript) is an anti-feature. You essentially are creating your own language that only you understand.

The parser features are fixed. The plugins enable/disable them, but they're already "there", just toggled. As far as I know at this point the parser is not pluggable. Babel is a playground for the official TC39 proposals so it might get stuff a little early, but that's about it.

Where the plugins shine is when compiling those (part of the standard) features to something interesting for production. Better inlining, adding debugging and instrumentation, compiling away certain things, optimizing your views for performance, etc.

All things that don't change the language whatsoever, but can improve your debugging or production experience.

That can be done in TS world (and is quite common) by targeting ES6 and piping the result in Babel though. It's just annoying.

You do have things like Prettier not being compatible with TS because different parsers, though.

Post reply on HN