
I Was Wrong About TypeScript - Tx3
https://www.triplet.fi/blog/i-was-wrong-about-typescript-here-is-why/
======
joostdevries
With the arrival of TS 2.0 this month (hopefully) we'll have some cool
features: a union types [1] b type guards to work with them [1] c nonullable
types [2]

[1] [https://www.typescriptlang.org/docs/handbook/advanced-
types....](https://www.typescriptlang.org/docs/handbook/advanced-types.html)
[2]
[https://github.com/Microsoft/TypeScript/pull/7140](https://github.com/Microsoft/TypeScript/pull/7140)

As a Scala developer I like Typescript a lot. Which is a first for me in
browser development.

But I'm not so fond of webpack et al. So I created a sbt-typescript plugin.
And now I have incremental compilation of NG2 - Play apps for both the browser
side and the server side. In a single build definition. It's a nice
experience.

~~~
virtualwhys
> As a Scala developer

Interesting, choosing TypeScript over Scala.js; what does TS offer vs. working
directly in Scala across the board?

~~~
choward
I think the biggest advantage is that typescript emits code that is good
JavaScript. This means if I decide to stop using typescript, I can just use
the generated JavaScript. It also means that there transpiled file is smaller.
Using scala.js for a small project wouldn't make sense if you cared about file
size at all. It could be worth it more as your project grows, but your then
you are that much more commited. There's no exit strategy like with
typescript.

~~~
intrasight
I remember hearing the same argument in the early 80s for the benefit of C vs
Assembly. And it actually was a good argument. A lot of people, myself
included, learned "real programming" (ie assembly) by using C as training
wheels. But a funny thing happened on the way to the forum - C became real
programming and nobody remembered or learned assembly - myself included. Then
the same thing happened ten years later with the transition from C to C++.

~~~
choward
So it sounds like everything worked out.

~~~
intrasight
It did, and it will. My point is that just like with these "legacy" languages,
the next generation of TypeScript developers are no more likely to "drop down
into JavaScript" as a C developer is to "drop down into assembly". So our
development tools and debuggers must be really solid at the language level
that we code in. And just like I skipped the "transpiling" phase of C++, I'll
probably skip the transpiling phase of TypeScript, and wait for the tooling
and runtime to be more mature.

~~~
CJefferson
The advantage is it gives you an escape route if Typescript ends up dying. I
worked on a project that had to do a giant dead language -> Java conversion,
and it was extremely painful.

------
dandare
I find it funny - the first language I learned was ActionScript 3 (built on
ECMA 4 proposal) and I become a Flash developer aka laughing stock. I remember
I had very rough time transitioning to JavaScript because it felt like a stone
age compared to ActionScript 3. Then came TS and saved me and dare I say the
whole web.

~~~
pygy_
Did you know that Microsoft was part of the cabal against ES4, proposing a
competing and very modest ES3.1 which became ES5?

~~~
int_19h
MS was on both sides of it. Remember JS.NET? It was veey ES4'ish (for early
definitions of ES4, anyway).

~~~
pygy_
No, I didn't know about it...

Still, the hostility from the "against" side (which also included Yahoo and a
pre-Chrome Google) was enough to derail the effort.

------
burai
Another good alternative is Facebook's flow. Rather than being a transpired
language it works on top of JavaScript files.

This two tools are amazing and it improves working with JavaScript to the
point of never wanting to go back to not typed JavaScript

~~~
hiphipjorge
Well, you still need some transpiling in order to remove the Flow type
signatures. In practice, they end up being pretty similar in terms of needing
a build step.

~~~
TAForObvReasons
You can embed the type information in special JS comments that the checker
understands: [http://flowtype.org/blog/2015/02/20/Flow-
Comments.html](http://flowtype.org/blog/2015/02/20/Flow-Comments.html)

Your existing minification step will remove the comments. But even if you
don't remove the comments the code will still run.

------
azurelogic
I recently started learning TS after reading a previous HN post on it
([https://medium.com/@basarat/typescript-
won-a4e0dfde4b08](https://medium.com/@basarat/typescript-won-a4e0dfde4b08))
and listening to the JS Jabber episode with Anders Hejlsberg himself
explaining the benefits ([https://devchat.tv/js-jabber/209-jsj-typescript-
with-anders-...](https://devchat.tv/js-jabber/209-jsj-typescript-with-anders-
hejlsberg)). These two (plus knowing that Angular 2.0 is going to be much
easier with TX) totally sold me on learning it. I'm in the middle of this
Pluralsight course: [https://app.pluralsight.com/library/courses/typescript-
in-de...](https://app.pluralsight.com/library/courses/typescript-in-
depth/table-of-contents). Besides the benefits of TS, I'm learning how perfect
VS Code is for writing it. I've been a big proponent of WebStorm in the past,
but VS Code is really shining for this type of work.

~~~
Tx3
About the text editor: I think all editors use the same TypeScript compiler
APIs. That would mean that you would get pretty much same suggestions, error
lists, etc. Correct me if I am wrong. VS Code could have some other API calls
or project file support.

JS Jabber episode was great! Full of great insights.

~~~
evmar
I use TypeScript from both Emacs and VSCode, depending on my mood. They do
both use the same underlying compiler API, but the VSCode support is more
pleasant in how it's surfaced in the editor: ctl-click on a variable to jump
to its definition, f2 to rename the variable under the cursor, or ctl-T to
open a query field to jump to a symbol.

Emacs is capable of all of these things (because Emacs is capable of anything)
but it doesn't work that way out of the box nor is there an already-written
package around that makes that easy. To rename you type M-x tide-rename-symbol
and it's inconvenient enough that I forget to use it.

~~~
jasonm23
So bind f2 to tide-rename-symbol in the mode map.

And throw the bind into your .emacs

------
bdcravens
Ashamedly at one point I was on the anti-Angular 2 bandwagon due to
Typescript, because Microsoft. When I started learning Angular 2 myself I've
found I actually enjoyed working with Typescript, for many reasons.
(confidence that my code wasn't a ball of mystery before it ran, using inline
templates, succinctness of annotations, etc)

At the same time, you're gonna need to use some preexisting libraries, and run
into the issue of not having types available. (though they do exist for most
mainstream libs) However, I found creating types for any given lib pretty
flexible, and that you can usually get away with just enough types.

~~~
daxfohl
Ha, I'm on the anti-Angular2 bandwagon due to Angular1. I use React and
Typescript and love it. Curious if you've tried React. Or Angular1

(TBH Angular1 was pretty great at the time, but after React I look back at
those monstrous template files, ng-everything, plugins and workarounds, and
only the bad memories surface).

~~~
ENGNR
Angular blew a loooooot of my trust in Google, who in the past always put out
the highest quality stuff. I built an entire app in the damn thing only to
realize as it got bigger that it wouldn't scale. Sure you can use less HTML
templates, but that's the whole point so that it's easier for designers to
approach / fix.

Sure I should have checked it out but the documentation didn't exactly
highlight it (at the time anyway), and with the services, controllers,
testability, etc it just looked like they'd thought it all through.

Frankly after finding React there's no way I'm giving NG2 even a look in.

~~~
teen
o.O i love angular 1. and probably would like 2 as well, havent started any
new major projects lately though

~~~
dragonshed
+1

In the last 4 months I've built a large angular1.5 app in ES5 using the new
component facade and d3.js, and it's been pretty smooth.

------
lloyd-christmas
> I have written tests in TypeScript, compiled to JavaScript, and then used
> Mocha, for example, to run tests. I would like to hear your thoughts on
> this.

We use ts-node to run our mocha tests without ever compiling:
[https://github.com/TypeStrong/ts-node](https://github.com/TypeStrong/ts-node)

~~~
camwest
ts-node has some issues with source maps unfortunately. When your project gets
big enough you might want to move back to ts->js then running mocha.

~~~
lloyd-christmas
Mind being a bit more specific with "has some issues"? Our project isn't
exactly small, and we haven't bumped into a problem yet. I'd really like to
know what to expect if something is about to jump out from behind a wall.

------
gmac
As something of a side note on this post, suggesting there is a single
'Dart/CoffeeScript route' that languages can take seems a bit misleading.

Dart is a whole different language that happens to be transpilable to JS.
CoffeeScript is just a dash of syntactic sugar that (IMHO) makes JS a whole
lot less tedious to write ('The golden rule of CoffeeScript is: "It's just
JavaScript"').

Notwithstanding that, I am keen to try using TypeScript on a new project one
of these days.

~~~
Tx3
Good point! I used similar categorising as Anders Hejlberg used in the
JavaScript Jabber podcast ([https://devchat.tv/js-jabber/209-jsj-typescript-
with-anders-...](https://devchat.tv/js-jabber/209-jsj-typescript-with-anders-
hejlsberg)). For those who don't like audio, he basically referred TypeScript
being superset of JavaScript, unlike some other languages.

~~~
k__
Somehow I can't stand listening to Hejlberg.

Often it feels like the CS professors I met at university, who wanted to teach
you about "real programming languages and not such toys like JavaScript"

~~~
johnny_reilly
I can't go with that. Anders H is one of the most avuncular, helpful and
accessible voices out there. Oh and his very verbs twinkle!

~~~
k__
Well, I just saw a talk about TypeScript 2 and it felt to me that he was
belittling JavaScript.

~~~
wereHamster
If you've ever worked with a strongly typed language you can't but belittle
JavaScript ;)

~~~
k__
I worked with C++, Java and Scala, and all felt really unwieldy.

------
stevehiehn
Last week was my first week trying out Angular2 + TypeScript. I use mostly
Java & C# at my day job. I was actually a really shocked at how fast i was
able to gain a working knowledge of TypeScript. The only thing i don't like is
my project has extra files everywhere (.js + .ts). However there is probably a
way to make my IDE hide them or something.

~~~
robwormald
I'd suggest using the --outDir option, so TS writes the .js files to a
different directory which you can easily blow away.

~~~
Tx3
Rob is exactly right that you should use --outDir

You should aim for deployment process where outDir would be in .gitignore and
building of the JS files would happen on a build server.

~~~
rymohr
If you use --outDir, wouldn't the .js files that import the transpiled .ts
files need to point to outDir instead?

This is the kind of stuff that makes the "incremental" adoption argument hard
for me to swallow. If I can't rewrite a .js file to .ts without any further
ripple effects within the project, then it's not truly incremental.

I wrestled with this stuff last week and ultimately ended up going with flow
since it gave me type checking _and_ incremental adoption, without
complicating my existing babel/webpack stack.

~~~
DanRosenwasser
Hey, I work on the TypeScript team. I hope you'll reconsider, and maybe you
can fill me in on the issues you ran into.

Your .js files should typically be relative to each other, so unless you're
using absolute paths (which you usually shouldn't!), this hasn't been a
problem for other users. Is there something that I'm missing?

~~~
rymohr
Hey Dan, thanks for responding. I think the key point you may be missing (or
perhaps I missed a flag somewhere) is that I want relative requires but I
don't want the intermediate js and sourcemap files cluttering up my project
(and assuming I have an existing babel/webpack stack I'm happy with -- I just
want the type checking).

I want the ability to convert any existing js file within the project to ts
without having to touch a single other source file. I also want the type
checker to assume that if I don't have a type definition for a package, that I
don't want the use of that package to be type checked (without being forced to
rewrite my ES6 imports to commonjs).

I was able to do this with flow but not typescript.

Is there something I'm missing?

~~~
DanRosenwasser
Hey rhymohr, I think I see what you mean. If you're already using something
like Babel & Webpack, it should just be a matter of using a TypeScript loader
like ts-loader[1] or awesome-typescript-loader[2]. TypeScript should just fit
into that build step.

Let me know how that ends up working out!

[1]: [https://github.com/TypeStrong/ts-
loader](https://github.com/TypeStrong/ts-loader) [2]:
[https://github.com/s-panferov/awesome-typescript-
loader](https://github.com/s-panferov/awesome-typescript-loader)

------
kkirsche
Having avoided typescript thus far, I really appreciated this take. Thank you
for sharing it!

~~~
Tx3
I am pleased to hear! One of the goals of the blog post was to convince people
to give a second thought for the great tool.

~~~
johnny_reilly
It is fantastic - so glad you posted. On the transpilation thing; Babel still
has a total use case. TypeScript doesn't provide es6 APIs such as Map /
Promise / Array.find etc I output es6 from my TypeScript and pipe that into
Babel to get the new APIs and to do transpilation. Works great. (There's a
number of ways to do it; I use WebPack with ts-loader and babel-loader which
rocks.)

------
venuzr
Are there any patterns / recommended practices for unit testing Typescript. I
recently joined a project which uses Angular1 + Typescript and had to
introduce unit testing to the code base and it has been painful. A lot of
backend API calls (wrapped in services) are being (chained and) invoked in the
constructor. Any initialization is being squashed into the constructor. This
makes setup of karma tests extremely painful/brittle without a complete
refactor for each component. However wrapping initialization code in public
methods feel strange to me. Any suggestions?

~~~
jestar_jokin
I don't know exactly what your code looks like, but a major reason for using
Dependency Injection, like AngularJS does, is to allow your tests to "mock"
the injected services. Then, you verify the behaviour (but not the
implementation), by checking that each mock is invoked with the expected
arguments, and set it to return a particular value.

On the server side, I've used TypeMoq, which is pretty nice. I have only used
it to mock imported modules; for AngularJS 1, you'd need to invoke the
"inject" service, to insert your mocks into the controller.

Further reading:

[https://en.wikipedia.org/wiki/Mock_object](https://en.wikipedia.org/wiki/Mock_object)

------
Waterluvian
I just can't justify writing my team's code base in typescript. I don't want
to make that move, setting us down a very specific path. I don't want to add
another layer of training to develop on our codebase, but mainly, I just don't
have the confidence that it's a right or wrong choice, and its a big choice.

But I get a sense that it would be great to try for smaller, disposable
projects as that's limited risk.

Does anyone else struggle with TypeScript simply because of how big a choice
it can be?

~~~
mikerichards
I wrote in a previous post that I enjoy working with Typescript and overall
it's a win for our team, but these days I sometimes wonder how much of a win
over es6/7.

I've found the biggest headache is getting all the *.d.ts files setup right
and setting up your own types can sometimes be a pain, but as I mentioned it's
pretty opt-in.

~~~
wereHamster
You don't use TS because of the ES6 features. If that's your goal then you can
simply stick with babel. You use TS because of the type checker, and that will
not be part of ES6/7.

------
jcsnv
Anyone have feedback on using Flow vs TypeScript?

~~~
dmnd
I'm also interested in this question.

Here's two things I saw on Jeff Morrison's (Flow author) Twitter:

* [http://djcordhose.github.io/flow-vs-typescript/2016_hhjs.htm...](http://djcordhose.github.io/flow-vs-typescript/2016_hhjs.html)

* [https://gist.github.com/jeffmo/ef9214ca3acfe76c54a237b5710d3...](https://gist.github.com/jeffmo/ef9214ca3acfe76c54a237b5710d37be)

~~~
danielearwicker
Interesting last line in that presentation:

"Flow written in OCaml, Typescript in Typescript"

------
Pxtl
> Web Forms abstracted away the core technologies of the Web with mixed
> results

Understatement of the century.

~~~
Tx3
Hey, I just tried to be polite.. but yes, you're absolutely right,
understatement of the century!

------
jondubois
I'm not a huge fan of TypeScript (though I will admit that it's way more
useful than CoffeeScript). My main issues with it are that: 1. The type
definition files tend to get out of date. 2. The build step is time consuming
for large apps. 3. It adds complexity to your app and opens it up to new kinds
of errors (particularly during setup, different typescript versions...).

I prefer using plain JavaScript - When I need to find a definition for a
function, I just do a text search for it in my IDE. Text search isn't as nice
as intellisense for beginners but you get used to it pretty quickly and it's
actually pretty efficient once you do.

I also like to read through the code a bit before using a function written by
someone else, I find that just knowing the interface is often not enough -
Often you want to know how specific edge cases are handled and it encourages
you to fix bugs in other people's code instead of thinking "This class doesn't
work, it's not my problem - I'll just hack a solution to work around it".

------
235337
I signed up just to tell you that a slam dunk is not an easy shot. Its when
the player jumps up and places "slams" the ball in the net rather then taking
the shot from a distance. Its A) hard to get that close unobstructed and B)
for most people hard to actually jump that high. Its almost a boastful move of
skill to slam dunk the ball.

I'm actually no a sports person....

------
StephenCleary
I still use Babel _with_ TypeScript.

This gives me the benefit of TS (specifically, typing), on my preferred
development machine (Windows, where FB Flow is really crappy), while getting
language-level polyfills (like generators) from Babel.

A nice side effect of having TS "compile" to ES6 modules is that Babel's nice-
module-loading is used, which means I can just "import _ from 'lodash'" and
never have to mess around with "* as" and the _endless_ manipulation of .d.ts
files.

That said, there are still things missing. In particular, object spread
support, which is _so_ nice when using Redux.

I've thought about maybe doing a Babel precompile, followed by TS for typing,
then a Babel "real compile", but that's probably just crazy.

------
k__
The thing with 3rd party libs is, often there are no type defs, especially
bleeding edge stuff :/

Also VSC often is flunky with picking up defs... sometimes you open a file and
some are missing.

Or imports with numbers don't work.

On the other hand, using big libs like babylonjs is charming with all the auto
complete :)

~~~
solomatov
It's not a problem. You can resort to any type and works with 3rd party stuff
like with normal JS code.

~~~
k__
Yes, I can write my own types, but typing isn't always easy. Especially with
advanced techniques like parametric polymorphism etc.

~~~
calebegg
No, I think solomatov is saying you can always use the 'any' type built-in to
TypeScript. You can always do:

    
    
        declare var fancyNewLib: any;
    
        fancyNewLib('hello');
        fancyNewLib.someCoolFeature = 3;
    

You don't get any suggestions or typechecking (obviously), but you're no worse
off than just using JS in that sense. And you can easily replace your
'declare' with the actual // <reference> tag when you find it or make it, and
clean up any errors.

~~~
k__
Ah, yes, that's what I'm doing most of the time. But like you said it's no
better than using JS directly, haha.

~~~
solomatov
Actually, it's better. If the core of your application has non trivial
business logic, it's a good idea to write it in typed way and write ui and
other support stuff with partially typed code.

~~~
k__
Fair enough and I think with strict null type checking, where null/undefined
isn't part of any anymore things would still get much better than with plain
JS.

------
Dr_tldr
It seems like people are trying to use types as a substitute for tests and a
way to protect themselves from unintended mutations.

But if you write tests already and use immutable data structures, what
benefits does TS bring to people whose background isn't in strongly typed
languages?

~~~
jestar_jokin
\- Documentation. You don't need to have free-text comments saying "@param
myArg must be a string", you can just look at the type signature, and
immediately know how to use a function. Attempting to pass in a number will
fail at the time of writing, not at runtime (of your test). This is a _huge_
benefit when using third party libraries. For a JS lib, you need to read the
documentation, and if something is undocumented you need access to the source
code and the time to analyse it, to understand exactly how to use the lib.
Compare this to making the type interface available.

\- It's easier for a machine to read, which means the possibility for better
tooling. e.g. linters and checkers, automatic refactoring.

\- It's actually faster to write, due to the ease of making changes. If you
move a function out to a new module, the compiler will immediately tell you
all of the invocation sites that are now broken. (If you rely on tests, you
have to make sure you have tests in _every_ invoking module, rather than just
the module you are actually changing. [Ignoring mocking issues...])

~~~
Dr_tldr
I'm not so sure about the "faster to write" since my IDE and linting will
already take care of that. The java-style boilerplate is a huge turnoff for
me, and the validation seems to produce false negatives so often as to
actually introduce more bugs. Ie, If a variable gets mutated without changing
type, TS is now worse than useless for validation.

The self-documenting part is the strongest argument I've heard, but writing
real documentation and real tests still seems better.

~~~
jestar_jokin
An IDE can assist you even better when it can understand the code you're
writing. For example, autocomplete "myString.re" without type hints, and an
IDE like IntelliJ might suggest the method "reject()" (which is found on a
Promise interface), or "remove()" (which is found on a DB entity interface),
as well as "replace()" (which is found on a String interface). Wouldn't it be
nice for it to always pick the right option?

TypeScript doesn't help with immutability at all. For that, you should look at
something like PureScript. (Or GHCJS, or any other compile-to-JS languages
that support immutability.) TypeScript assumes you are sticking with
JavaScript's semantics, mutability and all. If you want immutability, you
still need to use "Object.freeze()". Variable mutation is not something picked
up by types alone.

There are other languages that introduce "dependent types", which can actually
include values in their type signatures, which might be able to specify
something like you want; i.e. "a function that accepts an argument of type 'a'
which derives a number, and returns the same type 'a', but the returned value
must be equal to the input value plus 10".

Documentation is nice... or so I've heard! Speaking for myself, developers are
lazy and just want to write code. Why not make them document the code as they
write it? Plus, external documentation (even as JavaDoc-style comments) always
falls out of date with the code.

I think better than tests, is to enforce "design by contract" \- assert your
preconditions and postconditions on every function. This inlines your
assumptions and behaviour verification with the actual code to be run. (If
performance is a concern, you can implement this in a way that allows you to
disable assertions.)

In general, the more guarantees you can enforce at compile time (such as only
accepting certain types of values, or that input values are never mutated in
place), the less need there is for having twice as much testing code as
application code.

------
Scarbutt
By the title I though he was going to talk more about the language but it was
95% about tooling.

~~~
tacos
That's because there's not much language to talk about. Which is sort of the
point--and 95% of the elegance.

------
likeclockwork
All the TypeScript fervor kind of passes me by because I simply don't want to
structure my work around classes and 'ideal TypeScript' that I've seen looks a
lot like Java or another class-oriented language.

~~~
WorldMaker
Typescript is still extremely useful even if you are writing more functional
code. There is no "ideal Typescript", TS is still ES underneath and just about
all the ES paradigms including high functional code are still available in TS
and benefit from typing information. (The possible exception being that TS is
not entirely great at some of the more complex prototype-oriented paradigms,
but even that has gotten significantly better in TS >= 1.8 with support for
things like intersection types.)

------
kyriakos
Been using typescript since its introduction. It really helped me improve my
JavaScript code quality and most importantly it's really good at keeping large
projects tidy and easy to comprehend.

~~~
Tx3
It would be interesting to hear more about your experiences. I have been quite
hesitant to use more advanced TypeScript features and stayed on a type system
related annotations.

~~~
mikerichards
Interestingly enough, the Typescript compiler team doesn't even use classes.
If you want, you pretty much write just functional code.

------
josdejong
Thanks for your story. Funny thing is, just yesterday I wrote a similar
article about static typing but from a different angle, see:
[http://josdejong.com/blog/2016/06/05/static-typing-the-
good-...](http://josdejong.com/blog/2016/06/05/static-typing-the-good-parts/)

------
chrisan
I see a lot of Angular comments, has anyone had good/bad experiences with
TypeScript and React?

~~~
mikerichards
From a React newbies's perspective, the React community is much more in the
es6 camp than Typescript. Many of the starter kits are in es6. It's not a huge
deal.

I actually write most of my front-end code these days in Aurelia, which is
written in es6, but they actually have type annotations which Babel knows how
to deal with. So basically the tooling can auto-generate the *.d.ts files for
you.

That said, Typescript natively supports React syntax through TSX files, which
is nice.

~~~
batuhanicoz
Shameless plug: When we've started switching to TypeScript and was looking for
a good starter, we've couldn't find any that we've liked so we've created &
open sourced our own. Maybe it can help people who are considering using
TypeScript with React:
[https://github.com/barbar/vortigern](https://github.com/barbar/vortigern)

~~~
DanRosenwasser
We also have an official doc on getting started with TypeScript, React, and
Webpack if anyone's interested:
[https://www.typescriptlang.org/docs/handbook/react-&-webpack...](https://www.typescriptlang.org/docs/handbook/react-&-webpack.html)

------
joshschreuder
Does anyone have a good tutorial on migrating existing JS codebases to TS?

Talking specifically Angular 1 if you have one, otherwise a general tutorial
is fine.

I'm interested in whether it is worth the effort migrating a pretty large
frontend codebase.

~~~
jestar_jokin
I did this on my current project. Basically:

\- Set up your TypeScript config

\- Set up Typings (or some other type def manager)

\- Rename all ".js" files to ".ts"

\- Replace all "var x = require()" calls to "import x = require()"

\- Gradually refactor components (controllers, directives, services) to
classes, or at least add type annotations to everything.

Because TypeScript is a superset of JavaScript, you can work on an untyped
system and add gradual typing until the codebase starts looking nicer. Any new
functionality can be implemented in TypeScript; any existing functionality can
be slowly refactored when it is touched by changes.

~~~
whatever_dude
I'd add tslint to that once the basic migration is done. It can get a lot of
issues in the code that are either bad stylistic options, or things that can
produce errors in the future.

------
ryancmartin1976
I don't see any reason to use TypeScript over Babel. I'm a big supporter of
Microsoft technologies, especially since I started out my career developing
web applications in the late 90's with Classic ASP. Then adopting .NET in 2000
and working in that space solely until 2011 at which point I jumped shipped
over to the isomorphic JavaScript world of Node.js and Angular.

Over the past few years I've really taken to Node.js and Angular and when the
Angular team told the world it choose TypeScript as its main language of
choice to build out the new version of Angular 2.0, I had to seriously
consider adopting it as well for Angular development going forward. If it's
good enough for the Google team to use for Angular 2.0 then it should be good
enough for me to use as well. Then during my research into the technology I
ran across Babel.

After spending decent amount of time reading up on blog posts defending,
promoting or choosing one of the two technologies over the other and alert
spending countless hours building applications with each of them in order to
get a real good understanding on how each feels to work with. I came to the
conclusion that Babel is the only library I need to use on all of my projects
and for good reason.

Babel provides the development world a tool that allows them the ability to
use tomorrow's features and tools today and within mostly ever browser that's
in use in some form commercially or professionally. Having the ability to use
features in future ECMAScript standards planned for down the road today, makes
perfect sense for me to use today if there will not be any side effects to
doing so.

These features help me write less code, cleaner code and more robust code,
just by using a library that handles all of the heavy work behind the scenes
when it's time to transpile all of my futuristic code into today's boring
standard for browser consumption.

Yes TypeScript can provide the end user a large portion of the features and
functionality I am referring to with the Babel library but Babel provides the
end user a lot more than TypeScript can and it will always be able to provide
that and more going into the future as well.

------
wigam
The lack of multiple type definitions for some libraries discouraged me at
first. I'll give it a go in the next huge JS project I have.

------
daxfohl
I just wish TS was based on CoffeeScript.

~~~
kodablah
I've often thought about a CoffeeScript variant with optional typing that
transpiled to TS. The types would be ascribed via a backslash, e.g.
`(hello\string) -> hello + ' world'`. But considering the huge benefit of TS
is the tooling such as intellisence, I doubt it's worth the effort to start a
whole separate ecosystem.

~~~
daxfohl
I envisioned it somewhat the opposite way. Gradual types _a-la_ TS tacked onto
CoffeeScript. No _actual_ TS integration per-se.

Though even better would be if the TS team could figure out a way to factor
out the type inference logic so that it could be applied just as simply to
CoffeeScript as to Javascript, and even allow definitelytyped defs and perhaps
intellisense logic to be reused everywhere.

Roslyn does this somewhat for C# and VB, so it might not be too big of a jump.

------
fiatjaf
How much memory does the compiler use?

~~~
chadcmulligan
seriously? what does it matter? I run it on a 8GB VM with VS and never noticed
an issue.

~~~
fiatjaf
It doesn't matter to you, I understand that.

------
gabssnake
It seems the whole argument is for better tooling in Javascript... why the new
language?

------
mikerichards
At the high risk of starting a huge flamewar, I think the benefits of static-
typing have won in a way.

I've been using Typescript exclusively as my transpiled language for about a
little over a year now. The benefits of intellisense/code-completion and
refactoring because of static types can't be underestimated, especially in
large apps.

That said, I actually like the opt-in nature of Typescript. There's some parts
of code I don't feel like I need to define an interface for. It's just not
worth it.

Typescript is turning out to be quite a powerful little language...maybe
approaching the point of quite a bit of complexity, but all in-all it's pretty
much been a win for my development efforts.

------
zxcvcxz
I prefer frameworks that focus on pure javascript because the ones that don't
tend to allow you too use javascript but have sparse documentation on how to
use it effectively, instead focusing on typescript. When I first tried Angular
2 their javascript "hello world" example wouldn't even work, it was some bug
in their site. I already need to use all sorts of other tools and abstraction
layers when building websites/apps, typescript feels like just another
abstraction layer (which it is), that means another vim plugin for typescript
(or a bloated IDE), another npm dev dependency, another layer to the build
process, so I try to avoid it for these reasons.

~~~
Tx3
3rd party libraries / frameworks written with non-JavaScript languages is
worth another blog post and discussion. I agree completely with you that
libraries / -most- frameworks should be written in plain old JS.

The reason is simple, contributing and reading the project source code should
not start by learning a programming language. It is a different scenario when
a team in a company has decided to learn and write their project with
TypeScript/CoffeeScript/etc. language.

About tooling, I think writing modern JavaScript (ES2015, ES2016) is
beneficial and therefore, you need a tool like Babel. When you go to that
path, why not use TypeScript instead and get ES2015/ES2016 + type system +
great compiler?

~~~
shados
(this won't be quite true after TS 2.0, but..) TypeScript doesn't support
everything ES6 or even everything Babel does, and some of the stuff it does
support are not matching the standard, in subtle ways. Then you're missing out
on the Babel plugin ecosystem. You can use TS and Babel together for SOME of
that (but not all of it, syntax parser and all).

It may still be a slam dunk to you, but it's not as "obvious" an answer as you
make it sound.

------
LionessLover
"Introduction to TypeScript" by MicroSoft - a free (untimed) course

[https://www.edx.org/course/introduction-typescript-
microsoft...](https://www.edx.org/course/introduction-typescript-microsoft-
dev201x-1)

------
smegel
[http://walkercoderanger.com/blog/2014/02/javascript-
minefiel...](http://walkercoderanger.com/blog/2014/02/javascript-minefield/)

