

TypeScript: a language for application-scale JavaScript development - D_Guidi
http://www.typescriptlang.org/
TypeScript is a language for application-scale JavaScript development.
TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.
Any browser. Any host. Any OS. Open Source.
From Microsoft.
======
cek
Say what you want about whether this is a good idea or not, it is clear at
least part of MS is really serious about open source.

* TypeScript is under the Apache 2.0 license [1]

* Source is available via git on Codeplex [2]

* Installation is as easy as _npm install -g typescript_ [3]

Extra bonus coolness: They've provided an online playground like jsfiddle!
[4].

[1]<http://typescript.codeplex.com/license>

[2][http://typescript.codeplex.com/SourceControl/changeset/view/...](http://typescript.codeplex.com/SourceControl/changeset/view/d397c54a55db)

[3]<http://www.typescriptlang.org/#Download>

[4]<http://www.typescriptlang.org/Playground/>

~~~
DougWebb
I started doing C# development last year, coming from mostly a Unix/Perl
platform, and I'm really glad about the timing because that's when Microsoft
got serious about open development. I started doing web apps using ASP.NET
MVC3, and this year MVC4 was released as an open-source project[1]. It seems
that a bunch of 'young turks' have reached higher management positions in most
of the key software development products within Microsoft and they're all
pushing for this kind of open source approach.

[1] <http://aspnet.codeplex.com/>

~~~
skrebbel
Roughly the same story here. At the risk of sounding like a fanboy, I feel
that while most tech BigCos (e.g. Google, Apple) have become more evil over
time, MS has actually become _less_ evil, to the point that using their tech
(and some major tech at that) is relatively free of any lock-in risk.

TypeScript seems very much in line with this trend, and I love it. This is
exactly what I wanted - JavaScript but with decent safety and IDE support. And
no more than that. I really hope that non-MS-geeks will embrace it and that
Eclipse plugins and JetBrains tools and the likes will follow.

That said, ASP.NET MVC is a misguided and overrated Rails ripoff, IMHO.
Where's all that great refactoring support if everything is made `dynamic` and
stringly typed? What's up with matching parameters to _method argument names_?
(I mean, change an argument name and your code breaks? wtf?) Since when does
Microsoft tech favour magic over clarity?

~~~
nkohari
Trust me when I say that if you use .NET, you're always going to be stuck with
Microsoft. Mono, the only other somewhat viable implementation of the CLR,
just doesn't really cut it in practice -- at least for ASP.NET.

~~~
skrebbel
hmm, mind sharing why? My limited Mono experience was that getting a simple
ASP.NET application running on a Linux VPS was, without prior Mono experience,
one hours' work. I was pretty impressed by this.

~~~
nkohari
As meanguy pointed out, the Mono team lost Novell's backing -- arguably, they
never had it in the first place. Xamarin is now focused entirely on mobile, to
the detriment of the core CLR implementation and web.

Not that I blame them in the least. I've been a huge fan of Miguel for years,
and they're doing great things in the mobile space. I just can't in good
conscience invest heavily in Mono knowing that it's essentially at a dead end
-- particularly when other much more attractive web technologies have been
released since .NET's inception.

The reality is that Microsoft never really wanted to build a cross-platform
CLR. They wanted a great Java-like runtime that only works on Windows. If that
matches up with your goals, then by all means use .NET, but be prepared for a
tough slog later on if you want to escape Windows.

~~~
cek
Mono is now backed by Xamarin. They got something like 12M in VC funding this
summer and appear to be on fire. From what I've seen, the future of cross
platform .NET looks great.

~~~
meanguy
Click the Xamarin Dev Center link. You'll see Android and iOS but no Linux.
They're focusing on mobile client tools.

They never got the full stack running on the server and they punted most of
the Windows-specific client stuff from the start.

They landed on a super smart subset and seem to be kicking ass with it. A C#
compiler with some odd omissions and cool enhancements + native bindings to
iOS and Android equals a damn useful tool. If you're building .NET or even
Java backends it's certainly a very sane way to hook into them from Android
phones and tablets in the enterprise.

But it's not a cross-platform .NET environment by any stretch and certainly
isn't on the path to becoming one.

------
wingspan
Awesome, great to see this finally released. I'm a dev in FUSE Labs
(<http://fuse.microsoft.com>) and we've been dogfooding TypeScript for a while
now. I'd be happy to answer any questions about using TypeScript vs vanilla
JS, converting a large codebase, etc.

~~~
platonichvn
This is great to hear. I have only just started reading up on TypeScript. But
I would love to know if there will be support for a decimal type. I have been
following Google's work on Dart and it doesn't look like they will be
implementing it last I checked. Such a feature would be a great
differentiator.

~~~
wingspan
A team member could comment better than I, but unless TypeScript adds some
kind of operator overloading, supporting a new type would be difficult since
it compiles to normal JavaScript. Even then, creating a performance decimal
type without native code support might be difficult.

~~~
platonichvn
Yeah performance is another issue. But providing a type that compiles to a
defined type that implements decimal representation would be very useful. GWT
pulls off something similar by compiling the Java BigDecimal to a JavaScript
equivalent.

------
arturadib
All of these compile-to-JS efforts are great, and as much as I love things
like CoffeeScript I have to say I definitely worry about language
fragmentation.

JavaScript is full of flaws, but its monopoly in the browser space has brought
about one intriguing and welcome side-effect: a VERY efficient market for both
employers and employees.

It's easy to overlook how important this common denominator has been for
everyone involved. Employees have a tremendous amount of mobility within the
industry: don't like your current JavaScript job? No problem - just about
every dot-com needs a JavaScripter. Similarly, companies can today tap into a
tremendous pool of JavaScript developers.

In today's fast-paced development environment, the ability to hit the ground
running is key, and I worry that fragmentation will introduce unnecessary
friction in the industry.

~~~
camus
Javascript is dreadfull , and its flaws are counter productive and
intolerable. It has good things like closures and first class functions , and
that's it. Most of js developpers hate javascript , but are forced to work
with it. So they dont care what they use as client language provided it gets
the job done. few people cares about Javascript. most of the devs hate it. But
the browser as dev plateform is a fact.

~~~
kofman
Agreed, it's a terrible language. Among other things, it makes it way too easy
to write code which many people will read as being correct, but will actually
be subtly incorrect.

A few of the weakest parts:

\- for (var x in y) when used for array iteration or even dict iteration;
hasOwnProperty? Really?

\- x[obj] = y; seriously, did i really want '[Object object]' as my key?

\- the choice of function level scope over block level scope

~~~
Xcelerate
I'm not sure function level scope over block level is a bad thing. It makes it
more Lisp-y. And if you want block level scope, it's about as easy as (in
CoffeeScript):

    
    
        do ->
            ... local variables right here ...

~~~
munificent
> I'm not sure function level scope over block level is a bad thing. It makes
> it more Lisp-y.

Lisp has block scope.

~~~
Xcelerate
Well, it can have both...

~~~
Evbn
Example?

Can you write Lisp like this?

Function for(){ f(x); var x = 2; }

Compiles and runs with f(undefined)

------
epidemian
It looks _really_ good for a first release. The focus on tooling is IMO the
most refreshing thing about the project; the playground is great!

I haven't dug much into it yet, but there are a couple of annoyances that i
noticed in the playground that i wish will be corrected/alleviated somehow:

\- The language is not expression-oriented. Once i got used to the "everything
is an expression" mindset in languages like CoffeeScript or Ruby (or every
functional language that i can think of) it feels quite tedious to "go back"
and remember that, no, now the "if" is not an expression any more, you can't
return it, or pass it to a function, or assign it to something. You can use
the special syntax of the "?:" operator for an if-expression, but there is no
equivalent for "switch", or "try", or "for".

