Hacker News Reader

Comment by Androider | Hacker News Reader

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.

View on HN

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

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

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]

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.

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?

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.

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

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.

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.

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.

Reply on news.ycombinator.com