
Why does TypeScript have be the answer to anything? - andrijac
http://www.hanselman.com/blog/WhyDoesTypeScriptHaveBeTheAnswerToAnything.aspx
======
krohrbaugh
First of all, I'm glad Microsoft is getting involved in this space. They have
a deep talent pool when it comes to language design and tooling and it'll be
interesting to see where TypeScript goes.

Unfortunately, the arguments trying to draw some kind of monumental
distinction between TypeScript, Dart and CoffeeScript are silly. They are all
a response to the state of client-side development and are all applying
essentially the same strategy (i.e., some syntax changes and a pre-compiler).
It's great that TypeScript is a superset, which is what makes it pretty
interesting to me, but it's still more similar to the other two than not.

Plus, what's so bad about being Microsoft's "answer" to something else?
Windows was the response to Mac OS, Xbox was a response to PlayStation, .NET
was the response to Java, ASP.NET AJAX was the response to Prototype (later
abandoned for jQuery), ASP.NET MVC was the response to Rails, Entity Framework
was the response to Hibernate/Active Record, NuGet was the response to
Rubygems/npm. Each of these moved MSFT forward and several of them moved the
industry forward. The ASP.NET team (of which Mr. Hanselman is a member) is
doing a lot of great stuff inside MSFT, but a lot of is derivative. That's
okay. It's largely the strategy MSFT has always followed, so why waste energy
defending what has worked well in the past?

I agree with one point, however: It _is_ disappointing when smart people
display a profound ignorance of computing history.

~~~
TazeTSchnitzel
> essentially the same strategy (i.e., some syntax changes and a pre-compiler)

TypeScript and CoffeeScript, yes. Dart's a brand new C-like web language that
is quite different, and has its own VM. Although, of course, you can still
compile to JS. But unlike TypeScript and CoffeeScript, it isn't really an
alternative syntax for JS, or annotations removed at compile-time.

~~~
krohrbaugh
Yes, I know and you are correct.

At a high-level, though, and in the case where browsers are the target
platform, those aspects are largely implementation details.

~~~
TazeTSchnitzel
With the rather large exception of filesize.

------
eranation
I think google missed big time on Dart, and something like TypeScript is what
they should have done. I really find it hard to come up with bad things to say
about Microsoft's move, it's a mental cognitive dissonance, but I have to
admit, they are doing something very right.

1) it's just JavaScript - winning some CoffeeScript fans

2) regular JavaScript is valid, (just like SCSS vs SASS)

3) it has day 1 interop with vanila JS (Dart just started, and until it has
it, it's just a play-with language)

4) TypeScript support for most popular editors (Dart has mostly Eclipse I
think, TypeScript has support for everything but eclipse, but an eclipse
plugin is just a matter of time probably)

5) TypeScript has a bit more chance becoming a standard, (future ECMASCript
6?)

Well played Microsoft, didn't see it coming...

VS 2012 is actually nice, still I would probably wait for an Eclipse plugin
(I'm sure someone out there is already working on it) but this is for me a big
reason not to start learning Dart

~~~
cmccabe
I think you answered your own question. Google wanted a fundamentally
different language, not just JS with some extra features thrown in. As to what
will win out in the end-- I have no idea.

~~~
eranation
Google seem to like inventing things, they have people who create languages
for a living (some of the creators of Java, that some of them are probably
behind Dart) and they did some pretty amazing things, Go is a great language,
I'm sure Dart will have a fan base, and who knows, it might catch up (in 2004
no one thought Ruby will be that popular, right?) Google went for their
vision, Microsoft went for the practical.

------
ivanjovanovic
The way I see it:

1\. TypeScript is an answer to the poor state of JavaScript development today
and an attempt to get more structure into it. There are other answers as well,
and it can be discussed on properties of each of them, but they are competing
in the same domain.

2\. Since state of JavaScript is as it is, it is obvious that there is a lot
of potential benefit in being a leader of the technology in that domain.
Regarding that, it is kind of answer to forces that are trying to ensure
domination in that domain for the future.

~~~
dreamdu5t
Poor state of JavaScript development? By what measure?

I've been doing "application-scale" development using JavaScript for 5
years... Not once did I think "gee my development process would be better if I
had rigid typing." The notion is laughable.

The lack of rigid typing and classes is by design. This is a feature not a
bug. I honestly wonder about a programmer's understanding of JavaScript if
they say things like "JS lacks classes!" - I'm not sure they understand
JavaScript.