\- The type system doesn't seem to support parametric polymorphism. For
example, the type of string[]::map is ((string, number, string[]) => any, any)
=> any[] instead of ((string, number, string[]) => T, any) => T[]. So the
value ["hello", "world"].map((s) => s + '!') is of type any[] instead of
string[], which would be preferable IMO.

~~~
wingspan
TypeScript will eventually support generics, as per the spec [1]:

    
    
      NOTE: TypeScript currently doesn’t support Generics, but we expect to include them in the
      final language. Since TypeScript’s static type system has no run-time manifestation, Generics
      will be based on “type erasure” and intended purely as a conduit for expressing parametric type
      relationships in interfaces, classes, and function signatures.
    

[1] <http://go.microsoft.com/fwlink/?LinkId=267121>

~~~
epidemian
Cool. It is quite expectable too, at least considering the capabilities of the
C# type system :)

------
scanr
Very interesting. The Apache 2.0 Licence is comforting, makes it worth having
a look. The docs are here for anyone interested in the spec:

<http://typescript.codeplex.com/documentation>

I like what they've done. Nothing too revolutionary, mostly adding static
typing to Javascript without straying to far from the existing (or future)
language or increasing the noise significantly.

Here's some highlights:

* Type inference
    
    
        function f() {
            return "Hello World!";
        }
    

Will do the right thing

* Explicit Typing
    
    
        function f(s: string) {
            return s;
        }
    

* 'Ambient Types'

To facilitate integration into existing JS libraries or the DOM, TypeScript
lets you specify 'placeholders' for variables / classes that the runtime would
expect to see e.g.

    
    
        declare var document;
    

Almost a kind of dependency injection but also a neat way to manage talking to
existing code.

* Structural Typing

* Classes and Interfaces
    
    
        interface BankAccount {
            balance: number;
            deposit(credit: number): number;
        }
        
        class CheckingAccount extends BankAccount {
            constructor(balance: number) {
                super(balance);
            }
            writeCheck(debit: number) {
                this.balance -= debit;
            }
        }
    

* Modules
    
    
        module M {
            var s = "hello";
            export function f() {
                return s;
            }
        }
    

