Glad someone finally wrote a post about this. Coming from the lisp world, that's the thing I constantly see missing from languages wrapping javascript. They generally change the syntax a bit, add a few features to minimize boilerplate in some areas, and call it a day. Why would I want to learn a new syntax to program in a language I already know well? Unless you give me the tools to write code that writes code, I'm not going to bother learning/using a new javascript syntax.

At least TypeScript brings to the table something very valuable: optional type checking.

And sweet.js macros can be used to implement the type system of your choice in otherwise stock Javascript. (For that matter, you could un-overload the + operator so that it only works with numbers, and invent a . operator to do string concatenation.)

I can see a potential argument that doing type checking via macros costs more than precompilation in efficiency terms, but on the other hand, that's not necessarily so. How does TypeScript do type checking for non-constant values? That is, if I define function foo(bar: string) in a TypeScript library, then compile it, load the library in a Javascript interpreter, and call foo(Integer.parseInt("42")), what happens? I'm guessing that either foo() misbehaves, or that foo() throws an exception.

In the former case, there is no benefit to TypeScript because your type annotations are evanescent and misleading -- you can't rely on them, so you either have to write fences around input values just like you would without them, or risk your code misbehaving because it's written to rely on unreliable type annotations.

In the latter case, TypeScript is adding those fences automatically, so that a function which expects an integer argument can check whether it actually got one and fail if it didn't. That's basically what a macro system implementing type checking would do, too, and it seems to me that in both cases optimization would be merely an implementation detail.

It's not practical to implement a type system using macros. The problem is the software ecosystem. First of all, I don't think sweet.js macros can implement a full type system like TypeScript has which can load type definitions from other files, do type inference and support interface definitions.

Secondly, it's difficult to get a community around a single type system. Thirdly, it's difficult to get IDEs to support these sweet.js macro type systems.

The fact is, a sweet.js macro type system which is widely in use and supports everything TypeScript has and is supported by many IDEs doesn't support, and is unlikely in my opinion, if not technically impossible. In theory it might work.

If you compile TypeScript and then call it using JavaScript with the wrong type the code will misbehave. It's a downside, true, but a dynamic type checking system written in JavaScript would be too costly. Sweet.js macro type system wouldn't bring any benefit in that regard either.

You can rely on TypeScript type checking to make sure your code is correct. Similarly, if you develop in JavaScript, you can use unit tests instead of type checking to make sure your code is correct. Unit tests nor type checking can't guarantee that other code is correct, even if that other code happens to use your own code.

The benefits of TypeScript's type checking include the elimination of a class of unit tests, automatic refactoring, full intelli-sense support, better readability and automatic documentation (which doesn't remove the need of manual documentation).

You should have a look at Typed Racket [1] which is a type system for an existing language (Racket) built entirely with macros [2] that satisfies all of the criteria you want -- works with the IDE, safe interop with untyped code, etc.

[1] http://docs.racket-lang.org/ts-guide/ [2] http://www.ccs.neu.edu/racket/pubs/pldi11-thacff.pdf

There's also TypedClojure (https://github.com/clojure/core.typed) which is based on Typed Racket (is what I read in previous discussions about it here).