

TypeScript and the Road to 1.0 - smokel
http://blogs.msdn.com/b/typescript/archive/2013/10/17/typescript-and-the-road-to-1-0.aspx

======
kibwen
I actually want to commend Microsoft here for releasing an open-source (and
permissively-licensed!) compiler that doesn't run exclusively on its own
proprietary platform.

The language itself seems like a winner as well. Its conservative design makes
it the perennial dark horse of the compiled-to-JS language family, but that's
also what makes it most attractive to me. It's a thin-enough skin over the
underlying language that you get the familiar Javascript syntax (as per Dart)
while also retaining the ability to understand the generated code (as per
Coffeescript). It's also got well-defined corporate backing, which in a
professional environment gives me more peace of mind than recommending
Coffeescript (does jashkenas get paid to do this?), Clojurescript, or Elm (I'm
somewhat concerned about Dart here as well, at least until Google starts using
it in production). These properties mean that I'd happily recommend TypeScript
for client-side enterprise software development (but only once the compiler
hits 1.0, of course).

~~~
groovy2shoes
I can't speak for CoffeeScript or ClojureScript, but Evan Czaplicky _does_ get
paid to work on Elm: [http://elm-lang.org/blog/announce/Elm-and-
Prezi.elm](http://elm-lang.org/blog/announce/Elm-and-Prezi.elm)

------
clone1018
I really love TypeScript because one of the projects goals is to become
redundant one day. They're building what they hope JavaScript will get to
evolve into.

~~~
haxorize
That's not entirely true. While TypeScript is closely aligning itself with the
proposed ES6 syntax for classes and modules, there is no expectation that
ECMAScript will add optional static type checking. If you want statically
typed JavaScript you are always going to need something like TypeScript.

With that said, as ES6 evolves and becomes more widely supported there will be
aspects of the TypeScript compiler that will no longer be needed (e.g.
classes, modules, fat arrow functions, etc.).

~~~
k3n
> If you want statically typed JavaScript you are always going to need
> something like TypeScript.

I think that is a valid statement only within the context of the next ECMA
release. In other words, that's not to say that whichever successive version
after ES6 can't include it, or any version thereafter.

~~~
jeswin
You could make that argument about any missing feature. I haven't seen any
serious support for optional typing in JS; so at this point it would be fair
to say that GP is correct.

~~~
itsnotlupus
Well, there once was a forlorn EcmaScript version, aka ES4, which included
rather similar concepts (
[http://www.ecmascript.org/es4/spec/overview.pdf](http://www.ecmascript.org/es4/spec/overview.pdf)
) :

> Structural function types describe functions and methods. The type

> function (int, string): boolean

> describes a Function object that takes two arguments, one int and the other
> string, and which returns a boolean

Given that a great many other concepts from ES4 are finding their ways into
ES6, it is not implausible that this one may also reappear into a more
consensual specification someday.

------
kailuowang
To me the fundamental shortcoming for javascript is not its typelessness, it's
the lack of language syntax support for asynchronous programming, which is the
butter and bread for most javascript applications (server or client side).

I really hope I can do something like

for (

    
    
      ra <- asycn_opA(),
    
      rb <- async_opB(ra),
    
      _  <- asycn_opC(ra, rb)
    

).run()

~~~
apaprocki
So if you used Q or a similar library:

    
    
      Q.async(function*() {
        var ra = yield opA();
        var rb = yield opB(ra);
        yield opC(ra, rb);
      })().done();
    

Are you wishing for the other syntax or something that you can't achieve with
generators/promises today?

~~~
v13inc
Fortunately, with a bit of hacking, this style of syntax is possible without
generators :) (I'm hoping to open source a library I wrote that works all the
way back to IE6)

Here's your example rewritten in the 'monads' library (I probably need a
better name):

monads(function() { var ra = opA.defer(); var rb = opB.defer(); var result =
opC(ra(), rb()); });

