

TypeScript 0.9 – What’s Improved - remotesynth
http://flippinawesome.org/2013/10/21/typescript-0-9-whats-improved/

======
embwbam
I feel so productive in Typescript. I remember the feeling I got when I
realized how powerful the type system in Haskell was, and how useful it was at
catching mistakes. Every once in a while I read an article about Haskell and
think I should get better at it, then I realize that Typescript is really the
best of both worlds. It turns JavaScript into this awesome productive language
that can scale to large projects.

~~~
magicalist
I like Typescript too, but this is a little over the top. Typescript's typing
is nowhere near as expressive as Haskell's is (nor was it ever intended to
be). I think of it more as a nicer way of doing Closure Compiler-like
annotations plus you get a built in transpiler for many of the handier es6
features.

edit: oh, and tooling, but I'm not normally on Windows for development so I
haven't played much with the Visual Studio integration.

~~~
seanmcdirmid
Typing isn't just about catching type errors, but about semantic feedback
useful for tooling. Unless you are using Haskell, then its just about catching
type errors.

~~~
tikhonj
That's really unfair to Haskell. What are things like Hoogle if not tools,
uniquely[1] enabled by _Haskell_ 's type system? All the basic IDE-like frills
exist too, if you really want them. And now, with the advent of deferred type
errors and holes, Haskell's type system is getting even more interactive. The
process is quickly moving from writing code and running it through a compiler
to having an ongoing conversation with the typechecker as you build up your
program.

More importantly, types can go well beyond catching errors or tooling. Types
can actually make your code _more_ expressive and they can push your design
forwards.

For the first, the simplest example is with Haskell's typeclasses: you can't
easily write something like Show or have something like Haskell's flexible
numeric literals without types. This allows you to grow[1] Haskell in ways
that are even difficult in Lisp! For a more practical standpoint, I've found
certain libraries to be much harder to reproduce without typeclasses, most
crucially QuickCheck.

The second idea is slightly more abstract. As somebody else put it, types are
like gravity sources: we place them strategically in our design space, and the
rest of the code falls towards them. More concretely, coming up with the types
to represent some domain often really helps in writing the code for it.
Sometimes, once you've got the general framework of the types, the actual
programming just feels like systematically filling in the blanks. More
generally, the effect is nowhere near that pronounced, but the types do help
shape everything else. In a sense, types help you constrain the set of
possible programs at the outset, giving you fewer options to consider as you
go along.

Oh, and I guess there's the performance thing. This includes both low-level
optimizations (C++ or even C-style stuff) and high-level ones (like rewrite
rules). Optional type systems seem to give up on these as a matter of
principle. I don't believe static types are strictly _necessary_ for good
performance, but empirically they seem to help. Most languages with really
good compilers are statically typed.

I think the idea that types just exist to catch type errors is one of the most
unfortunate common misunderstandings about type systems. It really scares
people away before they can learn about all the other benefits a good type
system confers.

[1]: Okay, not really _uniquely_ , but it's close. I've seen Hoogle-like tools
for OCaml but not for Java or C++, much less something like Python. I'm not
sure how useful or general they could be for other languages.

