The biggest win that flow has - and for me puts it over typescript - is that it has comment decorator syntax.
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.
That's a very common position, but my experience shows me if the comments are not in line with the code that is usually a very good hint that the code will be buggy. It probably has been changed in such a hurry that the comment was forgotten, which doesn't bode well for the code quality.
You're not wrong, but comments are bad practice because they allow you to write code you have to explain in a comment. In my opinion comment-less code works really well with SOLID because it forces your developers to code clean and decoupled.
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.
Counterpoint for me: V8 source code. It's well written, and easy to follow when you know what you're looking at. But some comments would greatly improve the discoverability for new contributors.
> That's a very common position, but my experience shows me if the comments are not in line with the code that is usually a very good hint that the code will be buggy.
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.
> 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.
Can't you do the same thing with TypeScript's typings?
With TS you can only do the latter. The first one has the advantage that it's legal Javascript, thus not requiring a compiler.
Since typescript is set-up purely as a compiler anyway I'm not sure it would be a useful feature for them.
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.
Not equivalent - the TS compiler currently does not actually enforce the types in a JS file. See https://github.com/Microsoft/TypeScript/issues/4790#issuecom... The feature of parsing JSDoc comments is currently only used for providing completion info for JS editors and for consuming exported JS functions and variables in TS files.
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.
> no messing around in a different but similar language
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.
You mean like how it breaks ES6 classes semantics by making members enumberables? Whoops (I know, if you look at my comment history I used that example all the time...but it's just such an easy one).
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)
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.
Wait... are you saying that TypeScript's ES5 output doesn't conform to the ES6 standard??? Why would that matter? There's no standard for it! I thought you were saying that TS -> ES6 was not valid ES6.
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.)
The difference is actually somewhat subtle, but is shown here under class/enumerable. Same deal about classes requiring new (a lot of libs actually have bugs for only testing against compiled classes with older Babel and using .apply on classes): https://kangax.github.io/compat-table/es6/
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.
> what if further JS will intersect with TS syntax
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.
You want to have your cake and eat it, too. You've just argued for both viewpoints (TS is bad because it does X and because it doesn't do X).
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.
What? I want TS to be different lang transpiled to JS or be annotation to JS but it is: Embrace and extend existing Standard (superset) and when everyone will write TS it will come to Extinguish step. (I like C# and don't like Windows my like not like to MS tech is 50%)
Microsoft is on the Javascript standards committee. So is Google, which is using TypeScript heavily in Angular 2.0. I would expect that TypeScript and JavaScript are going to continue to be harmonious.
It's very likely that JS will adopt some things tried initially in TS. Both TS and Babel have implemented extensions to the class syntax, for example, which are being considered for JS-future.
Actually TypeScript powers a JS editing experience codenamed "Salsa" that uses JSDoc comments for types. You can try it out in VS Code where it should currently be enabled.
Give that a shot if you're looking into that sort of workflow.
JSDoc is verbose, not inline, not directly associated with the code and not very friendly to use, as well as having a large maintenance overhead..?
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?)
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.