* Arrow function expressions
    
    
        (x) => { return Math.sin(x); }

~~~
euroclydon
Are you actually implying with the above example code that you can call a
undefined "super" _constructor_ on an interface and pass it the "balance"
variable, which the interface's non-existent _constructor_ would presumably
match by name?

~~~
scanr
Nope. I probably should have used a different example for the interface. The
examples are from the full spec where they progress a little more gradually
from a BankAccount interface to a BankAccount class to a CheckingAccount
subclass.

------
oinksoft
It seems to me that the type checking in TypeScript is extremely limited
compared to what the Closure Compiler supports. The examples only show simple
`fooInstance : Foo` examples, whereas Closure supports function prototype
validation and such, a la C. I will need to see more elaborate examples.

Granted, there is no documentation that I could find on the website. I
understand that this is a "preview," but I disagree with this way of
presenting a tool. When the Closure Library was released, for instance, it was
absolutely chock full of API documentation. This is because it was used for
real-world projects and extensive docs mattered, even internal to Google.

There is a language specification (PDF, in the source tree) which is
encouraging, but where's the manual?
<[http://www.floopsy.com/post/32453280184/w-t-f-m-write-the-
fr...](http://www.floopsy.com/post/32453280184/w-t-f-m-write-the-freaking-
manual>). The specification is largely a rewording of the ES5 spec with
insertions where the typing additions are important. It will take a good bit
for the reader to separate the wheat from the chaff, as they say.

I have more than a sneaking suspicion that this project is essentially a
proof-of-concept, and that it is not heavily used at Microsoft. Do you
remember "Microsoft Atlas" in 2006, at the height of the JS DOM Library Wars?
In the end, they just pushed their developers to use jQuery with some code
generation helpers. Microsoft's open-source track record for JavaScript is not
impressive, and I think you'd be a damned fool to invest in this technology
for any serious project.

~~~
wingspan

      I have more than a sneaking suspicion that this project is essentially a proof-of-concept, and that it is not heavily used at Microsoft.
    

My team has been dogfooding TypeScript for several months now, providing lots
of feedback and writing > 30,000 lines of code (in many cases the new
TypeScript code is shorter than the original Javascript).

~~~
oinksoft
In this case, I must infer that the culture of documentation is not the same
at Microsoft as it is at Google.

Further, how can you have a tool like this and nothing for generating type-
aware documentation from your source code? Google uses jsdoc-toolkit, so this
is a moot point for them. Either you guys are using this in an informal
fashion, or documentation isn't that important at Microsoft, or you just
haven't released the doc generation tool(s), which would be a really odd
choice!

~~~
bnr
The Language Specification looks pretty extensive[1].

And TypeScript is just the language, so there's no API to document besides
what your browser exposes in JS.

[1]
[http://www.typescriptlang.org/Content/TypeScript%20Language%...](http://www.typescriptlang.org/Content/TypeScript%20Language%20Specification.pdf)

~~~
oinksoft
Of course there is no API to document, and I noted the spec PDF in my top
comment. Where is the manual, or something like one? At Microsoft, do they
just tell a developer new to TypeScript to read the spec? Highly unlikely.
MSDN is full of good documentation, and it's very weird that there's nothing
of the sort for this project. I'd think that's an awful lot more important
than Vim integration and such.

Even CoffeeScript had a manual very early on, and so did Dart.

I'm not saying "bad on Microsoft for releasing this!"; it's good they're
starting to sort of figure out how open source works. Rather, like I said,

 _I think you'd be a damned fool to invest in this technology for any serious
project._

Right now this is a toy.

~~~
Evbn
Closure docs are pretty thin, mostly extracted symbols from code, with cryptic
or misleading explanations. But a least you have clickable API listings.

~~~
oinksoft
I don't think this is fair at all. The Closure Library may have its dark and
dusty corners, particularly for recently added/less used components, but on
the whole, the library API is quite well-documented. You are mistaken about
the API docs being generated from extracted code symbols; rather, it is all
pulled from standard JSDoc tags. The library authors are meticulous about
defining custom types rather than using ad-hoc enums and the like in their
code, making the codebase itself very comfortable to reason about and making
these @param and @return types very clear in their meaning.

I have my complaints about the library (certain dusty corners of goog.ui and
goog.editor have hard-coded CSS classNames and Google URLs, meaning you have
to use a patch queue to customize them) but I'm very pleased with the API
documentation and examples. Google admittedly leans on Bolin's book (O'Reilly,
2010) too much for the community's manual-style documentation, but this is
less crucial for a library than the API docs, and that book is really good :^)

The library has an extensive demo collection which is pretty nice too, and the
demos generally include a minimum of 2-3 examples to show different ways to
use library components (decorating vs. rendering usage of goog.ui package, for
instance).

