
Announcing TypeScript 1.0 - kjbekkelund
http://blogs.msdn.com/b/typescript/archive/2014/04/02/announcing-typescript-1-0.aspx
======
bilalhusain
The typescript playground[1], which lets you try TypeScript in your browser,
looks so professional and finished when compared to CoffeeScript[2] or
Dart[3]. As someone who attempted a half-baked Rust to JavaScript
transpiler[4], I am floored with the packaging of TypeScript (tutorials,
specs, editor integrations, npm, playground). At the moment, the only missing
feature that my jealousy could point out is autoscrolling (see lexer example
in my demo)!

By the way, is playground using v1.0?

[1]
[http://www.typescriptlang.org/Playground/](http://www.typescriptlang.org/Playground/)

[2] [http://coffeescript.org/](http://coffeescript.org/) (Try CoffeeScript
tab)

[3] [http://try.dartlang.org/](http://try.dartlang.org/)

[4] [http://bilalhusain.com/rust-
lexer/syntax.html](http://bilalhusain.com/rust-lexer/syntax.html)

~~~
couchand
I don't think any of them are very polished or professional.

The CoffeeScript site reports errors unintuitively yet visibly in the top-
right corner. The TypeScript site requires that you scroll right to the error
and then realize it's not just your browser complaining about a misspelling.
But both are better than the Dart sandbox, which basically only says "error".

None of them get page layout right. Dart and TypeScript have obvious
input/output boxes, but both get demerits for their handling of overflow. Dart
just grows the box which is acceptable, but TypeScript thinks their customized
scroll bars are better than native. CoffeeScript handles overflow reasonably,
but it's a big translucent overlay causing all sorts of moire on my screen.

I suppose if you're on a Windows computer you might be tricked into thinking
the TypeScript page looks reasonable, since it probably fits in. For me,
though, I'm having a hell of a time figuring out what's a button and what's
not.

~~~
bilalhusain
I hope the respective developers are listening. It should be noted that most
of these 'try X' editors are not marketed as a product, but I do agree that
calling it 'professional' was mistake. The warts show up during heavy usage of
a tool (the overflow example) and I was quick to reach conclusions based on
the first impressions. But all the features like completion, line numbers,
syntax highlighting do deserve respect (I couldn't find a better executed
alternative!).

Also, confirming that I am on a Windows computer :)

~~~
xixixao
The Try it for CoffeeScript was meant to be extremely simple, not to replace
JSFiddle and such. The errors will be moved to the output area in next
release. Someone might get around to implementing proper editor into it (say
CodeMirror). That said, MS has people they pay for developing TypeScript,
CoffeeScript is just of bunch of folks who enjoy working on the compiler and
helping others. You certainly shouldn't expect the same level of secondary
effort as in Dart or TypeScript - yet I think CoffeeScript is doing great on
this front.

~~~
roryokane
I described some details that would help implement a rich code editor (like
CodeMirror) in Try CoffeeScript in this issue:

“Use rich code editor in Try CoffeeScript on coffeescript.org” –
[https://github.com/jashkenas/coffee-
script/issues/3076](https://github.com/jashkenas/coffee-script/issues/3076)

I’m glad to hear that compile errors will finally be displayed in the output
area in the next release ([https://github.com/jashkenas/coffee-
script/pull/3425](https://github.com/jashkenas/coffee-script/pull/3425)). If
anyone feels like improving that interface even further, they could try
implementing the mockup in this issue:

“Highlight code errors and move error message in Try CoffeeScript” –
[https://github.com/jashkenas/coffee-
script/issues/3077](https://github.com/jashkenas/coffee-script/issues/3077)

------
keyle
I am huge believer in typescript. This has made me consider html5 seriously
for the first time.

There are still many dark spots (hello js scope, bs standards), but with
Typescript I've already built stuff I could have only done AIR in the past.

I find it ironic that MSFT tried to compete with Flash with Silverlight (and
failed I think), and to me, Typescript means end of the line for Flash/AS3.

The language is dead easy to pick up, and IntelliJ has been a really good IDE
with it.

Highly recommended.

------
radicalbyte
We've been using TypeScript for 9 months now on a large project. It's
fantastic. There's now way I'll go back to pure JavaScript again.

The type system just catches so many defects, and they're of the kind that are
hard and boring to find (typos).

Plus IntelliSense integration (including jsdoc) is great.

On the downside, our project takes some time to compile so we had to build a
tool to do it incrementally. Plus it doesn't play well with one-class-per-file
structures (but I expect that to be fixed).

~~~
axefrog
Agreed, TypeScript is great, but the compiler is excruciatingly slow. I have
to segment my app into multiple sub-build areas and only build a subset at a
time, which is annoying because I frequently end up making small changes
outside of that subset of code. My app is only around 25000 lines of code and
a full compilation still takes around 50-60 seconds which, in a JavaScript
workflow, is a lot of friction.

~~~
rplnt
I was expecting something in the order of minutes. Seeing as I work at a place
where full build used to took about three hours on a server. I see how it's
not ideal though.

~~~
prawks
In a typical Javascript workflow, near-instant feedback is the baseline.

I really like how Facebook's Hack has a local file system monitor which
incrementally compiles on file changes. I haven't used it yet, but it sounds
like a nearly ideal compromise.

~~~
rictic
Typescript has a command line option for this as well.

As far as I can tell, the language would also support a non-validating mode
that would be more or less instantaneous (the transformations it performs are
all local, and none of them involve knowledge of the types involved).

~~~
prawks
Neat, I'll need to look into that.

------
skrebbel
Most significant announcement IMHO:

> _Today, we 're announcing that we will begin taking pull requests for the
> TypeScript compiler and language service._

A relatively-flagshippy MS project becomes truly open source. This is awesome!

~~~
jeremiep
You're required to sign a CLA before you can contribute and they only accept
pull requests for bugs.

Nothing prevents you from forking, but the main repository doesn't look 100%
free.

~~~
nimish
CLA's are good practice in general. It's always up to the maintainers whether
they want feature requests.

And as you pointed out, you can always fork.

------
sytelus
Having spent quite a bit of my dev life with typed languages and now coding a
LOT in pure JavaScript, I'm actually not at all thrilled by TypeScript. Yes,
pure JS is bit hard to maintain and it does occasionally pisses me off but at
the same time it is liberating.

Not having to constantly keep adding types all over, not having to constantly
refactor things because I now accept object instead of an int etc is
refreshing. And best of all, not having _compile_ at all is fast and simple.
I'm only using JS frameworks that doesn't force me do build before testing the
page and retains purity of JavaScript (that means no simulations of
traditional OOP). Yes, sometime I do make bad mistakes and spend some time
chasing down bugs that would have been caught in typed languages. However
overall I find cost of adding types all over and maintaining them over the
evolution of code is actually higher. It would have been really great if they
had produced cool algorithms that could have inferred types as much as
possible and added it as static analysis tool instead of JS extension.

Just because JS doesn't have type checking I'm now set in to mindset of doing
quick tests of small changes, write more elaborate tests and so on. Even in
moderately large project I think pure JavaScript is not only _maintainable_
but also joy to work with compared to typed languages.

~~~
klibertp
I don't know very much about TypeScript, yet, but I'm doing some research and
I'm going to advocate it on my next project. From what I already know:

> Not having to constantly keep adding types all over,

TypeScript is gradually typed (which means it's happy with as little or as
much type declarations as you want to give to it) and uses type inference,
which reduces amount of needless type declarations even more. Actually, coming
from C and later C++ to Python and JavaScript I thought the same as you, that
type systems are a complete PITA. I then learned OCaml and I changed my mind:
_bad, archaic_ type systems _are_ PITA, but modern and powerful ones are a
huge help and incur little cost.

> and retains purity of JavaScript

That's like saying that you're not using any Scheme library which implements
convenient exception handling and you use bare call/cc instead.

Prototypal inheritance in JavaScript is strictly more powerful than most of
the class based systems, but it _is_ less convenient to express some common
idioms using just what's built-in. This is why you're going to implement some
kind of object and meta-object protocols on top of prototypes sooner or later.
It makes sense to agree on a standard way to do it, otherwise you're just
going to add _yet another_ slightly incompatible object system. I agree that
there are many cases where prototypal inheritance is enough, though, and you
shouldn't use classes by default in JavaScript.

> adding types all over and maintaining them over the evolution of code is
> actually higher

I have vastly different experience here. Types tend to make refactoring rather
easier than harder. It's because when you change a return value or expected
argument of some function you don't need to grep for all its calls in the
codebase - the compiler will tell you. With sufficiently good type system, the
compiler will tell you if the new type is compatible with the old one, which
makes writing adapters easier. And it all happens on compile time, which means
you don't need to run your app to test it. I read that TypeScript compilation
is slow - that may be, but I bet it's comparable to running all the unit tests
for a project, for example.

> It would have been really great if they had produced cool algorithms that
> could have inferred types as much as possible and added it as static
> analysis tool instead of JS extension.

Yeah, I agree, I'd like it too. I remember there being a very cool project
from some distinguished JS developer which did just that; it was an editor and
a supporting library for checking and validating JS code. I can't remember
what it was, exactly, though... Help, anyone?

> Just because JS doesn't have type checking

As I said, it's not either-or situation. Gradual typing is one thing,
contracts are the other. You _can_ have the best of both worlds. After a few
years I'm still amazed with Racket and Typed Racket combo - it's exactly the
right mixture of compile-time and run-time support for ensuring program
correctness and I would like to have something very similar in JS one day. In
the meantime, TypeScript is a step in the right direction. I only hope it will
continue to evolve after 1.0 release.

~~~
shaneofalltrad
I have performed QA tasks on both, and find that either JS developers are
better or going pure vanilla makes a much stabler product. The TypeScript
projects I have seen had some major flaws and requests (vs bugs) always turned
into low priority because of the inability to perform the task.

~~~
klibertp
I think it's easy to explain: TypeScript is a new technology and programmers
will have very little experience in using it. It's completely impossible to
find "TypeScript programmer with 5 years of experience" for example. On the
other hand, JS is stable and much older and you can easily assemble a team of
highly experienced people.

Relative strengths and weaknesses of TypeScript will be only visible after
it's around long enough to get its own best practices and experienced
programmers. I see the same process with CoffeeScript - in the beginning
average CS code was much worse than average JS, but now they are comparable
and the advantages of CS are starting to be visible.

That's of course on average. It's still possible to get a few people with
enough knowledge to be able to use TS effectively, but I think it's hard
enough to make it very rare. It's unfortunate, but technologies - and
especially languages - take very long time to mature. In short, your
impression is probably correct, but it's not because of TypeScript features;
we need to wait a few years before we can compare TS and JS products success
rates.

------
girvo
Anders is my favourite language designer, ever :)

TypeScript is something I'm still trying to get more buy-in from my team, but
the issue is the lack of decent autocomplete/static analysis in anything other
than Visual Studio. I'm working on that problem myself, actually.

~~~
chadzawistowski
IntelliJ supports TypeScript!
[http://www.jetbrains.com/idea/webhelp/typescript-
support.htm...](http://www.jetbrains.com/idea/webhelp/typescript-support.html)

~~~
DCoder
From past experience, their support is good, but one significant thing I
missed was type inference:

    
    
        // function signature
        getNumber(context: any, callback: (result: Number) => void);
        
        // calling that function
        // unfortunately, here the type of num is any
        // unless I specify it manually
        getNumber(..., (num) => { ... });
    

Visual Studio figured out the type on its own.

------
toggle
It'd be great if there was a compiler that would compile TypeScript to asm.js
[0]. Adding type-safety in TypeScript is only for the programmer -- when you
compile it to Javascript, you don't get any performance increase. But, if you
could compile it to asm.js, you'd actually get some performance increase out
of it. (Note: I don't know much about TypeScript or asm.js, so if what I just
said is completely untrue, I'd love to know why.)

[0]: [http://asmjs.org/](http://asmjs.org/)

~~~
Touche
asm.js requires you to manage your own memory. TypesScript doesn't, it's a
pretty thin layer on top of JavaScript.

~~~
fractalsea
Care to explain why?

To my understanding asm.js is a restricted subset of JS that allows for
optimisations to be performed that would not otherwise be possible. In a
similar way to how Java bytecode can be interpreted more efficiently compared
to a non-compiled language, like Python.

With that in mind, sure you could target asm.js with a high level language
that requires memory management, but why couldn't you also target it with a
language that assumes GC. JS interpreters have this GC component built in
already. Essentially I don't see how it is different from Java + Java bytecode
+ the JVM, which does perform GC.

I'm very curious about this.

~~~
azakai
asm.js is a subset of JavaScript, and to be easy to optimize, it removes most
of the dynamic stuff from JS and leaves a simple, low-level dialect that is
basically equivalent to LLVM IR or to C.

You can compile many things to C and LLVM IR, like C++, C#, and so forth. You
can compile the VMs of dynamic languages like Python, Lua and Ruby, but
compiling them directly would be inefficient - you'd need type checks all over
the place. You need a custom VM to be fast on those.

asm.js can run Lua at close to the speed of the normal Lua VM running
natively, so this approach is very feasible. But, for JavaScript itself, it
probably doesn't make sense, the current VMs are the best that can be done.

However, a subset of TypeScript - without classes, without weird prototype
things, just arrays and numbers and computation on those - could be compiled
to asm.js. That might be an interesting project to try out.

~~~
fractalsea
OK, so are you saying that compiling the language's runtime environment,
including the GC, to asm.js would not be efficient enough? That makes sense.

I guess I was hoping that there may be some way to compile the runtime such
that the GC wouldn't need to be compiled, and the GC of whatever is
interpreting the asm.js code (e.g. SpiderMonkey) could be used instead.

~~~
DougBTX
That's roughly what happens when TypeScript gets compiled to JavaScript, it
can use the browser's GC. asm.js is used to avoid the browser's GC, either
when the original code doesn't need a GC since it uses manual memory
management, or it uses a different type of GC from the browser and wants to
use that instead (which is effectively the same thing).

------
jbm
Could someone be so kind as to explain why I should consider Typescript over
Coffeescript in future projects?

I've been using CS for the past year or two, but I'm hearing a lot of buzz
around TS for the past few months. It would be really nice to have a better
idea as to why it should be best to move now - is it really that much better?

(I love the CS tools available on PyCharm; they really made my life easier.
That said, I think that there are similar TS tools available as well)

~~~
untog
One reason (as I see it) is that TypeScript is implementing ES6 features along
with the type-specifc stuff, so it's going to end up in a place where it's
very compatible with the 'future' of JavaScript.

CoffeeScript will always be something quite different. I love it, but that
difference makes me nervous. ES6 ought to bring a lot of the features I like
about CoffeeScript into JavaScript.

~~~
tkubacki
I don't want to troll here but "very compatible" sounds like MS best days of
EEE - Typescript still IS a different lang. Question is what if future
Javascript will go in a different direction than todays Typescript ?

Typescript main feature is tooling but I would rather go with lang where I'm
not second class citizen on non-windows (eg. Dart's editor works on
Windows/OSX/Linux)

~~~
nightski
Do you really feel JavaScript has that luxury? Seeing as how widely deployed
and used it is I feel that it can't go in a completely different direction
anytime soon.

~~~
tkubacki
Not JavaScript, but Typescript. What if Typescript will implement _now_
features incompatibile with future JS ?

------
egeozcan
Am I really missing it or are they announcing a new version with no release
notes?

edit: it seems that they had them in the blog post for the release candidate
[http://blogs.msdn.com/b/typescript/archive/2014/02/25/announ...](http://blogs.msdn.com/b/typescript/archive/2014/02/25/announcing-
typescript-1-0rc.aspx)

~~~
shadowmint
There are a few little new things, but 1.0 is essentially bugfixes from the
0.98 release which was essentially feature complete.

New things (eg async) are further away on the roadmap:
[http://typescript.codeplex.com/wikipage?title=Roadmap](http://typescript.codeplex.com/wikipage?title=Roadmap)

------
bprater
The article is light on 'What is Typescript'. Can someone explain what
TypeScript is?

~~~
lmkg
It's a compile-to-JavaScript language, like CoffeeScript. Differentiating
features:

\- Strict superset of JS. All(?) JS is valid TS, making it easier to migrate
to TS.

\- Many of the added features are from EcmaScript 6, i.e. JavaScript Of The
Future. TS lets you use those today, instead of waiting for browsers to
implement.

\- (Optional) type system, which some people are fans of.

\- Much stronger tooling & IDE support, in part due to the typing.

~~~
mfn
Also, compiling down to human-readable and well formatted JS has always been a
priority. So it's never difficult to migrate away from typescript, since the
typescript can simply be replaced by the compiler's javascript output.

IIRC, this is actually one of the main reasons they're holding off on
implementing async/await, since that would require the compiler to convert
functions into unreadable state machines.

------
dkarapetyan
Anders is a really good language designer. Everything this dude touches turns
to gold. He was also behind C# and as far as enterprise languages go C# is a
joy to work with. TypeScript is the same way. It's all really well thought out
and instead of getting in the way the type system actually helps because you
can leverage the dynamic aspects of JavaScript during the prototyping phase
and then gradually add types as the design is fleshed out. Typed Racket I
think is the other language that gives you similar capabilities but I haven't
played enough with that one to have an opinion yet.

~~~
oscargrouch
Linq _(cough)_

Delphy _(cough, cough)_

~~~
efdee
Is there anything wrong with LINQ that we are not aware of?

~~~
Kutta
I guess it's not wrong, but not designed by Anders.

------
brokenparser
The language is nice, but the compiler uses its own lib.d.ts which has all
sorts of definitions for browsers and even proprietary MSIE ones. This doesn't
make any sense when using TypeScript in any other context (like Gjs, NodeJS,
Rhino, Seed, etc.). TypeScript shouldn't assume a browser by default, or at
least provide an option for compiling without lib.d.ts.

~~~
wereHamster
$ tsc --nolib

~~~
brokenparser
Ooh, undocumented features! How nice, thanks =]

------
bsaul
This project really is the greatest thing that could happen in computer
science : a great mind trying to solve a problem in the most pragmatic yet
elegant way to achieve the greatest possible benefit for developper with th
minimal amount of time and work.

~~~
keithwarren
A little strong on hyperbole.

Less Flair version - Happy to see a well know and respected computer scientist
trying to solve a problem faced by lots of developers and doing it in a simple
and easy to understand way.

~~~
bsaul
Agree. I wanted to put some emphasis on the fact that technologies with modest
goals, but well executed, may in fact achieve more than grand masterplans.
After more than 15 years of coding I came to realize that focusing very
strongly to your true needs and nothing more, is really a quality met only by
the very advanced.

------
RazvanPanda
TypeScript IRC channel: irc://irc.freenode.net/#typescript

------
pingec
edit: The talk has ended now. Will update if I find a link to that talk.

Anders talking about TypeScript live:
[http://channel9.msdn.com/](http://channel9.msdn.com/)

~~~
BlackMonday
[http://video.ch9.ms/sessions/build/2014/3-576_LG.mp4](http://video.ch9.ms/sessions/build/2014/3-576_LG.mp4)

------
benawabe896
I always get voted down for this, but I still feel that typescript is an
answer to a question that nobody is asking. (I'm also very suspect of all of
the positive comments. Is HN really this pro-MS for JavaScript?) In my
company, we literally have a typescript counterpart team doing the same
projects. Our code is cleaner, better architected, and our team is able to
consistently produce 2 to 3 times more features. In my experience, the teams
that choose typescript are usually windows devs that cannot wean themselves
off of visual studio due to their dependence upon auto completion and IDE
tools. I'm not hating, I just don't understand why any js dev would add code
to their code.

~~~
ternaryoperator
> In my experience, the teams that choose typescript are usually windows devs
> that cannot wean themselves off of visual studio due to their dependence
> upon auto completion and IDE tools.

Well, since VS does auto-completion with JavaScript too, so maybe you're not
understanding the whole situation. Some people like TypeScript for its ability
to facilitate creation of large projects via addition types, classes, and
namespaces, while retaining much of the basic JavaScript syntax.

------
silentrob
I was really hoping it would have a lib style compile api, but it seems fairly
locked down. :(

------
mauriziopd
How does it stack with dart?

------
dewiz
typescript at stackoverflow
[http://stackoverflow.com/questions/tagged/typescript](http://stackoverflow.com/questions/tagged/typescript)

~~~
cicloid
any leads on what should we be seeing?

~~~
ehsanu1
Stack Overflow questions and answers on TypeScript I assume..

------
jokoon
I thought it was a font.

I was just opening MSVC expecting an update, looking in the font configuration
menu and everything...