~~~
oinksoft
Types _are not_ classes! Why do people feel the need to constantly drag out
this scarecrow? Having tools to perform static analysis is nothing but a good
thing, and you need type data to do a great deal of this. Perhaps your project
requirements are such that you never require type checking for your JS, but I
can say that it's saved my ass a number of times when working on very large
code-bases, and definitely has sped up my development cycle when working on
hairy code.

This is a type, not a class, taken from a Closure Compiler docs annotation
example:

    
    
      /**
       * Enum for tri-state values.
       * @enum {number}
       */
      project.TriState = {
        TRUE: 1,
        FALSE: -1,
        MAYBE: 0
      };
    

Now I can require this type in my code with standard JSDoc, which is what the
compiler uses anyway for type-checking. It makes my code self-documenting (the
Closure Linter, should you use it, will complain if you omit descriptions and
the like too, if you find yourself getting lazy):

    
    
      /**
       * Do something...
       * 
       * @param state {project.TriState} The state ...
       */
      function doSomething(state) {
    

If you are documenting your code, you already do this. And now you have static
analysis out-of-the-box ... not bad!

~~~
disordinary
The JSDoc system gets in the way too much, how for instance do you type
variables which is something like:

    
    
      /** @type {myType} */ var thing = new myType( );
    

It gets way to verbose when compared to typescript which is something like:

    
    
      var thing : myType = new myType( );

~~~
oinksoft
Actually that's not quite accurate. The Closure Compiler doesn't need you to
tell it that `thing` is a myType, it knows that, asuming myType is defined in
your compiled code, or you provide an extern specifying what myType means. And
I might be wrong about that last bit even; the compiler may always know that
`new Foo` returns a {Foo} regardless of context ... I would have to check the
compiler source to be certain.

Also, I think that the first example is more likely to be written as follows
(in the case where type data cannot be inferred):

    
    
      /**
       * Description of the variable.
       *
       * @type {my.UnionType}
       */
      var foo = { ... };
    

Whatever "..." may be. It's common to document the meaning of variables where
explicit typing like this is important, just like in well-documented Java and
PHP code.

~~~
disordinary
The benefit of typing javascript is for the developer and not the compiler,
therefore telling closure compiler that a variable is a type is to decrease
the chance of mistakes. Closure compiler also is buggy and isn't as smart as
we would like to think it is, sometimes you have to prod it into the right
direction. It was a simplified example, something better would be:

    
    
      /** @type {myType} */ var thing = function_that_returns_a_myType( );
    

The point is using comments for typing a language is messy and takes up far
more space than required.

------
rbellio
I've been testing it out and I like it so far. I personally don't enjoy
writing JavaScript in text editors and the tools like PHPStorm, while being
decent don't really give me the slick development environments that I've come
to enjoy.

Since I do a lot of Windows and .NET web app development for my day job, I
really enjoy the fact that Microsoft is putting a concerted effort into not
only adding more support for JavaScript, but also for looking at the state of
JavaScript and looking to improve the experience for people like me.

In Anders introduction to TypeScript, he mentions the gap between .NET
development and JavaScript and hints that this is just the beginning of
bridging that gap.

Rather than being a language that hides the underlying structure (a la ASP and
ASP.NET) it is much closer to native JavaScript development. I'm really
excited to see where this might go and have my fingers crossed that it only
improves the state of JavaScript development.

------
benatkin
The author ignores the fact that TypeScript is being heavily promoted by
Microsoft. TypeScript isn't an experiment, but something Microsoft is trying
to sell, along with their IDE. He starts it with a quote from a colleague
rather than citing examples of people attacking TypeScript, as if it's a
forgone conclusion that people have gone overboard on attacking it. I hate to
see an argument for a programming language start with the author's persecution
complex.

~~~
TazeTSchnitzel
>Microsoft is trying to sell

Do you mean sell as in for money? Or sell as in get people to adopt? Under an
Apache license, I doubt it's the former. Although they could sell the Visual
Studio tooling.

~~~
seanmcdirmid
Use the tooling to sell the platform? It might be in Microsoft's interest to
have some mindshare I this space; JavaScript is a significant part of the
windows 8 story from what I can tell.

------
devgutt
This is a ingenious move. A much smaller subset than CoffeeScript and still a
sensitive and important one that probably will be incorporate at ECMAScript 6.
If not, you still have your vanilla JS. I'm not sure with TypeScript will
succeed, but I'm sure that this is the way to fix JS's problems.

------
bascule
"What I like about TypeScript - so far - is that TypeScript’s static typing
could enable better tooling with warning squiggles, easy statement completion,
plus smart refactoring. You also get easy navigation around code, as well as
find references, rename, and more."

RubyMine (by IntelliJ) can do all of that. Don't get me wrong, the refactoring
support for statically typed languages is a _lot_ better (e.g changing method
signatures) but none of the examples he listed require one.

------
jmmcd
This isn't exactly the right place, but I don't know where else to ask this.

When people argue for static types (whether optional as in TypeScript or
mandatory), one of the main reasons is "tooling". Why?

I know that writing a "go to definition" function for your IDE is impossible
to do 100% correctly, when types are dynamic. But I would've thought it'd be
pretty easy to do a 99% implementation, which rarely fails if you don't
deliberately write code to fool it. Right?

~~~
jes5199
Yeah, I think it might be a programming-language cultural thing. Most
refactoring tools are written for Java and C#, so the people with experience
writing refactoring tools have worked out how to solve the problems when they
have certain assurances. But it really should be possible to write usable
refactoring tools for ruby and python and javascript - you'll have to do a
little more work to figure out name collisions between variables and methods
and there's going to be ambiguous metaprogramming stuff like using strings to
lookup instance variables, but having good tooling in the cases where you
weren't using metaprogramming might encourage programmers to use a more
concrete coding style, and that's probably a good thing. (Java has the same
problems when you use a lot of reflection. So people don't use much
reflection!)