Google's real failure with Closure Tools has been marketing, but that is not
my concern very much as a user. However, I see how this affects the library's
adoption, so I've created a page at <https://oinksoft.com/closure-tools/irc/>
(I op the IRC channel) where I hope to aggregate more resources over time so
that new users are able to get up-and-running without using Bolin's book.

------
spicyj
This looks nice. I love the fact that there's no runtime that needs to be
included or any overhead when the compiled JS runs.

It'd be 100% more useful if it was more aware of nullable types -- as it is,
it appears that

    
    
        null * 7
    

compiles without any error messages. If they add a "nullable number" type
distinct from "number", I'll be a lot more likely to use it.

It also appears that some other things compile that perhaps shouldn't, such as

    
    
        7[2]
    

and

    
    
        7["a"]
    

even though (7).a is equivalent and (correctly) fails to compile.

~~~
wingspan
`7[2]` is valid Javascript, so it is also valid TypeScript (fetching the '2'
member of the `7` object).

Detecting null expressions at compile time might help. There are "nullable"
types, but afaik only in signatures:

    
    
      foo(x?) {
          alert(x);
      }
    

If `x` is not passed in, it will be `undefined`.

~~~
spicyj
"wingspan" * 7 is also gramatically correct JavaScript, but evaluates to NaN
and almost certainly isn't what you want in your JS program, which is why
TypeScript prints a type error (well, warning) if you try to compile it.

Having optional variables is similar, but not the same as nullable types,
especially when the compiler can't enforce non-nullable-ness. All JS devs are
familiar with the annoying error "'null' is not an object" (and anyone who's
programmed in a language like Haskell, OCaml, or F# knows the value of
sophisticated compile-type type checking).

~~~
wingspan
Yes I see what you mean, it'd be interesting to see what the exact rules
around type checking are; especially when dealing with []. The string type for
example, always give you a string when indexed, even when incorrect:

    
    
      var s = 'foo';
      var l = s['length'];
      // type of l is `string`
    

I also agree about non-nullable types, and I've found even with TypeScript,
having to make sure your vars are defined and not-null is still a pain.

~~~
masklinn
> var s = 'foo';

> var l = s['length'];

> // type of l is `string`

beg pardon?

    
    
        $ js
        js> var s = 'foo';
        js> s['length'];
        3
        js> typeof s['length'];
        number
    
        $ node
        > var s = 'foo';
        undefined
        > s['length'];
        3
        > typeof s['length'];
        'number'

~~~
wingspan
Please read the whole post for context. I am talking about the type system in
TypeScript thinking that `l` is a string (which you can find out, for
instance, by hovering over the `var` keyword in Visual Studio), when in fact,
as you pointed out, it is a number. I assume this is because TypeScript caters
to the most common case of indexing a string to obtain a single character
(another string, basically).

------
swannodette
They've added type annotations to all of jQuery it seems?

