By the way, is playground using v1.0?
[1] http://www.typescriptlang.org/Playground/
[2] http://coffeescript.org/ (Try CoffeeScript tab)
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.
Also, confirming that I am on a Windows computer :)
Compilation errors are attributed to the place where they occurred and highlighted there with a red underline. Actual error is displayed on hover.
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.
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).
interface Person {
firstname: string;
lastname: string;
}
function greeter(person: Person) {
return 'Hello, ' + person.firstname + ' ' + person.lastname;
}
var user = {firstname: 'John', lastname: 'Doe'}
document.body.innerHTML = greeter(user);
This. at least the js one. Maybe VS is bundled with a Typescript compiler written in C# , i dont know,but clearly the javascript one is damn slow.
Although it's more of a patch. A proper IDE for JS would be neat, but it'd need to support popular DI frameworks and the like.
I've not yet ported my Angular apps to Typescript but I'm very much itching to do so.
Misspelled magic strings, which were replaced with enumerations.
We also had a number of bugs with unexpected type use - like a function which expected a boolean but was given a string, or even more common number/string failures.
> 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!
Nothing prevents you from forking, but the main repository doesn't look 100% free.
And as you pointed out, you can always fork.
license: Apache License 2
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.
> 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.
You will see that joy quickly fade away in enterprise projects.
I've seen multiple examples of "enterpisey" web apps, and there was no joy, just because developers didn't know how to build a good application with JavaScript and even more - they didn't care at all.
With a "don't touch anything that works" mindset that lots of enterprise developers have - you write write-only JavaScript code and when it becomes too large - of course, there is no joy in touching this kind of codebase.
Every enterprise project with a in-browser front-end needs a good front-end developer from the start to set up good code, good practices and good attitude to a front-end part of the code, and it will be fine: the joy won't fade away.
You don't have to if you don't want to.
>not having to constantly refactor things because I now accept object instead of an int etc is refreshing
Again this is your choice, you can omit types if you want
TS gives you the option to add typing if you want it. And that is huge in my book, try refactoring a large enterprise app written in JS vs. written in TS.
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.
// 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) => { ... });
[0]: http://asmjs.org/
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.
You could, however, use the type annotations part of the asm.js spec to take advantage of the fact most js runtimes are going to be attempting to optimise the heck out of them.
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)
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.
The TypeScript language team has yet to prove that they will track the specs and implement features as spec'd. I think claiming that they will "implement ES6 features" is a bit pre-mature. So far, they have implemented a few drafts and ignored a few others. A mixed bag.
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)
- Typescript is a superset of Javascript (mostly), so we ported by converting all the Coffeescript sources to Javascript and renaming them with .ts extensions. There was a bit of cleanup involved in getting modules to play nice together, but most of the code ran without modification.
- The JS that the Typescript compiler generates is much easier to read, in part due to less "magic" in the language.
- It also makes performance much easier to reason about, for the same reasons. One issue that bit us several times was Coffeescript's auto-return feature, which was invisibly accumulating large arrays of values from our interpreter's bytecode loop! This is no longer a concern with the current Typescript codebase.
- The inner workings of the JVM are fairly complex, so enforcing types at compile-time actually does catch bugs before they happen.
Is just your regular js, but with some stuff added like type
check, classes, interfaces and some cute operators, just the
language that most know with some goodies added to help
with development, that is and that all, in oppose to CS that
is just syntatic sugar with others cute tricks that make the
language more appealing to people like you (assuming by your
post that you are a python developer). So if you are into JS
or type check then you should give TS a try, if not then
just stick with CS, only you can answer is changing
transpiler in your workflow is gonna make your life easier.
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...
New things (eg async) are further away on the roadmap: http://typescript.codeplex.com/wikipage?title=Roadmap
- 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.
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.
Delphy (cough, cough)
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.
Anders talking about TypeScript live: http://channel9.msdn.com/
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.
I was just opening MSVC expecting an update, looking in the font configuration menu and everything...