This means I can just write JavaScript and add comments for types. No transplier step, no messing around in a different but similar language, no additional complexity, just easy.
It's inferred types are a much stronger system imo too - gets out of a developers way more.
Typescript is great, but I really do prefer Flow in every metric.
Maybe in this case it doesn't matter very much but there are a lot of ways comments can get lost or messed up.
I've yet to be in a "oh this bit needs a comment" moments where the code couldn't be improved significantly to make it both better and more understandable.
I also had the "pleasure" to work in a few projects where it wasn't even on the list, beyond a few powerpoint presentations.
An example might help but to me bad code is code that repeats itself which includes comments. To me, comments should only be used for high level explanations (e.g. architecture, algorithms, public API) and when the purpose of code is non obvious (e.g. weird bug workarounds, optimisations). The vast majority of comments can be removed by rolling their contents into better function and variable names.
Can't you do the same thing with TypeScript's typings?
var x /*: string*/ = ""
var x : string = ""
A disadvantage could be that it's easier to make silent errors by making syntax errors in the comments. I don't how Flow would handle e.g.
`var x /* number*/ = ""`For example:
/**
* @param {string} a
* @param {number} b
* @returns {string}
*/
function foo(a, b){
return a + b;
}
function foo(a: string, b: number): string {
return a + b;
}
But not functionally identical when it involves my fingers typing (the function there being my ergonomics). Flow would just be inline comments at the code points required.
TypeScript would be a disaster if it subtly changed the semantics of JavaScript. It doesn't, though. It's a superset, so it's really not a "different but similar" language. It's the same language with more features, and the compiler is a great guide to using those features.
When comes the time to pick between shinier output and correctness, TypeScript is perfectly happy to diverge from JavaScript, until it really has no choice (eg: when it moved to ES6 modules)
Edit: This is seriously driving me nuts that I can't find anything about it. I hope you see this and respond because I'm incredibly curious!
Look at what is the output for the following code:
class Cat { talk() { console.log('meow'); } }
It's something along the lines of:
var Cat = (function () { function Cat() { } Cat.prototype.talk = function () { console.log('meow'); }; return Cat; }());
The methods in that output will be enumerable. They shouldn't be. The reason is (most likely) that the output for non-enumerable class members is TERRIBLE (try the same thing on babel's "Try it out" page), thus why Babel provides loose mode. Still, it's the kind of very subtle things that can bite you in the rear big time.
Then again, if you have good unit tests and move those over too, it won't be a problem I guess :) Also most likely not a problem if you use ES6 as the compile target.
Also, properties set on the prototype will fail propertyIsEnumerable() and also hasOwnProperty(). for..in loops should always be filtered by hasOwnProperty() in any sane code base anyway.
(I tested the TS output for that class in Node 5 and my own browser, and the property did not come up in the loop, so I just don't think this is an issue in reality.)
And all I was saying is that the spouting of "TS is a superset of ES6!" is not that simple, since most usage will be (for now) with the ES5 output, where it isn't compliant in subtle ways that do cause problems/bugs. Nothing more :)
Obviously there's even cases here TS is compliant and Babel is not. Babel will call those bugs instead of spouting their compiler has no compromises like a lot of the comments here try to imply to convince people.
Oh so I can just run it in a browser without transpiling? No? Ok then, not the same language: so it's.. different but similar.
A core value of TypeScript is to support the latest ES20xx standard. The TypeScript team pays attention to JavaScript proposals. In the unlikely event that JavaScript got a type system, it would almost definitely be either TypeScript or Flow. If it wasn't, or if ES standards overlapped with TS syntax, then TS would remove that syntax.
Also, if you don't like the next version of TS, you can just use the old version to transpile your code and then stop using it. Switching to TS is an easily reversible decision, whether it's 1 day or 1 year later.
> We need clean break with transpile step (eg. Dart) or annotations.
You can already have this with Scala.js or any of the other languages that compile to JS. TypeScript is one option among many.
The appeal of TypeScript is that it fixes some things about JavaScript rather than throwing the language away. That's useful because it allows teams to transition from one to the other gradually. Facebook had to do the same thing with PHP, so they created Hack.
So there is no hard promise of TS backward compatibility ?
Sorry but whole TS looks like another EEE - MS will/can argue on some further JS changes for/against based on existing TS codebase. I hope I'm wrong here though.
Just be honest and recognize that you dislike Typescript and/or Microsoft. Nothing to be ashamed of, many decisions in tech are based on feelings as much as on cold, calculated decisions.
Give that a shot if you're looking into that sort of workflow.
oh god... shivers... ;)
No, that sounds neat but I loathe JSDoc/JavaDoc derived formats. Good idea for someone else though!
I mean... that all applies to JSDoc/JavaDoc syntax before I compare it to Flow anyhow.
Flow's comment system is inline - right next to the code you're writing. It's very clear exactly what it refers to and it's easy to use. Plus it's not TypeScript: it's JavaScript, just with comments.
TypeScript is great, but it is what it is and that is not JavaScript (a superset, sure, but C++ is a superset of C, so what?)