
TypeScript Won - SanderMak
https://medium.com/@basarat/typescript-won-a4e0dfde4b08#.a8e1ay4m6
======
knowtheory
I could quibble with the conflation of correlation w/ causation for a lot of
the comments this post makes about es6/babel or coffeescript.

But each time i re-read this post, the cohesive point that pops out most is
that this post is basically a Donald Trump speech about Typescript.

The claim is that it's bigger, it's better, and everyone else is a bit sad. It
disingenuously claims that it's not about about competition and then
_literally ends with_ "Typescript Won".

So, lemme offer some rhetorical advice:

1) pick to a POV & stick to it. It's a competition or it's not. You either
think it's worth highlighting how much better Typescript is over other
technologies, or you don't.

2) Most of the points made in the post aren't assertions about the benefits of
Typescript or the decisions it makes. Not everyone agrees that the existence
of a static type checker is an unqualified benefit (and there are many
dimensions to that conversation). If you want to make the assertion that
Typescript makes your life easier/better _because it has a type checker_ ,
assert the benefits of having a type checker (and the decision making for
AngularJS's adoption of Typescript on the basis of having a type checker could
use a citation).

3) Related to 1., this post comes off as MEGA passive-aggressive because you
keep on mentioning how much you also love other technologies _at the same
time_ talking about how they are inferior to Typescript on a variety of
shifting bases. Because of that you're not telling a cohesive story about
Typescript. You're just talking about how you think other technologies are
bad.

~~~
mordocai
On point 2, I don't think an optional type checker has any real downsides that
I can think of (optional because with typescript you don't have to add type
annotations to your code). It helps with debugging and possibly performance
but you can choose not to use it.

The rest of your comment I agree with.

~~~
doodpants
I have no experience with TypeScript, but in general the downside of optional
language features is when you're working with a team, and different people end
up using different dialects of the language.

~~~
chimeracoder
That doesn't really apply here, because type annotations have no runtime
effect. They're effectively comments.

~~~
jaredklewis
The content of comments isn't enforced by the compiler, so I would say they
are not very comment-like.

------
thejameskyle
It's frustrating that the only reason thats really given for TypeScript being
"better" than Babel is that it has more downloads, using incorrect charts to
prove it.