~~~
jmmcd
YES! And I bet that a little bit of heuristics, a little bit of machine
learning, and/or a little bit of user feedback (say, a button that tells the
tool it went to the wrong function definition) would help such a tool cover a
few more of the difficult cases.

This ought to be a classic case of "worse is better", which is why I'm
surprised to see that people seem to shy away from it.

------
MatthewPhillips
I agree with this. If it's nothing more than a forward-compatible superset of
JavaScript, with _optional_ static typing, it has a place in the world of JS
target languages.

~~~
grayrest
I'm not sold on forward compat. I'm only an interested observer of TC39 but to
my knowledge only arrow lambdas and modules (the cross file ones) are near
consensus. The rest of the features added have either been going around for a
long time or haven't really gotten a lot of discussion.

------
mistercow
>Dart interops with JavaScript...but it's not JS. It doesn't even use the
JavaScript number type for example.

What is meant by this? As far as I know, the only way that you can use Dart in
any browser currently is by compiling it to JS, and when you do that it most
certainly does use native JS numbers. In fact, the type check function it
creates for numbers contains this line:

    
    
          if (!(typeof value === 'number')) {

~~~
scott_s
He means that the semantics of Dart - including the data types provided by
Dart - are different from JavaScript. This is in opposition to TypeScript,
which is a superset of JavaScript, which means that it necessarily shares
JavaScrips semantics.

If your example bothers you, consider that JavaScript just happens to be a
_target language_ for the Dart compiler. That is, it takes a program with
Dart's semantics, and figures out how to map those to JavaScript semantics.
That there is a mapping is not all that interesting, as such a mapping will
exist from any Turing complete language to any other.

~~~
lindenr
Really? Wow, that's cool. Can I have a reference?

~~~
scott_s
I'm really just describing how a compiler works. Are you looking for
references on the compilation process? There's a classic series called "Let's
Build a Compiler" (<http://news.ycombinator.com/item?id=1727004>) available
online that walks through building a simple compiler. Then there's also actual
textbooks, but I was not impressed with either of the two textbooks I've had
on the topic. Many people recommend "Compilers: Principles, Techniques, and
Tools" (<http://dragonbook.stanford.edu/>) also referred to as just _the
dragon book_. If you're not averse to textbooks, you may also want to check
out Michael Scott's "Programming Language Pragmatics"
(<http://www.cs.rochester.edu/~scott/pragmatics/>).

------
jconley
The Typescript syntax looks shockingly like Adobe's ActionScript. Next up,
Adobe releases an ActionScript to Javascript cross compiler?

~~~
aaronblohowiak
Do you know the history of ES4?
[http://en.wikipedia.org/wiki/ECMAScript#ECMAScript.2C_4th_Ed...](http://en.wikipedia.org/wiki/ECMAScript#ECMAScript.2C_4th_Edition)

------
nahname
I have to build my entire project every time I want to update my client side
code? That is an enormous tax to charge the developer just to add static
typing to your client side code. I can't see this doing anything but slowing a
team down.

~~~
Me1000
Anyone building large projects do this anyway, using minifiers to reduce the
download size. Sometimes the code has inline documentation which gets built
too.

A build step is already a reality for many people writing JS today.

~~~
asher_
This isn't really a fair comparison. You can use unminified, commented
javascript in development for testing without a build step, and just build for
production.

Even so, a build step can be a single keypress, so its no big deal.

~~~
MatthewPhillips
I don't know about you, but to me once a code file is larger than say a couple
hundred lines it becomes exponentially less readable. So any non-trivial
amount of JavaScript already includes a concatenation build step anyways, even
for development. As long as the TypeScript compiler is reasonably fast on
larger (10k LOC) projects, it wouldn't be any issue at all.

~~~
oinksoft
This is a moot point. The Closure Compiler supports dependency resolution so
that you can unit test your code without building the full project. So, if I
am testing foo.bar.Baz, I can create a file that only includes `base.js' and a
goog.require('foo.bar.Baz'); call, and `base.js' will include all of its
dependencies, in most cases fairly quickly.

Unless you are performing integration tests, there is no reason to compile
each time. Doing that is just the legacy of limited build systems.

~~~
MatthewPhillips
Does goog.require() resolve at run time or compile time?

~~~
oinksoft
You're realistically only going to _deploy_ a compiled script. The compiler
supports goog.require/provide() without requiring any JS inputs, and core
tools like closurebuilder.py (which has superseded calcdeps.py) build your
dependency graph for you. The compiler uses the require/provide statements to
ensure that all necessary symbols are indeed provided, and are only included
once in the script.

For debugging purposes, `base.js' implements goog.require() in JavaScript. The
implementation is naïve, it just turns foo.bar.Baz into foo/bar/Baz.js and
tries to include it. This is good enough for running unit tests or fiddling
around with experimental code, which are the two times you're going to use
`base.js'.

[http://code.google.com/p/closure-
library/source/browse/trunk...](http://code.google.com/p/closure-
library/source/browse/trunk/closure/goog/base.js?r=2#240)

~~~
MatthewPhillips
Yes, my question is whether goog.require() executes on the client's computer
(in production) or whether Closure strips out those calls when you pass a
special flag (as part of your deploy build). I personally don't want
dependency resolution to happen at runtime in production.

~~~
oinksoft
Erm ... like I said, it happens at compile-time. The library provides a
runtime version for testing purposes. Sorry if I wasn't clear enough.

------
cmccabe
Seems like a troll article to me.

Of course people are comparing TypeScript to Dart. They do the same freaking
thing-- provide you with a different way to write code to run in the browser.

Then he presents the metaphysical distinction between "building on JS" (good)
versus "interop with JS" (bad). What's the difference? Neither language is JS.
If something breaks, you're still going to be debugging code that isn't the
code you wrote-- it's generated code.

I feel no better informed after reading this article than before. Will someone
please do a straightforward comparison between Dart, TypeScript, and
CoffeeScript? It might be kind of hard because as far as I can see, TypeScript
does not build on Linux.

P.S. Is "it doesn't even use the JS numeric type" supposed to be a put-down of
Dart? I always thought the JS numeric type was a big mistake. Who would want
to be forced to use floats for everything? Inaccurate and slow-- two great
tastes that taste great together.

~~~
Garoof
> What's the difference?

One lets you take existing JS-code and make use of new language features
there. The other "just" lets you call existing JS-code.

I'd guess one is clearly better than the other when it comes to dealing with
existing JS-code* . (While the other is clearly preferable to the one when it
comes to making the language you want to make.)

* It still obviously depends a lot on the language. Like, how well TS-code works together with plain JS-code (how much do you get out of adding some type annotations here and there while leaving most of the JS-code untouched, etc.).

~~~
cmccabe
OK. So there is a path to converting JS to typescript without rewriting the
whole thing. Thanks for the additional information.

~~~
ryanzec
I believe it is also possible to create definition files, like c++ header
files, for existing libraries. So for instance, if you want the type checking
for backbone, you could create a backbone.d.ts and just include the
class/method/function definitions (and interfaces if you want to) and not even
touch the original library. I would imagine this is the preferred way of doing
things still I would imagine most libraries are not going to want to convert
there libraries to include TypeScript only syntax.

