File size

File size

File size

File size

File size

786.2 MB

Anders Hejlsberg, Steve Lucco, and Luke Hoban join us for a casual chat about - what else - TypeScript. Why did they do it? What's the backstory? How is TS related to Dart and does it really aim to solve the same problems? What's wrong with JS, anyway? Does TS extend JS or is it just a design time tool that adds semantic structure where there is none? What about ECMAScript 6 - won't that release of JS have modules and classes? Is Anders still working on C#? TypeScript and Windows Store HTML5 apps.

As usual, this is a conversation and as such just happened as it did. Tune in.

So will JQuery or other libraries used in combination with typescript supports tooling????? I guess it wont because these are already type less.Is there a reverse compiler to converted JQuery to Typed JQuery sothat tools and IDES can make use of these libraries from IDEs with typescript.

@Vineel Kumar Reddy Kovvuri: From what I've seen, there are these declare files (plain old JS files) that provide type hints for common libraries that light up the awesome tooling. I believe there's already a declare file for jQuery. Also, if there's a declare file not available, it's pretty straight forward to role your own.

@Rubbish: I'm curious why you compare this to CoffeeScript. I love CoffeeScript but I don't really see any comparisons. TypeScript gives you modules and classes, maybe that's it. I think that TypeScript gives you more than that, especially if you're using the VS tooling that comes with it. I use a Mac and roll my code in SublimeText 2, so tooling support is as of yet non-existant, but using something like Guard and LiveReload it should be pretty straight forward to get some large application work done with TypeScript that might even surpass what I've done with CoffeeScript by way of productivity and maintainability. I'm thinking especially how CoffeeScript gets muddled when spread across a large number of files or, heaven forbid, we have a massive single file of CoffeeScript. How often have you run into an issue related to incorrect indentation level or methods that look like they just run together? I think TypeScript will help with this.

I like the approach that TypeScript is taking in principal, but I have to be honest and say that there is zero chance this will ever be used by anybody in the enterprise without javascript source maps, because I simply CANNOT convince anyone to take these *-to-Javascript tools seriously without source map debugging support. Why wasn't this included from day 1? Chrome has had a working implementation of source map debugging for months, and the source map specification was available for months prior to that. FireFox has a beta plugin for it, but has generally expressed interest in supporting the same specification. IE of course doesn't, but maybe that's just Not Invented Here syndrome?

Also, I wish TypeScript were a "superset of a subset" of javascript, rather than a strict superset. One of the benefits of CoffeeScript (and 'strict mode', if it were properly enforced) is specifically that it breaks from JavaScript in many ways, eliminating some of the "javascript bad parts" and restricts you to just the good parts. For instance, as far as I know, all CoffeeScript code that compiles cleanly automatically passes JSHint/JSLint checks. I think if you took the type annotations and modules from TypeScript and added them to the CoffeeScript syntax, along with the Visual Studio integration with intellisense and live error checking, I think THAT would be a better language than either of them individually.

Also, can we get you guys to push on the IE team to support source maps? DO NOT invent your own source map standard PLEASE - just use the standard that Chrome and FireFox are adopting. Additionally, something that's been on my wish list for a while is the ability to remote debug javascript in the browser, so that Visual Studio or Eclipse could hook into javascript code running in the browser and then implement its own debugging interface (using the same source maps, but with a more tailored debugging interface, perhaps with better watch expression parsing or visualization).

With that capability, you could implement a Visual Studio debugger extension for TypeScript running in IE that would let you you do breakpoints, step-by-step debugging, and watch visualization *IN* TypeScript (of course you could switch back and forth between typescript and javascript views).

@SleepyDaddySoftware: You stepped on a NIT of mine. What standards are you talking about. The Mozilla proposal is NOT a standard. If Microsoft implemented their own source mapping it would NOT be a standard. I could forgive you calling either of these a defacto-standard (though one could always argue about what constitutes defacto-standard status), but so much meaning is lost by web devs when they continually talk about things like they are standards when they are not.

There's a reason the mozilla source mappings are in draft. Ignoring their existence would be wrong, so I mostly agree with your sentiment. However, that doesn't entirely preclude the possibility that the draft either needs tweaking or even may need to be thrown out for an alternative design... it just means such direction should include documented reasons and be submitted as a competing proposal.

That said, you're quite correct that source mappings should be a high priority feature to add here, and the goal should be to use the draft proposal for the feature.

