3 ms·

Question for TypeScript users from someone who's still on the fence: Are you at all worried that TS will end up like CoffeeScript? That is, it starts out with

Question for TypeScript users from someone who's still on the fence: Are you at all worried that TS will end up like CoffeeScript? That is, it starts out with some great ideas that are quite easy to get behind, but JavaScript keeps on advancing year after year and soon you have the same features available but with an annoyingly different syntax, or you actually end up falling behind the curve. You're also not able to simply use the latest JS features, my last attempt at adopting TS died when I found it didn't at the time support object rest and spread properties, which I had been liberally using via Babel for quite some time. It seems like Flow is a "safer" choice to me, but I'd love to hear if you disagree.

deleted 10y ago
[deleted]
Strom 10y ago
The TypeScript team has a goal of keeping it a superset of JavaScript. This means that when JavaScript gets some new features, TypeScript also supports that. If TypeScript supported it before with some other syntax, the syntax gets changed. [1] The hero feature of TypeScript, static typing, will never be available in pure JavaScript based on any current prophecies. -- [1] One reason the object spread/rest situation took so long was because they didn't want to implement it and then have to change the syntax/meaning later. It's better to wait until new proposals have gotten a decent amount of progress, so that they're fairly stable. Do note that spread/rest still isn't in the JavaScript standard, it's a proposal.
- sixdimensional 10y ago
  Side related question- has this going outside of standards with such things as Typescript been harmful? I mean, standards move slowly, but your question raises an interesting point - why didn't we just extend actual Javascript to have typing supported? Have we given up on advancing the core language in such regards?
  - WorldMaker 10y ago
    ES4 attempted to add type support. (It's the ES version time forgot, mostly known only for forks it spawned like Adobe's ActionScript.) Typescript and Flow both resemble, to different degrees, the type support that ES4 attempted (pascal-style `: typename` annotations being common to all of them). Presumably the reasons browsers were not interested in ES4 remain the case today. If that changes, then Typescript/Flow are useful playgrounds to explore what the standard could be. Many ES proposals now require "prollyfills" exploring that feature in the space of existing browsers as proof-of-concept, to help explore possible complications. Typescript and Flow do good jobs of "prollyfilling" type support, and I would expect that if a new attempt to standardize types in ES were to occur, they would both be looked to for advice/guidance.
ng12 10y ago
The current delta between Typescript and ES6 is very small so even if you have an "abandon ship" moment it's probably a days worth of work to get your code compiling with Babel. In fact Flow's types are similar enough that you can probably use the same type information (or just pass it through babel-transform-strip-types).
JamesBarney 10y ago
We were able to get spread to work by using Babel with TypeScript. This is also how people used async before it had official support from the typescript library.
evmar 10y ago
The delta between TypeScript and the JS standard is very small (for many TS users I expect it's a trivia challenge that they won't be able to answer: "write a TS program that isn't valid JS once you erase the types"). As you yourself point out, you were using features that weren't in a browser and needed a different transpiler to implement them. I think object spread still isn't even part of the standard(?) and you could imagine the standard diverging from the babel implementation of it, so the risk is mostly the same there. The TypeScript team is pretty committed to tracking the standard, and e.g. turn down feature proposals that aren't far enough along in the standards process. See https://github.com/Microsoft/TypeScript/issues/16 https://github.com/Microsoft/TypeScript/issues/16 for a feature users are begging for that they aren't implementing. Another good example is that they had their own module system which they deprecated in favor of the ES6 module system. [disclaimer: big TS fan; I think Flow is fine too but I don't think it offers any advantage with respect to the issues you're concerned about here]
- riquito 10y ago
  > As you yourself point out, you were using features that weren't in a browser and needed a different transpiler to implement them. I think object spread still isn't even part of the standard(?) and you could imagine the standard diverging from the babel implementation of it, so the risk is mostly the same there. That's why there are stages and you should use at least stage 2 (draft) https://babeljs.io/docs/plugins/preset-stage-2/ https://babeljs.io/docs/plugins/preset-stage-2/