Here's the actual download charts if you are interested:
[https://twitter.com/thejameskyle/status/725344218411986946](https://twitter.com/thejameskyle/status/725344218411986946)

Source: \- babel-core: [http://npm-stat.com/charts.html?package=babel-
core&author=&f...](http://npm-stat.com/charts.html?package=babel-
core&author=&from=2015-04-28&to=2016-04-27) \- typescript: [http://npm-
stat.com/charts.html?package=typescript&author=&f...](http://npm-
stat.com/charts.html?package=typescript&author=&from=2015-04-28&to=2016-04-27)

Also if you want types with Babel, use Flow– which is arguably a much better
type system anyways.

~~~
avolcano
fwiw, TypeScript -> Babel is doable, if painful. I have it set up in my repo
here:
[https://github.com/thomasboyt/manygolf](https://github.com/thomasboyt/manygolf)

I agree that Flow currently the superior type system (and, unlike TypeScript,
not a complete nightmare to set up if you're wanting to use Babel/Webpack
instead of manually running file builds through your editor like it's 2002),
but TypeScript has significantly more momentum behind it making it a much more
practical solution for basically anyone who doesn't currently work at
Facebook. There are also several exciting new features coming to the type
system that brings it closer to parity with Flow:

Non-nullable types:
[https://github.com/Microsoft/TypeScript/pull/7140](https://github.com/Microsoft/TypeScript/pull/7140)

Control flow type analysis:
[https://github.com/Microsoft/TypeScript/pull/8010](https://github.com/Microsoft/TypeScript/pull/8010)

I wish TypeScript tried to better-integrate with the greater JavaScript
ecosystem and stop acting as a language of its own. Thankfully, the "es6"
target gets it pretty close (I think it still compiles some es7 features,
meaning you can't have Babel handle everything yet), and the non-standard
module syntax seems to be a thing of the past.

I hope the gap can be bridged between the TypeScript and Babel communities, so
that TypeScript can one day be shipped as a Babel transform, same as Flow.

~~~
thejameskyle
There's not really a gap between them. I've spoken to people on the TypeScript
team a number of times. Jonathan Turner and I talked about sharing ASTs once,
and I gave an internal presentation about Babel at Microsoft last year. Also,
there's tons of people that use TypeScript for type-checking and stripping
types and then use Babel for compiling down ES2015 code since Babel follows
the spec closer.

~~~
WorldMaker
Not to mention that currently Typescript doesn't emit certain types of
polyfills so it can be handy to let Babel manage that.

------
antjanus
One thing that makes a huge difference is the plugin ecosystem. TypeScript, as
far as I know, doesn't have any while Babel has a whole myriad of them by
various people.

I recently built a Babel plugin that solves a lot of my module import pathing
issues (namely the `../../` hell)

[https://github.com/AntJanus/babel-plugin-
namespaces](https://github.com/AntJanus/babel-plugin-namespaces)

This and other plugins are just not possible on TS. The best way to look at
Babel vs TypeScript is to realize they do different things. As far as Babel
ES2015 transpiling vs TypeScript, maybe TS wins out. But Babel is a whole
platform for transpiling. In fact, you can use both Babel and TypeScript
together!

------
koolba
Does anyone here have _bad_ things to say about TypeScript?

I haven't used it for any large projects yet (couple toy ones) but seems
pretty legit. Based on my anecdata, people who have used it at scale seems to
like it.

I can't tell if that's because they're still in the honeymoon phase or if it
really is a step forward for the long term.

~~~
Keats
The type system is not that great and inference is quite limited. Definitions
are not always existent or up to date and a single repo like definitelytyped
is a terrible way to manage all the definitions.

The above sounds negative but TS is still the best bet right now imo. Some
people will prefer Elm or Purescript for better type systems but I like
staying close to JS.

~~~
d1plo1d
Personally, I'm more excited about Flow because it introduces a modern type
system into ES6/ESNext without me having to sacrifice Babel.

With regards to types: TypeScript has only recently added support for any kind
of Algebraic Data Types whereas Flow was built upon Unions and Intersections
from day one. That to me speaks to their priorities.

~~~
softawre
Unions were added in TS 1.4, over a year ago.

[https://blogs.msdn.microsoft.com/typescript/2015/01/16/annou...](https://blogs.msdn.microsoft.com/typescript/2015/01/16/announcing-
typescript-1-4/)

~~~
WorldMaker
Also, Intersections were added in TS 1.6, last year:

[https://blogs.msdn.microsoft.com/typescript/2015/09/16/annou...](https://blogs.msdn.microsoft.com/typescript/2015/09/16/announcing-
typescript-1-6/)

They seem to be moving at a decent, agile pace to improving/expanding upon the
algebraic sides of the type system.

~~~
d1plo1d
Yup, I was definitely wrong on that one. Sorry about that.

Thank you for correcting me.

~~~
WorldMaker
Next up on the roadmap, Typescript is working to add opt-in strict null and
undefined checking which is probably the last area where Flow's type system is
particularly better than Typescript's.

(It will be opt-in as Typescript follows a rule of increasing strictness via
compile options to support the spectrum of JS needs, but also as it will not
be entirely backward compatible with existing type definition files and will
need some effort among typings authors.)

------
symlinkk
I bet we'll be seeing a lot more of Typescript in the next few years, seeing
as it's the default language that is suggested in Angular 2's documentation. I
find it odd that Dart wasn't the default language of choice for Angular 2
(although it is fully supported) seeing as Google is behind both projects. I
think it really boils down to what the author wrote here: "Dart is not
JavaScript. TypeScript is." At the end of the day more people are going to
want to use what they are already more familiar with, and it's really not
necessary to throw out years and years of progress we have made on JS.

~~~
pjmlp
For me it was a clear message to the outside world, how little backing Dart
has inside Google, if their management allows for choosing a programming
language designed by the competition instead of their own one, for their own
products.

~~~
LukeB_UK
Or it shows that they see that there's already an established base of people
using TypeScript, more than Dart, and choosing to follow where the community
exists. Throughout the development of Angular 2 the team also talked with the
developers of other frameworks, libraries and tools, which shows that they
believe in the community more than trying to push their own agenda.

------
jwineman
Interesting he omits Flow from his very carefully chosen "Typescript won"
arguments.

~~~
spankalee
Does anyone actually use Flow? I see TypeScript all over the place.

~~~
k__
I do, in production. But yeah, it seems Flow needs more marketing.

TypeScript seems to be rather big for MS. But FB mostly pumps money in Babel
and React at the moment...

------
gkilmain
What have they won? Why all of the f'ing if you choose A you're awesome if you
choose B you've lost? Articles like this give me anxiety.

~~~
corysama
The article presents measurements indicating that Typescript has won greater
mindshare compared to similar JavaScript transpilers.

~~~
gkilmain
TypeScript is a transpiler + type checker. If you just need a transpiler the
author makes no recommendation between Babel and TypeScript

------
superskierpat
On the topic of typescript vs purescript and similar projects, I believe these
projects are more for people who want to stay in the same mindset across the
whole stack. So haskell with ghjs or purescript and scala with scalajs... I
dont think they are really in competition with typescript.

~~~
benjaminjackman
This reflects my use case. I was just writing Scala code that compiles to both
the JVM and JS. The requirements for the code in terms of performance for the
JVM side are very intense which ruled out using Typescript there. I am using
the browser for visualizations / UI where I have used Typescript in the past,
between using Vanilla Javascript and then Coffeescript and before Scala.js was
available.

I continue to watch Typescript because I think it has its place and certainly
is worth knowing / using in certain projects. I really appreciate the
.d.ts/DefinitelyTyped (files which provide Typescript static types for
javascript libraries) that are available, I am able to mostly convert them to
ScalaJS facades programatically which gives me nice code complete in ScalaJS.

One area I think Typescript outshines ScalaJS is if you have a large existing
Javascript codebase, or are a Javascript programmer looking to _incrementally_
improve your codebase / language knowledge Typescript is the best _step_ in
that direction.

However if you are going `full stack`, with high performance requirements on
one side, and a browser on the other, right now I think Scala is the best
option. That opinion might change in the future with web-assembly (then
perhaps back again e.g. scala.native ).

------
yesimahuman
No need to say TypeScript "won," we're all pushing JS forward and TS is just
another tool in the toolbox. However, I'm glad to see it doing well especially
since it felt like a big risk for us at Ionic to pick TypeScript (along with
ng2). I've been happy with how positively received TS has been, which has been
a bit of a surprise to me, honestly.

------
LukeB_UK
I think the end result is actually that JavaScript wins. If it turns out that
a lot of people think that JavaScript needs a type system, one will be
proposed and rolled into the language.

------
tptacek
Is Typescript/Babel an either/or choice?

ES6 is non-negotiable. I understand the basic premise behind Typescript. Would
I "switch" from Babel to Typescript and get arrow functions and string
interpolation through Typescript somehow?

~~~
eloisant
Yes, because Typescripts is 2 things:

* A language, superset of ES6 that adds optional types

* A compiler (like Babel) that will take your Typescript code, check if the types are correct, remove them, and transpile the non-ES5 parts of into ES5 (just like Babel).

So if you want to use Typescript-the-langage, you need Typescript-the-compiler
and you will no longer need Babel.

~~~
thejameskyle
Many people choose to use both. TypeScript for type-checking and stripping
types, and Babel for compiling down ES2015 code. Babel follows the spec for
that much closer than TypeScript does and has hundreds of plugins that allow
you to do even more.

------
drinchev
Wow this is such a strong title. There's no winning. Use the right tool for
the right job.

Although every big project I take these days I prefer to write in TypeScript,
I would honestly not use it if I have a small static landing page with an AJAX
ticker or something. It would be overkill.

------
davidhyde
TypeScript on JavaScript is like c# on CIL (.net common intermediate
language). You are free to modernize the language as much as you want without
breaking backwards compatibility. Not surprising Anders Hejlsberg is heavily
involved in both. Great language.

------
PSeitz
Once ES6 is widely supported, and a transpiler is not necessary anymore,
people will switch to pure ES6.

------
JustSomeNobody
I hate these stupid "X Won" posts.

------
rhinoceraptor
Or it could be that Babel downloads are declining because it's becoming less
necessary as Node and the major browsers implement ES6.

The whole point of Babel is to be a stopgap, so it's not surprising that its
usage is declining. Babel is not a language.

------
Touche
Weird comparisons. People who like Elm aren't going to switch to TypeScript
because it's more popular. They are fundamental disagreements that can't be
dismissed with a Google Trend chart.

TypeScript is currently popular but popularity in JavaScript never last long.
The cycle is:

* A library that comes out that solves a problem with the previous iteration.

* The new popular library has some different problem but people ignore it because the new cool thing is still fresh in their minds.

* People become annoyed with the popular library and someone makes a new library that fixes the problem with the popular library. It looks a lot like the original library that popular library replaced.

* Cycle repeats itself.

~~~
nathancahill
The difference is that Typescript isn't someone's side project where they
accidentally typed `npm publish` when they should have typed `rm -r ./`

It's backed by M$ and the Github repo is super active, especially in langauge
proposals. This will be around for a while.

~~~
Touche
Sure and Traceur was backed by Google but that didn't stop it from losing the
hype train to Babel (which _was_ someone's side project).

The JavaScript hype cycle has no escape hatch. All that go up, must come down.
Some things just last a little longer than others.

~~~
nathancahill
> Backed by Google

Exactly the problem. Like all other Google projects, they bailed on it.

~~~
Touche
No they didn't, it's still under active development, last release 4 days ago.

Ditto for Closure which is actively developed (and is among the best libraries
in ES6 features) but also lost the hype cycle to Uglify.

~~~
nathancahill
Uglify? Webpack would have been the better comparison if we're talking
straight hype factor.

~~~
Touche
You must be young. There was a time when Closure was the most used library for
minification. Before that it was the YUI Compressor. Anyways, Node came out
and Uglify worked with Node and Closure didn't and even though Closure had
some benefits like dead code elimination (which was eventually added to Uglify
but not sure if as good or not - regardless it wasn't there at first) Uglify
still won out.

------
kowdermeister
If I absolutely must choose a "winner" (what does that even mean?) then I
would give the golden medal to the one that has a standard behind it.

I think it's a very pointless thing to pick a winner. It's not a popularity
contest. You will be able to tell that some technology is "lost" or is over,
when the popularity will be declined to the 0.0.1 alpha release state.

~~~
nathancahill
The standard doesn't keep up fast enough with the pace of development in the
JS ecosystem. That's why Babel's plugin architecture is so great. It allows
super fast paced experimentation with new language features, without having to
get buy-in from browser vendors or even JS family languages.

~~~
kowdermeister
That's true and experimentation is good thing, just look at CoffeeScript,
although I never liked it.

However I always bet on technologies that are standardized rather than
maintained by a company. Not a fail safe approach, I know, but that's the way
I minimize risk.

------
quangv
Doesn't matter, it maybe more popular, but it no one died.

[http://zenoverflow.com/2016/04/27/platform-of-the-
browser/](http://zenoverflow.com/2016/04/27/platform-of-the-browser/) \- my
response to TypeScript Winning

------
shrugger
I love the piegonhole arguments that always 'exclude' Dart from these types of
discussions.

Class-based vs prototype-based, classes will always win. JS is terrible,
TypeScript is only very slightly better.

Dart's core team is absolutely world class, and the language is already highly
capable.

~~~
nathancahill
JS has classes.

~~~
shrugger
JS has a syntactic sugar keyword class. Objects are still prototypes.

------
noahlt
What about Flow?

------
untog
Choosing a winner based on Google Trends?

Hmm.

Pointing out that CoffeeScript is on the decline because Google Trends for it
once peaked and has since declined?

Hmm.

Failing to consider that TypeScript might be at a similar peak and is due a
similar decline?

Hmm.

~~~
nathancahill
Posting pointless comments?

Hmm.

~~~
untog
What exactly is pointless about what I said? The article presents no good data
to back up its assertion, and even raises a potential issue then doesn't
address it.

------
gcb0
... won the disposable syntax sugar of the month.

next month people will want memory protection in JavaScript and JavaScript
developers being JavaScript developers will create a new project from scratch
with new syntax, just like Babel did from coffee and like typescript did from
Babel.

meh.

this is all needed because you have a team that doesn't know how to agree on
coding style or something. yes, it would be nice to have type errors detected
before runtime. but we have responsive devs so we never had those errors to
begin with. and we're way past 80k lines. adding a transpiler would be more
annoying than helpful.

~~~
woah
Babel is a program which compiles a newer version of JS into an older version,
so that you can use the new version on platforms that don't support it yet. I
can't tell if you're aware of what it is.

------
draw_down
I'll keep writing in the language it compiles down to. Which would be
JavaScript, of course. But keep telling yourselves that if you must...

------
coroutines
TypeScript "won" because certain folks will happily trade some coherency for
more complexity.

Types (can) be helpful.

------
intrasight
JavaScript as an intermediate language is a fail, therefore TypeScript is a
fail.

------
deforciant
javascript and "win" must not be in the same sentence

~~~
bazqux2
except that one

------
hiou
If you like typescript so much you might as well stop pretending you write
JavaScript and just write in C# like you really want to.

[http://bridge.net](http://bridge.net)

If typescript was simply type safety that would be one thing. It's definitely
a lot, lot more than that.

Typescript is to .NET as Coffeescript was to Ruby. A bunch of developers who
didn't know JavaScript and wanted to find the closest thing they could to what
they already knew. And who really uses Coffeescript anymore? Stick with esnext
to babel and the bright future JavaScript has ahead.

~~~
coroutines
I say again: Javascript can learn many things more from Coffeescript.

Coffeescript's future is diminished, presently (hah) - but ES6 only picked up
a handful of magical features.