~~~
dangoor
Is that open source? I'd be interested in taking a look.

------
jeswin
Does optional typing really work? I've always felt (or presumed) that once you
start putting types in, it kinda starts spreading everywhere and eventually
will look like full static typing. I'd rather have tests than types.

It is good to see people try different things though, so congrats on release.

~~~
gregwebs
If it spreads everywhere then that is because it is valuable everywhere. With
optional typing you decide where types have the most value, so there really
isn't a downside.

You are probably going to end up using types a lot if you are using projects
that already have type declaration files available (from the DefinitelyTyped
project).

~~~
awj
> If it spreads everywhere then that is because it is valuable everywhere.

Well, there is a downside in that you're now having to choose between adding
type annotations where you don't particularly want them or ignoring compiler
errors (warnings?). The former puts types everywhere, the latter partially
defeats the purpose of static typing and adds "sort out the errors I care
about" as another work duty.

My understanding is that with typescript you can use .js/.ts files as a
relatively coarse mechanism of segregating out your untyped code, but it isn't
entirely roses.

~~~
gregwebs
> ... choose between adding type annotations where you don't particularly want
> them or ignoring compiler errors ...

That is just not the case. Types get inferred. If the inference isn't making
it all the way through that means you have dynamic types, not a compilation
error.

And yes, ignoring warnings is crazy. TypeScript has very few warnings, mostly
just errors that can't be ignored.

------
james-manning
Sorry if this comes across as somewhat tangential, but I'm still wondering
if/when we'll have JavaScript runtimes (V8, Chakra, SpiderMonkey, whatever)
that can export runtime type information, even if only enabled in a 'debug'
mode?

I love the idea of optional typing being supported (whether in the base
language or TypeScript/Closure/etc) but it's maddening to think of trying to
have to add the type information manually to existing code, especially code
with lots of good test coverage, knowing that the JavaScript runtime seems to
have to figure it out anyway (at least based on talks about V8 from the past).

This kind of functionality seems even more important for projects like
DefinitelyTyped, where people are trying to track the public API's for
projects that sometimes have a lot of churn. Having runtimes export their
runtime type information (which seems to have sufficient mapping to source
based on existing debugger experiences in Chrome, IE10+, etc) and allowing the
creation of tooling that can populate/check/etc the type information in source
seems like a big potential win.

Anders asking the Chakra team for this to (massively, AFAICT) help TypeScript
adoption among existing projects seems reasonable, but TypeScript type
information seems to still be 'add it yourself' for now?

Am I just missing something that makes this far more
complex/difficult/intractable than I realize?