curveship 10y ago
The TypeScript team's philosophy* is that they want to incorporate features that have either ~0% or ~100% chance of making it into ES. Types they put in the 0% bucket. Once a feature is near 100%, they'll include it. But if it's only at, say, 60%, it doesn't make the cut, for fear that it will change before standardization, leaving TypeScript in the "annoyingly different" situation you describe. * - [edit: found the source] "We'd really like to hit features that have either a ~0% chance of making it into ES7+ (e.g. type annotations), or have a ~100% chance of making it in with easily-defined semantics (e.g. where fat arrow was two years ago). New operators are likely to fall in the awkward middle." [https://github.com/Microsoft/TypeScript/issues/16 https://github.com/Microsoft/TypeScript/issues/16]
peferron 10y ago
I'd be more "worried" to see JS/TS gradually disappear in favor of other languages that compile to wasm. If that happens, it won't matter which JS flavor or superset you're using. There's massive inertia behind JS though, so that'll take a while. I put "worried" in quotes because I'm actually looking forward to using other languages. TS is a fantastic addition, but there's only so much it can do on top of JS, despite the great improvements in ES2015+. For example, I wish TS had a decent enum system with associated values and pattern matching (like Swift for example), but that's unlikely to happen.
Shinchy 10y ago
Can't speak for anyone else but I started out using TypeScrip a while ago. Eventually Javascript just sort of caught up in terms of what was possible with the obvious exception of Type Casting. However after a while the annoyance of certain parts of TypeScript no longer outweighed the benefits I was getting from it, so I've dropped it and instead just use ES6/7 Javascript with Babel and in the end I'm much happier with it.

deleted 10y ago

[deleted]

Strom 10y ago

The TypeScript team has a goal of keeping it a superset of JavaScript. This means that when JavaScript gets some new features, TypeScript also supports that. If TypeScript supported it before with some other syntax, the syntax gets changed. [1] The hero feature of TypeScript, static typing, will never be available in pure JavaScript based on any current prophecies. -- [1] One reason the object spread/rest situation took so long was because they didn't want to implement it and then have to change the syntax/meaning later. It's better to wait until new proposals have gotten a decent amount of progress, so that they're fairly stable. Do note that spread/rest still isn't in the JavaScript standard, it's a proposal.

sixdimensional 10y ago
Side related question- has this going outside of standards with such things as Typescript been harmful? I mean, standards move slowly, but your question raises an interesting point - why didn't we just extend actual Javascript to have typing supported? Have we given up on advancing the core language in such regards?
- WorldMaker 10y ago
  ES4 attempted to add type support. (It's the ES version time forgot, mostly known only for forks it spawned like Adobe's ActionScript.) Typescript and Flow both resemble, to different degrees, the type support that ES4 attempted (pascal-style `: typename` annotations being common to all of them). Presumably the reasons browsers were not interested in ES4 remain the case today. If that changes, then Typescript/Flow are useful playgrounds to explore what the standard could be. Many ES proposals now require "prollyfills" exploring that feature in the space of existing browsers as proof-of-concept, to help explore possible complications. Typescript and Flow do good jobs of "prollyfilling" type support, and I would expect that if a new attempt to standardize types in ES were to occur, they would both be looked to for advice/guidance.

ng12 10y ago

The current delta between Typescript and ES6 is very small so even if you have an "abandon ship" moment it's probably a days worth of work to get your code compiling with Babel. In fact Flow's types are similar enough that you can probably use the same type information (or just pass it through babel-transform-strip-types).

JamesBarney 10y ago

We were able to get spread to work by using Babel with TypeScript. This is also how people used async before it had official support from the typescript library.

evmar 10y ago

The delta between TypeScript and the JS standard is very small (for many TS users I expect it's a trivia challenge that they won't be able to answer: "write a TS program that isn't valid JS once you erase the types"). As you yourself point out, you were using features that weren't in a browser and needed a different transpiler to implement them. I think object spread still isn't even part of the standard(?) and you could imagine the standard diverging from the babel implementation of it, so the risk is mostly the same there. The TypeScript team is pretty committed to tracking the standard, and e.g. turn down feature proposals that aren't far enough along in the standards process. See https://github.com/Microsoft/TypeScript/issues/16 https://github.com/Microsoft/TypeScript/issues/16 for a feature users are begging for that they aren't implementing. Another good example is that they had their own module system which they deprecated in favor of the ES6 module system. [disclaimer: big TS fan; I think Flow is fine too but I don't think it offers any advantage with respect to the issues you're concerned about here]

riquito 10y ago
> As you yourself point out, you were using features that weren't in a browser and needed a different transpiler to implement them. I think object spread still isn't even part of the standard(?) and you could imagine the standard diverging from the babel implementation of it, so the risk is mostly the same there. That's why there are stages and you should use at least stage 2 (draft) https://babeljs.io/docs/plugins/preset-stage-2/ https://babeljs.io/docs/plugins/preset-stage-2/

curveship 10y ago

The TypeScript team's philosophy* is that they want to incorporate features that have either ~0% or ~100% chance of making it into ES. Types they put in the 0% bucket. Once a feature is near 100%, they'll include it. But if it's only at, say, 60%, it doesn't make the cut, for fear that it will change before standardization, leaving TypeScript in the "annoyingly different" situation you describe. * - [edit: found the source] "We'd really like to hit features that have either a ~0% chance of making it into ES7+ (e.g. type annotations), or have a ~100% chance of making it in with easily-defined semantics (e.g. where fat arrow was two years ago). New operators are likely to fall in the awkward middle." [https://github.com/Microsoft/TypeScript/issues/16 https://github.com/Microsoft/TypeScript/issues/16]

peferron 10y ago

I'd be more "worried" to see JS/TS gradually disappear in favor of other languages that compile to wasm. If that happens, it won't matter which JS flavor or superset you're using. There's massive inertia behind JS though, so that'll take a while. I put "worried" in quotes because I'm actually looking forward to using other languages. TS is a fantastic addition, but there's only so much it can do on top of JS, despite the great improvements in ES2015+. For example, I wish TS had a decent enum system with associated values and pattern matching (like Swift for example), but that's unlikely to happen.

Shinchy 10y ago

Can't speak for anyone else but I started out using TypeScrip a while ago. Eventually Javascript just sort of caught up in terms of what was possible with the obvious exception of Type Casting. However after a while the annoyance of certain parts of TypeScript no longer outweighed the benefits I was getting from it, so I've dropped it and instead just use ES6/7 Javascript with Babel and in the end I'm much happier with it.