TypeScript and the Road to 1.0

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

by smokel • 13 years ago

112 89 13 years ago

blogs.msdn.com

clone10183• 13 years ago

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.

haxorize2• 13 years ago

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.).

k3n4• 13 years ago

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.

egeozcan• 13 years ago

Well, maybe you are mixing it with Google's Traceur-compiler?

https://github.com/google/traceur-compiler

nawitus3• 13 years ago

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.

clone10183• 13 years ago

I think that's the point, there is no difference between TypeScript and Node.js Modules.

nawitus3• 13 years ago

So how should I use a TypeScript module like typescript-collections with Node.js? If I don't add /// <reference path>, intellisense doesn't seem to work, but if I add /// <reference path> and import, I had some errors too.

1. https://github.com/basarat/typescript-collections

outside1234• 13 years ago

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...

nawitus3• 13 years ago

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

chrisoakman2• 13 years ago

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.

xtrumanx3• 13 years ago

...also we added the class keyword so you don't feel lost

I believe EcmaScript 6 plans on adding the class keyword and TypeScript's implementation reflects the current draft of how classes in ES6 will work.

...statically typed languages make it easier to think about your program...

Out of curiosity, do you normally program using statically typed languages?

If not, I can see why you would be underwhelmed. Then again, I shouldn't be surprised by your reaction. This is Hacker News and TypeScript is by Microsoft.

chrisoakman2• 13 years ago

Not a huge fan of the class keyword in ES6 either...

I do not use statically typed languages and I have nothing against MSFT; I was solely commenting on TypeScript as a language.

k3n4• 13 years ago

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.

clone10183• 13 years ago

While it's not my opinion, I did read this quote somewhere:

"CoffeeScript is only syntactic sugar. It brings very little new to the table, but perhaps worse of all, it doesn't really fix all of JavaScript's WTF-issues while adding a few of its own. While it's an improvement over JavaScript, its advantages are sometimes outweighed by the extra hassle to compile and deploy it"

agilebyte• 13 years ago

CS is aimed at making you more productive, TS is aimed at making you more correct, checking errors early.

Just my observation.

judah2• 13 years ago

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.

ahoge10• 13 years ago

[TS and CS] both basically solve the same problems

TS (or Dart) makes JS more toolable and thus more scalable. CS, on the other hand, just offers a keystroke reduction by dropping the "function" keyword, semicolons, and other punctuation.

TS and Dart also reduce the number of keystrokes though. They allow you to auto-complete pretty much everything.

sanxiyn2• 13 years ago

Well, value proposition is error messages and code completion, not "make it easier to think about your program". You may argue types don't help people much, but types do help tooling. (Not in the sense being untyped causes some tooling impossible, but in the sense being typed substantially reduces tooling implementation effort.)

Touche5• 13 years ago

This. TypeScript is a tool to sell Visual Studio, nothing more. If people are leaving VS because it can't do the magic things to JavaScript that it can to C# that's a big thread to Microsoft. TypeScript is about protecting the thing that makes them money.

jeswin2• 13 years ago

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.

sanxiyn2• 13 years ago

Optional typing works. Why wouldn't it?

gregwebs2• 13 years ago

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).

awj2• 13 years ago

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.

rictic2• 13 years ago

I've used typescript on a few projects now. What I've seen is that when first hacking on some code I use almost no types. Maybe some are inferred, and that's nice, but if not whatevs. As I'm playing with the code though, like when I'm re-reading a function or if I'm trying to debug something, I'll often add in types to see if the compiler can point anything out.

In practice this has meant that code that doesn't change much but is called frequently is fully typed, while code that's under more active development is less typed, unless it's tricky.

I've only just started playing with the noImplicitAny setting, where the compiler complains loudly about any identifier that it can't figure out a type for. Not sure what I think of it yet. I'd kinda like something that lets me do a targeted noImplicitAny, but it might be enough to just do it at the file level (i.e. these files should be fully typed, these files shouldn't).

tomlu• 13 years ago

Depends on what you mean. It doesn't spread in the same way that const correctness spreads in C++, i.e. once you add const somewhere you are forced to add it to a bunch of other places as well.

10098• 13 years ago

I'd rather have tests than types.

Why? Let the compiler do the testing for you.

ahoge10• 13 years ago

Does optional typing really work?

From my experience with Dart, I'd say it can work really well. Basically, if you just put type annotations at the API boundaries, you already get most of the type related benefits you would get with something like Java or C#.

Inside your functions, you can generally omit types. For the tools, there is enough type information floating around to make sense of everything.

If you use a literal, the type is known. If you use some annotated function, the type of the return value will be known. If you assign any of these things to "var", the actual type will be remembered. This means you get sanity checks, call-tips, and auto-complete without having to annotate the types there.

Putting types at the API boundaries also acts as documentation. It's so much better than writing JSDoc comments. Plus, you get all the benefits right away. It's a very sweet deal.

laureny• 13 years ago

I'd rather have tests than types.

False dichotomy.

You want both and you need both.

kibwen• 13 years ago

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• 13 years ago

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

kailuowang• 13 years ago

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()

judah2• 13 years ago

FWIW, there is talk of adding async/await like features (C#, Python) to TypeScript in a post 1.0 release.

apaprocki• 13 years ago

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• 13 years ago

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()); });

masklinn• 13 years ago

it's the lack of language syntax support for asynchronous programming

    spawn(function*() {
        var ra = yield async_opA();
        var rb = yield async_opB(ra);
        yield async_opC(ra, rb);
    });

This works right now in Gecko: http://taskjs.org/. Something very close ought work in ES6/Harmony.

L8D• 13 years ago

I think the one think that TypeScript needs to get it going is modularity. If another project like [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).

dangoor2• 13 years ago

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...

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.

james-manning• 13 years ago

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?

TypeScript and the Road to 1.0

Related Stories