------
L8D
I think the one think that TypeScript needs to get it going is modularity. If
another project like
[harp]([https://github.com/sintaxi/harp](https://github.com/sintaxi/harp))
could use TypeScript as a library and could compile the code without having to
result to system commands would be a great thing.

However, I think if someone came up with a system to add optional typing
through the use of string literals it would be awesome. That way we can have
perfectly valid JavaScript with the benefits of certain JavaScript engines and
type checkers. The string literal would be before a function declaration like:

    
    
        "add(Number, Number) -> Number";
        var add = function(x, y) { return x + y; };
    

That would basically specify that the function takes two numbers, and returns
a number. This system would not replace a language like TypeScript, as
TypeScript provides much more functionality. But it would allow for really
simple optional typing and for TypeScript to take advantage of this(in the
case that a JavaScript engine eventually implements and optimizes for these
type declarations).

~~~
dangoor
The TypeScript compiler can be used as a library, I believe.

The Closure Compiler has a whole type system that lives in doc comments:

[https://developers.google.com/closure/compiler/docs/js-
for-c...](https://developers.google.com/closure/compiler/docs/js-for-
compiler#types)

and I believe there's a command line option for doing type checking. Alas,
Closure Compiler is written in Java rather than JavaScript so you can't use it
quite as seamlessly as TypeScript's compiler.

------
nawitus
I hope they'll integrate a JavaScript debugger to TypeScript and Visual
Studio, possibly with source mapping. (I would specifically need Node.js
debugging).

I also hope that they make a better module system.. currently it's pretty
confusing and I don't really know how to differentiate between TypeScript and
Node.js modules.

~~~
outside1234
Visual Studio allows you to debug TypeScript directly with source maps if you
install the free plugin: [http://www.microsoft.com/en-
us/download/details.aspx?id=3479...](http://www.microsoft.com/en-
us/download/details.aspx?id=34790)

~~~
nawitus
What debugger is that using? Note that I'm not looking for debugging browser-
side TypeScript/JavaScript code.

------
chrisoakman
I couldn't be more underwhelmed by what TypeScript has to offer vs vanilla
JavaScript or CoffeeScript.

Reading through the marketing material from MS it seems like the entire value
proposition is "statically typed languages make it easier to think about your
program, also we added the class keyword so you don't feel lost"

I suppose if you believe those claims or are really interested in using MS
development tools, TypeScript is for you.

IMO, ClojureScript is much more interesting and has a far greater value
proposition for complex front-end development.

~~~
k3n
Are TypeSscript and CoffeeScript really that much different?

From what I understood, they both basically solve the same problems, one just
does it in a Ruby-esque style while the other does it in a C#-esque style.

~~~
judah
I use CoffeeScript in my day job for the last 2 years.

I've been using TypeScript in my startup the last 6 months.

They are definitely not the same. TypeScript is JavaScript + types, whereas
CoffeeScript is a new language, a mashup of Ruby and JS. (For example, you can
take any JS on the web, paste it in a TypeScript file, and it will compile.
But you absolutely cannot do this in CoffeeScript.)

CoffeeScript tries to do clever things for you, which often results in
inefficient code. For example, say you've got a function that ends with a for
loop. CoffeeScript will actually convert that into an array allocation and
return the result of the array. (Looping over 1000 elements at the end of a
function? CS just allocated a new array which will be dynamically resized at
runtime multiple times, allocated 1000 buckets for the elements.)

CoffeeScript also can't make up its mind about whether parens are necessary.
Function with multiple params? Not necessary. Chained function, like jQuery?
Necessary. Most of the time. Function with no params? Necessary, unless you
use the 'do' syntax.

It's a mess.

TypeScript, on the other hand, is designed by respected, experienced language
designer Anders Heijlsberg. His language wisdom and overall vision for the
language shines through.

Bottom line: Both are better than vanilla JS, I'd say. But I work with
CoffeeScript when I have to. I work with TypeScript because I choose to.

~~~
c0achmcguirk
I've used both extensively and I'd disagree with you on almost every point.

> _For example, you can take any JS on the web, paste it in a TypeScript file,
> and it will compile._

This myth won't die.

False. Typescript will choke on most JavaScript files from the web. Because
you will need to include definition files for any external library calls. If
you use jQuery, for example, the compiler won't like your
$('.class').doStuff() calls because it won't recognize it until you go find
the jquery.d.ts file to include at the top of your file. Also, TypeScript will
struggle with the dynamic-ness of JavaScript. To prove this to yourself, paste
the contents of typeface.js into the play compiler at
www.typescriptlang.org/Playground/ and you'll see all the red squigglies that
you have to fix.

On the other hand, if you can do it in JavaScript, you can do it in
CoffeeScript, because CS is NOT statically typed. You can use js2coffee to
convert any valid JS on the web to coffeescript.

In my testing it takes me 25 times longer to take legacy code and convert it
to TypeScript than to convert it to CoffeeScript. That's because "valid
JavaScript is NOT valid TypeScript."

> _CoffeeScript tries to do clever things for you, which often results in
> inefficient code._

I find that CoffeeScript's results are BETTER than the TypeScript code. For
example, CoffeeScript automatically does array length caching in it's for
loops, resulting in much faster loops. It also correctly converts == to === in
comparisons, eliminating many nasty JavaScript bugs. TypeScript does neither.
In my analysis, TypeScript generates poorer code than CoffeeScript.

> _CoffeeScript also can 't make up its mind about whether parens are
> necessary._

Use them all the time if you want, CS isn't dogmatic about it. EcmaScript 6
(and TypeScript too) will be moving toward optional parentheses too. It's a
nice feature.

> _TypeScript, on the other hand, is designed by respected, experienced
> language designer Anders Heijlsberg. His language wisdom and overall vision
> for the language shines through._

Anders has done a fine job of making TypeScript look like C#. It's one
redeeming trait is that it helps the tooling for allowing refactoring and
intellisense. I find it cumbersome and you have to put a lot of ceremony into
your code just to get it working. It is roughly 35% more lines of code to do
the same thing in TypeScript that you could do in CoffeeScript, and you are
fighting the compiler more often. I think TypeScript would be an incredible
burden for enterprise applications because of the need to include definition
files. Think of the joys of upgrading your version of jQuery and having to
find the jquery.d.ts file to go with it.

I recently presented a talk at a conference on the two languages and after
evaluating both languages in depth, CoffeeScript was the clear winner. Both in
the code it produces, but also the amount of effort to develop in it.

~~~
kmontrose
TypeScript appears to compile even in the face of undefined variables.

Just went to the playground and dropped a random jQuery sample in:
[http://www.typescriptlang.org/Playground/#src=%24(%20documen...](http://www.typescriptlang.org/Playground/#src=%24\(%20document%20\).ready\(function\(\)%20%7B%0D%0A%20%0D%0A%20%20%20%20%24\(%20%22a%22%20\).click\(function\(%20event%20\)%20%7B%0D%0A%20%0D%0A%20%20%20%20%20%20%20%20alert\(%20%22Thanks%20for%20visiting!%22%20\)%3B%0D%0A%20%0D%0A%20%20%20%20%7D\)%3B%0D%0A%20%0D%0A%7D\)%3B)

You get squiggles yes, but you also get valid javascript. So it looks like you
can paste random javascript into TypeScript and get it to compile. I went and
tried with the actual compiler (to make sure it's not some artifact of the
playground website), and confirmed you get a proper .js file out (and 2
messages, about $ being undefined).

Quick google makes it sound like getting rid of the squiggles / messages is
pretty easy:
[http://stackoverflow.com/a/12755602/80572](http://stackoverflow.com/a/12755602/80572)

I'm not sold on TypeScript yet (or any of the transpiled javascript languages,
honestly), but this:

> False. Typescript will choke on most JavaScript files from the web.

Seems to be the actual false statement in this thread.

~~~
c0achmcguirk
Thanks for trying that out the jQuery example. They look to be making the
compiler (or the playground site) more permissive lately. This didn't work in
May when I last tried it out.

I've used the typescript compiler on a randomly-chosen JS library (typeface.js
[http://typeface.neocracy.org/typeface-0.15.js](http://typeface.neocracy.org/typeface-0.15.js)
) and it had dozens of compiler errors for me to fix before it would compile.
The playground is now accepting them for some odd reason. This seems to be
recent behavior or perhaps the node.js version of the compiler behaves
differently?

~~~
rictic
One thing that threw me off initially is the fact that typescript will
complain about errors, but still do the translation of TS -> JS. For example:

    
    
        var s = 'hello';
        s.toExponential();
    

Typescript tells you about the obvious error that there's no property
'toExponential' on strings, but it also merrily produces yourfilename.js.

In my experience so long as you don't have any syntax errors, tsc will give
you back javascript. This is partly because the translation from typescript to
javascript is incredibly straightforwards and ignores the types completely.
Writing a nonvalidating, dumb but super fast ts -> js transpiler is about an
afternoon's worth of work, especially if you bootstrapped from the typescript
parser and tests.