For most of the talk it seemed like TypeScript was merely a more expressive and semantically rich way (than say special comment styles) to inform a JSLint like tool (the TypeScript compiler) about permissible use of language features... until Anders said "optionally statically typed..." (at ~34:10). Does that mean the TypeScript compiler can optionally emit runtime type checks to enforce conformance?

@wkempf: In principle I agree with you. In practice however, it would be disastrous if IE came out with a completely incompatible specification, no matter what the reasoning. Projects like CoffeeScript and Script# do not have the time or resources to put into multiple source map generators. Then web developers will be faced with the problem that their tool of choice only generates source maps for chrome, but not for firefox or IE, or the other way around. Or, compiler writers will simply forgo source map compilation altogether because nobody can agree on a specification. The best case scenario is that they are similar enough that one could write a tool to translate a source map from one format to another, but that could result in a loss of information.

So, it would be better for all stakeholders involved if IE implemented the google standard, or else worked with both google and the Mozilla team to improve the standard together before implementing it, possibly even formalizing it into a web standards body proposal together. In this ecosystem, there is only room for one specification, so it's better to work together on it and not introduce a competing format just for the sake of inventing something in-house.

@SleepyDaddySoftware: Boy, did you miss the point badly. "So, it would be better for all stakeholders involved if IE implemented the google standard" There you go again. There is no standard. None. There's a draft proposal, but no standard. This is an important distinction.

Everything else you said I've already said I'm in total agreement on. TypeScript should have source mapping, and that source mapping should be (barring compelling reasons otherwise) based on the existing draft proposal. If the existing proposal falls short for some reason, first the proposal should be tweaked before abandoning for an entirely different proposal. That's how standardization processes work.

Just wonderfull! What a nice Christmas gift this year :-) I am finally motivated again to learn HTML5 and node.js development using something on top of JS, which after each try demotivated me by natural unreliability of any JS dev env. I trust Anders from his begin in TurboPascal era, everything he does is almost genial. And if C# .NET (which was also more about common type system than anything else) helped only to MS followers, this next big thing will save all almost mad JS devs around the world, as its open source - and, so, Anders and his team have my vote for Turing or Nobel price now :-). Hope this all will be ASAP baked into LightSwitch HTML5 clients too and used as general purpose embedded scripting language for plugins of many apps. So, my langspec is already printed .... thanks again :-)

Obviously there are advantages to TS being a very thin layer over JS, so the output code is recognisable (having tried it the results are very impressive I think).

The main difference here is improved tooling enabled by static type declarations. What does that remind me of? The "concepts" feature that was originally mooted for C++0x. Like a lot of people, when I first read through the C++0x feature list, I weeded out the stuff that compiler implementers would do last (or possibly never bother with). And concepts stuck out like a sore thumb. And sure enough it got dropped from the eventual standard.

TypeScript is a very similar project, in that it overlays a system of declared structural typing over an existing system that already works okay without it, with the aim of improved tooling.

Yes, TS adds classes and modules, but (as the examples show) it doesn't really need to do very much to implement those. They are easy patterns to follow. (Okay, classical inheritance gets tricky when you start inheriting implementation, but most modern OO books warn against doing that too much anyway.)

The => syntax is nice, but I'd class that alongside CoffeeScript - not interesting in itself, because all it does is make the code "look" pretty in the most superficial possible sense (to me, it's already pretty in the sense that matters!) I wouldn't turn down => as part of a bundled deal, but it's not a deal-maker in itself.

Having played with TS for a day, it's a beautiful demonstration of how static typing is a genuinely valuable productivity tool. And this implementation of it is unusually good (it already appears to be better than Java and C#, due to the underlying structural nature, as opposed to dumb nominal typing).

But at the same time, over the last couple of years I've found it quite possible to build large, complex, modular applications in JavaScript. It's already workable. Static typing would be luxury, but I can get by without it.

However, the number one, constant, irritating pain is the lack of support for continuations in the language. Fix that somehow in TS and I will jump at it like a starving leopard. (Async/await, or even just the yield keyword as implemented in Mozilla).

Then the static typing and other bits of sugar will be a fantastic bonus.

I think TypeScript has a very bright future, assuming MS is not going to dump it in couple of years.

It is not limiting to use plain JavaScript, when you need you can constrain yourself and get rich tooling support and on top of that it is Open Source, so I expect many contributions from the community.

Actually one of the reasons I didn't like JavaScript is of the poor tooling. I agree with Anders that tedious things should be delegated to the machine.

It would also be interesting to see some Windows 8 examples on TypeScript.

Remove this comment

Remove this thread

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.