[2]: Easily my favorite CS talk:
[http://www.youtube.com/watch?v=_ahvzDzKdB0](http://www.youtube.com/watch?v=_ahvzDzKdB0)

~~~
seanmcdirmid
I saw Growing a Language in person in 1999 (he redid the talk during Utah's
yearly Organick lecture). As for your arguments about Haskell, I find this
very useful; thanks for the reply. I am quite interested in type systems for
tool purposes, and grocking whether even code completion is possible for
Haskell is quite a chore. Hoogle is exactly the tool I'm competing with :)

------
johnny_reilly
My team has been using TypeScript since 0.9 was released. From our perspective
it's been a great win. It's greatly eased the refactoring of our JavaScript.

The thing that's been really nice is the ability to write a certain amount of
ES6 style code (eg using arrow functions to lexically bind the this value) and
having the TypeScript compiler transpile that into ES5 / ES3 JavaScript.

I really like it. I think the tooling is still a little rough but it's still
in Alpha so that's fair enough I guess. It'll improve.

------
jolt
I think typescript is such a good idea. And generics is a great addition.

The only thing I dislike about TS is the way it handles dependencies. The
require/declare/import/export methodology confuses me. And on top of that
there is the //<reference /> tag, and all of it seems to be relying on files,
rather than on constructs in the code. Relying on files, means that I have to
maintain the order of which to import what, and this becomes even harder if
some of the files contain code that is not just module/class definitions, but
actual statements in global scope.

~~~
embwbam
One of the major problems with JavaScript has always been that there are too
many options. I feel like TS reduces some, but it still lets people choose
between a module pattern (AMD, CommonJS), and the traditional everything-in-
the-global-scope way of writing programs.

So you're left feeling confused because there is more than one way to write a
program. Options are good and all, but in the front-end Javascript community,
I think we could deal with fewer of them.

To solve your own problem: I would recommend using CommonJS with Browserify
for everything, and only use reference tags for ambient declarations. (.d.ts
files). Then you'll always use import and export

------
mode80
The best recent development in TypeScript IMHO is there's now a usable Sublime
Text plugin that makes code completion and other goodness available outside
Visual Studio. [https://github.com/Railk/T3S](https://github.com/Railk/T3S)

~~~
haxorize
The Sublime Text plugin is making use of typescript-tools [1] which also has
support for vim and emacs.

[1]: [https://github.com/clausreinke/typescript-
tools](https://github.com/clausreinke/typescript-tools)

------
michaelwww
After using TypeScript for awhile, I really can't think of a reason not to use
it. I haven't read anyone else express a reason not to use it. If it ever
turns out to be a problem, then I can just switch over to working on the
JavaScript output and dump the TypeScript front with almost zero effort. I did
some refactoring the other day and it became clear that TypeScript is a tool
that makes life easier and there probably is no good reason not to use it.

------
pingec
If anyone is using typescript, there is the unofficial channel #typescript on
freenode. Would be great to have more people to discuss TS with.

------
pavlov
Is TypeScript a superset of JavaScript? Or is there valid JavaScript that
doesn't compile in TS?

~~~
michielvoo
Superset[1]

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

~~~
pavlov
Thanks!

Is there a guarantee that TS will remain a strict superset?

Looking at the syntax, it reminds me of Flash ActionScript, which started out
as an ECMAScript implementation but became an incompatible superset that
pretended to be JavaScript compatible but would whine endlessly about untyped
_var_ declarations...

Hopefully ActionScript and C++ will serve as warnings to TypeScript designers:
if you're ever thinking about disrupting code compatibility with the original
language in the name of added type safety, don't do it.

~~~
johnny_reilly
My understanding is that the TypeScript team intend to TypeScript to always
remain a superset. If you watch the various videos with Anders talking about
it then that comes across pretty clearly.

------
Jare
Regarding noImplicitAny, I find the choice of a compiler option rather than
source code markup (like "user strict") rather odd. Granted there's no
standard way to do that, but still...

~~~
jol
why? compilers for other languages has compile time switches for various
checks and/or optimizations, there it is assumed normal. Javascript's "use
strict" is just a hack for lack such option. This has some benefits, i.e. you
take some codebase that must compile with noImplicitAny and want to add some
features, you start with less strict typing (implicit any allowed), when
finished you compile with different flag. Because ide (most people use) is
recompiling the code all the time there is no reason to clutter this when
prototyping. If you don't like this workflow, just use the flag from step 1.

~~~
Jare
My understanding was that NoImplicitAny changes the rules of the language, so
its use will make it harder to move code from projects that rely on it to
projects that don't. Traditional compilers opt for a rich set of warnings and
the ability to turn any warning into error. On closer inspection, it seems
that code developed with NoImplicityAny should work 100% on projects without
that, so my concern was unwarranted.