[http://typescript.codeplex.com/SourceControl/changeset/view/...](http://typescript.codeplex.com/SourceControl/changeset/view/d397c54a55db#typings%2fjquery.d.ts)

------
eddieplan9
This is quite impressive technically, and I think the type-checking feature
alone can make it appeal to those making large-scale application in
collaborative development environment. I hope this inspires other similar
efforts. A quick run-down of features:

\- It's a superset of JavaScript. So there is no porting effort needed. (With
CoffeeScript, you do not need to port if you don't want to.)

\- compile-time type checking, like type erasure in Java's generics.

\- module support at the language level. It's very thin. It does not give your
AMD or CommonJS module, but you can easily hack around it.

\- class and inheritance support at the language level. The implementation is
very similar to CoffeeScript's.

~~~
wingspan
With reference to AMD and CommonJS modules, the spec has more info [1]:

    
    
      TypeScript implements modules that are closely aligned with those proposed for
      ECMAScript 6 and supports code generation targeting CommonJS and AMD module systems.
    

It also looks like you can consume CommonJS and AMD modules using familiar
constructs.

[1] <http://go.microsoft.com/fwlink/?LinkId=267121>

------
tlack
Weird that I didn't spot a friendly list of features.. seems to have some cool
ones, like a shortened function expression (from the doc PDF):

    
    
        (x) => { return Math.sin(x); }
    

and modules, which are implemented using the immediately invoked function
expression pattern:

    
    
        module M {
          var s = "hello";
          export function f() {
            return s;
          }
        }
    

Syntax seems more clear than CoffeeScript and tool chain will probably shape
up better. Looking forward to seeing this get some traction.

~~~
untog
I like the shortened function form. I played around with CS for a while before
going back to JS, but I do miss being able to do something like:

    
    
        var names = people.map((p) -> return p.name);
    

(or something along those lines). Funnily enough, it reminds me of C#'s LINQ:

    
    
        var names = people.Select(p => p.name);

~~~
wingspan
I've written a LINQ style library for TypeScript that allows you to write
something like this:

    
    
      from([1,2,3]).select(n => n * n).where(n >=2).toArray()
    

which outputs

    
    
      [4, 9]
    

Hoping to open source it soon.

Edit: typo, n * 2 should have been n * n, sorry for the confusion

~~~
spicyj
Have you used the popular library Underscore.js <http://underscorejs.org/>?
The equivalent to your code in Underscore would be:

    
    
        _.chain([1,2,3]).map(n => n * n).filter(n => n >= 2).value()

~~~
wingspan
I did look at underscore when figuring out how to design the library, along
with many JS LINQ variants ([http://ianobermiller.com/blog/2012/09/19/linq-
for-javascript...](http://ianobermiller.com/blog/2012/09/19/linq-for-
javascript/)).

It should be pretty straightforward to provide Underscore bindings for
TypeScript.

One big difference in the library I was working on is that it is lazy, and
modeled after .NETs IEnumerable. Whether this is a good thing or not, I'm not
yet sure.

~~~
sciolistse
I've made a lazy linq-like library for javascript in the past..

The problem i had was that the native array methods are rather fast while
function calls (for moveNext) are quite slow, so i couldn't get a whole lot of
speed out of it.

Newer javascript engines might be sufficient to offset that though.

~~~
wingspan
I tried to get around this by creating overloads of almost all methods when
you are operating on an array. `each` for instance, has a standard
implementation using moveNext, and then an array implementation using a fast
for loop. In some cases you could even drop down to native function calls.

~~~
sciolistse
Sounds reasonable. Could be better timing now as well, what with server-side
javascript having become popular. Good luck with the library!

------
tlrobinson
This looks great, but the IDE seems to be one of the key features, so we're
going to need something other than Visual Studio.

EDIT: they've got syntax highlighting for some other editors, but full
completion and error reporting is still needed
[http://blogs.msdn.com/b/interoperability/archive/2012/10/01/...](http://blogs.msdn.com/b/interoperability/archive/2012/10/01/sublime-
text-vi-emacs-typescript-enabled.aspx)

~~~
wingspan
The language support in VS is really great, and getting better with each
release. Go to definition, code outlining, folding, type information on hover,
intellisense; all these make writing code much less easier and error prone,
especially if you are used to writing in a language like C# or Java in a good
IDE.

~~~
tlrobinson
But does VS run on Mac OS X or Linux? Didn't think so.

~~~
wingspan
Ah right, misread your post. I was just commenting in general on the VS
support, you are right that it would not be as nice on other platforms.

------
ericcholis
Favorite part about this, I didn't know it was Microsoft until I scrolled
down!

~~~
lowboy
I had suspicions from their choice of styling and typeface.

------
MicroAndMacro
Sublime Text, Vi, Emacs: TypeScript enabled
[http://blogs.msdn.com/b/interoperability/archive/2012/10/01/...](http://blogs.msdn.com/b/interoperability/archive/2012/10/01/sublime-
text-vi-emacs-typescript-enabled.aspx)

------
alexanderh
What about debugging? Thats my biggest problem with coffeescript

How do they map errors thrown in the browser, to TypeScript code? If this has
things like classes and such, the relationship isnt always going to be 1:1 and
debugging can become a nightmare. Part of what makes javascript so great is
how easy it is to debug. All these "superset" languages that compile to
javascript fail hard @ debug support usually

~~~
munificent
Source maps[1] should help with this.

[1]:
[http://www.html5rocks.com/en/tutorials/developertools/source...](http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/)

~~~
alexanderh
This is cool and I keep hearing its coming to coffeescript soon, but just the
fact that the TypeScript website doesnt mention "debugging" or "source maps"
anywhere on the front page is disheartening. Its more important than anything
to me, yet its still just a "we'll get there eventually" priority for all
these alternative javascript languages.

I would think microsoft wouldnt want to release this until source maps were
tested, working and included as part of the language as a major bullet point
feature. These languages are nothing but a novelty to use in prototyping until
that happens. I'll never use any of these languages in my production
development workflow until proper debugging is available.

~~~
cnp
Language output is more important than SourceMaps. Coffeescript output is
substantially _harder_ to read than TypeScript, and personally I've never had
an issue tracking down issues. I'm looking forward to it, sourcemaps or not.

------
malandrew
Like someone else commented in the TC article about Typescript, this Resig
quote, changing "Google" for "Microsoft" is relevant:

    
    
      "Why is [Microsoft] putting time and effort into 
      changing JavaScript when the DOM is what needs fixing?"
    

<https://twitter.com/jeresig/status/124114331616026624>

~~~
munificent
Ironically, improving the DOM _is_ actually something we're trying to do with
Dart: <http://www.dartlang.org/articles/improving-the-dom/>.

~~~
malandrew
Those "improvements" really don't address what is wrong with the DOM. The
problem with the DOM isn't that it could use a more consistent API with better
interface naming.

The DOM simply is a poor abstraction for applications. For example, it doesn't
have a concurrency model and many modifications to the styling of individual
elements or changes to the DOM structure can cause repaints and reflows.

------
lukeholder
Can I write my TypeScript in coffeescript?

~~~
gfosco
One can never be too careful, apparently.

------
streptomycin
This seems similar to the type checking and optimization done by Google
Closure Compiler?

~~~
polarix
The main difference is that the Closure compiler compiles JS->JS, keeping all
the type info in jsdoc comments. Typescript makes the typing a first class
language entity, which reduces code portability (and toolchain flexibility) in
favor of (I assume) readability and maintainabilty.

Another huge advantage is that the typescript parser & compiler is written in
Javascript. Closure's jscomp is Java, which decreases backend portability
somewhat.

------
koops
I've written a lot of JavaScript, including large-scale projects, and never
once have thought, "Gee, I wish I had type checking."

Haven't we come to a consensus that types are more trouble than they're worth?
They hurt clarity and catch few bugs.

~~~
jakejake
I have a theory about this - how you feel about static typing is related to
whether you see the compiler as your friend or as your enemy.

If you see the compiler as your friend then you tend to like type checking
because it blocks certain bugs and typos. It won't let you run your code until
they're fixed. If you see the compiler as your enemy, as a barricade that you
need to get past, then you tend to not like static types. The compiler
prevents you from seeing your code running immediately.

Obviously there's other benefits to each system but I feel like this is the
more "gut reaction."

~~~
masklinn
> I have a theory about this - how you feel about static typing is related to
> whether you see the compiler as your friend or as your enemy.

An alternative explanation is a dislike of overly verbose languages with
terrible type systems (the poster child for this category being Java), and as
a result of low exposure to better statically typed languages painting all of
the category with a Java brush.

~~~
jakejake
probably true if people equate static typing to Java then they assume it adds
a lot of overhead.

------
andrewla
On a tangent, does anyone know anything about the in-browser editor they are
using for the playground? It seems really slick. The javascript references
something called "monaco" and the directories are all prefixed with "vs".

The code is hosted on their demo site; /Script/vs/editor/editor.main.js
appears to be the main js file and has this notice:

    
    
        /*!
            © Microsoft. All rights reserved.
    
            This library is supported for use in Windows Store apps only.
    
            Build: 1.0.8514.0.win8_rtm.120711-1900
      
            Version: Microsoft.WinJS.1.0
        */

~~~
wingspan
I believe the monaco editor is already being used in Azure Websites and
possibly the TFS preview. I wouldn't be surprised if more information about it
would be released soon, they are also a major dogfooder of TypeScript.

------
drcode
Back in the day, Microsoft would use a strategy called "embrace, extend,
extinguish." <http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish>

Recently, Microsoft has been pushing Javascript very hard (embrace) and now it
looks like they've started the "extend" phase.

Luckily, no one really worries about them being able to pull off the
"extinguish" part anymore... they just don't have enough market power these
days.

EDIT: Yes, I conceede the fact that TypeScript is OS probably addresses most
of these objections.

~~~
untog
Except that this is fully open source, which makes it a little difficult for
MS to retain control over it, no?

Re-reading late 90s M$ memes gets old after a time.

~~~
dj2stein9
Microsoft was so ruthless, and dominating in the 1990's that it will be
incredibly difficult to convince any developer that was streamrolled by this
company to give them a second chance.

------
kombine
Now I want to take an advantage of strict typing at runtime, which is
obviously not possible, because instead of standardizing a VM all vendors are
doing stupid things like this.

~~~
cek
I'm willing to bet MS has built runtime type support into the Chakra VM.

The question is whether they will do it in a propitiatory way or push it as an
extension of ECMAScript and try to get other VMs to implement it.

~~~
kombine
The worst thing is that they already have the runtime that is language-
agnostic, performant, has a great standard library and so on. When they tried
making it available on the Web, the so-called "open stadards" won. Which are
in fact a bag of shit.

------
luke_s
It seems the analyser to infer the types of your vars is fairly easily fooled.
The following code compiles, but prints out "Hello undefined":

    
    
      interface person{
    	firstname;
    	lastname;
      }
    
      interface apple{
    	colour;
      }
    
      function hello(p : person){
    	alert("hello " + p.firstname);
      }
    
      var aPerson = {firstname: "joe", lastname : "blogs"};
      var anApple = {color: "red"};
    
      var foo;
      if(true){
    	foo = anApple;
      }
    
      hello(foo);

~~~
wingspan
When you paste this into the Playground, and hover over the `var

------
DigitalSea
I will admit MS have impressed me here. The fact they've released TypeScript
under an Apache 2.0 licence and put the code up on CodePlex goes to show
Microsoft are making strides in the open source community. A big change
considering the mentality of MS used to be open source was unsafe and a threat
to their dominance in the software industry. The world must be ending: Apple
is starting to falter and Microsoft is climbing back to the top.

------
colin_jack
In case anyones interested, dart JS interop:

<https://github.com/dart-lang/js-interop/>

------
emillon
Very good idea. But note that these annotations are just hints : they are
enforced only in simple cases :

var x = "lol" - error found : <http://pastebin.com/R1wqp0CS> var x; x = "lol"
- accepted : <http://pastebin.com/0vc68RbY>

------
mykolasmith
Codeplex/samples/simple (<http://bit.ly/Svcc4Y>) is the same as the
CoffeeScript constructors doc section (<http://bitly.com/PnLtGy>)... Wonder
what other stuff they borrowed from CoffeeScript?

~~~
nagnatron
Maybe that's a good idea because it makes it easy to compare the two?

------
anuraj
Wholeheartedly support this thinking softie has no daggers hidden. The changes
do make the language more readable and maintaninable compared to the mess
called JavaScript. If the IDE is support is also there, this will be a no-
brainer.

------
Floopsy
(Wikipedia) “Some examples, like Dart, portend that JavaScript has fundamental
flaws and to support these scenarios requires a ‘clean break’ from JavaScript
in both syntax and runtime. We disagree with this point of view.” -
Microsoft’s JavaScript team

If Google comes out with Dart, well, then there's no need for that. But it's
ok for Microsoft to be secretly working on their own Javascript 2.0. Just
sayin' - Why criticize Dart when you've just come with almost the same thing?
:)

But snark aside, good job Microsoft. Well done.

~~~
BrendanEich
Also, no "JS will be replaced" threat, no proprietary native VM in IE-
prototype to advantage it over other browsers running TypeScript compiled to
JS.

But I agree it is another case of two-faced behavior, not in the way you
suggest. The IE blog post against Dart rejects a "clean break" and TypeScript
builds on ES6. That's consistent.

What is not consistent is how similar parts (but not all) of TypeScript are to
ES4, which MS opposed vigorously. Time has passed and ES4 had its own
problems, so bygones.

------
libria
It's good to see sharp developers like Anders Hejlsberg spearheading this. I
really hope this means we'll get LINQ sometime in the future; good to hear
generics are on the way.

------
iambot
I worked on a joke/conversion project a little while ago that achieves the
same ends without having to compile to JavaScript.

The only reason I wrote it was to prove to a co-worker who was "hating" on
JavaScript that it IS possible to have a type system in JavaScript - if that's
what you want. Its not the same end result but similar enough to warrant a
mention.

Here's the repo: <https://github.com/christopherdebeer/TypedFunc>

------
dogada
One of the key TypeScript features is not only the fact that JavaScript
program is TypeScript programs but also ability to add type annotations to
existing javascript libraries without changing of their source code. For
example, see port of Backbone's TodoMVC:
[http://typescript.codeplex.com/SourceControl/changeset/view/...](http://typescript.codeplex.com/SourceControl/changeset/view/d397c54a55db#samples%2ftodomvc%2fjs%2ftodos.ts)

------
jonny_eh
I was reading the synopsis on the page then it faded out and replaced it with
sample code. Geez, let me read and then scroll down. WTF is with the carousel
non-sense?

------
aaronblohowiak
They added static typing to javascript, except you can still pass a number to
a function that takes a string. In their example
<http://www.typescriptlang.org/Playground/> replace the

    
    
       new Greeter("World");
    

with

    
    
       new Greeter(5);
    

and it still works. What good is adding types to functions if they are
ignored?

~~~
glennsl
TypeScript will not abort compilation, but it will give you a warning. In the
playground, that would be the red squiggly line indicating an error.

------
zachrose
Would it not be just as reasonable to put type information in JSDoc, and build
a preprocessor that does the complaining?

------
charlieok
So they've set up a site for TypeScript but as far as I can tell, that site
hasn't got a blog. With so many projects vying for attention, subscribing to a
project's blog is my default way of keeping it in mind for later. If they post
interesting updates, I'll be reminded later to come back and give it a closer
look.

------
dogada
IMO Microsoft looks for web-developer loyalty because recent stupid policy of
big monopoly drive them to zero share on web-browser market. The only
remaining question: will IE10 support TypeScript or it will be added in IE11
only?

------
nnq
The only thing that I find "exciting" in the land of compiled-to-javascript
languages is LiveScript (<http://gkz.github.com/LiveScript/>)...

------
antidoh
I wish they had named it something else. typescript is the default output file
name for script(1).

<http://www.unix.com/man-page/Linux/1/script/>

------
SeanLuke
> The scope of a parameter, local variable, or local function declared within
> a function declaration (including a constructor, member function, or member
> accessor declaration) or function expression is the body of that function
> declaration or function expression.

This thing claims to be meant for "application-scale" JavaScript, and yet
doesn't repair even JavaScript's most notorious error?

A suggestion to the authors. Purchase this book:

[http://www.amazon.com/JavaScript-Good-Parts-Douglas-
Crockfor...](http://www.amazon.com/JavaScript-Good-Parts-Douglas-
Crockford/dp/0596517742)

... then go through the book with a fine-tooth comb, and every time it
describes something as a "bad part" or an "awful part", delete or fix that
misfeature in TypeScript.

~~~
AdamTReineke
Except then you would likely lose the attribute of being a superset of
JavaScript.

------
stalled
(for posterity, stray duplicate discussion with exactly the same url:
<http://news.ycombinator.com/item?id=4597724>)

------
euroclydon
What unit test framework are they using in the source? It looks like Jasmine
('describe', 'it') but then it has 'assert' and I can't find an include for
it.

------
jon6

        $ t
        command not found
    

clearly they could have named the compiler just 't' instead of the overly
verbose 'tsc'. all those extra characters!!

~~~
ndabas

        $ curl http://news.ycombinator.com/user?id=j
        No such user.
    

Clearly you could have named yourself just 'j' instead of the overly verbose
'jon6'. All those extra characters!!

~~~
jon6
Clearly you can't perceive sarcasm.

------
wicknicks
Looks really good. The IDE support looks like a big bonus. Wish this had been
released on a Friday -- have to wait a bit before I can dig deeper!

------
bilalq
Am I the only one experiencing sluggish scrolling on that site? Rather ironic
for a site boasting about application-scale development.

------
ww520
This looks very good enhancement on top of Javascript. Hope browsers start
bundling the TypeScript compiler natively.

------
bbayer
yet another language compiled to javascript. What is the deal with the adding
type system without doing runtime checks? Does it solve DOM manipulation
complexity or it just solve code readability problem? Does it worth to learn
new language constructs when you decide to begin low or middle scale projects?

------
dotborg
Reminds me about Turbo Pascal, I love it!

------
stuaxo
Hm.. classes, interfaces... reminds me of AS3; which of course MS stopped
becoming the next javascript.

Still - looks useful.

------
Zelphyr
The Google guys called. They want Microsoft to stop being jealous of the JS-
influenced turd that is Dart.

------
ilaksh
Not having to deal with types is one of the advantages of JavaScript. This
actually makes it worse.

------
buremba
I think javascript is awesome enough so it doesn't need any language
improvements. The only improvement over javascript is coffeescript and it's
just because its syntax nothing more else. take a look at this video from
google i/o: <http://goo.gl/BGvAS>

------
FreshCode
Could TypeScript be combined with the CoffeeScript syntax to save keystrokes?

------
clockwork_189
Seems pretty cool, but how does it compare to DART or does it even compare?

------
iamleppert
Why does everyone want to take all the nice features of javascript, it being
so loose and freeform and turn it into Java? I don't need interfaces and
classes built into the language. That's why it's so powerful and lightweight.
Prototypical!

People keep making the same mistakes, if you let them.

No thanks.

~~~
winteriscomming
Because these "loose and freeform" attributes make your life hell building
large applications with large teams.

------
devongovett
My thoughts on Badass JS here:
[http://badassjs.com/post/32674515997/typescript-
microsofts-n...](http://badassjs.com/post/32674515997/typescript-microsofts-
new-typed-javascript-dialect)

------
petegrif
MS answer to DART?

------
euroclydon
The compiler's written in... TypeScript!

------
Andi
For stuff like this, you use schema.js.

------
wensheng
No list comprehension? No, Thanks.

~~~
wingspan
Would be a good thing to suggest to the team, it is the first release of the
language, after all.

In the interim, a simple library like underscore is quite succinct:

    
    
      _.map([1,2,3], n => n * n)
    

With more library support you could even do infinite lists with something like
this:

    
    
      _.generate(index => 1.0 / index);

------
dreamdu5t
The lack of strong typing in JavaScript is a _feature_ not a bug.

------
mbq
Looks like all the bad features of Java and JS combined.

------
zoowar
lol: application-scale

------
dmorgan
Open Source? Node.js? Github? Javascript cross-compiler? ES6 based? Type
annotations?

This is the first sign that they are "getting" 2012 developers and are back in
the game with a vengeance. Hope it works.

Dart is mid-nineties MS by comparison.

------
camus
Funny how Microsoft refused ES4 because it came from Macromedia/Adobe ,yet now
it pushes a language that looks like its own JScript/AS3

------
pootch
MS has no credibility in this space. If you think slapping an OSS license on
their code gives them cred you must be some kind of fanboy. As for Javascript
- well, browsers still sucks, webapps still suck, and web development still
sucks. Javascript is a big part of that. 30%

------
init0
<http://i.imgur.com/XB3ib.png> Oh M$ Oh...

~~~
untog
You lost me at "M$". I'd like to think that HN's level of discussion is above
that.

~~~
cbaleanu
Nonetheless, interesting disclaimer text spotted there. Raises a good
question... would that text be there because somebody in the industry analyzes
your code?

~~~
lazugod
Are we reading the same thing? Code is _not_ sent to Microsoft.

~~~
cbaleanu
Exactly. But if one clearly states that, perhaps there are others in the
industry that do the oposite, iaw analyzing / scraping / calling home some
code.

Having that disclaimer makes them safe in case someone might notice that
_insert IDE / online editor here_ does that and rings the bell.

~~~
untog
I think it just means that Microsoft has overzealous lawyers.

