Earlier quoted context omitted.
Can you explain the difference between Flow's approach and plain JSDoc 3?
Flow's type system is infinitely more powerful. It's proper static analysis. Tern, as an example, can only do so much.
[deleted]
Flow vs. Typescript
21–30 of 158 posts
Re: Flow vs. Typescript
#22Both differences in this presentation are addressed in TypeScript 2.0
Re: Flow vs. Typescript
#23Earlier quoted context omitted.
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.
Re: Flow vs. Typescript
#24The 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 pr…
> 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.
what if further JS will intersect with TS syntax ? IMO Typescript is "no go". We need clean break with transpile step (eg. Dart) or annotations.
Re: Flow vs. Typescript
#25So today is typed JS day? https://i.imgur.com/XAEeEFm.png Guess it's time for the question then... I haven't dived into this whole types thing yet so could someone provide a TLDR about either Flow or TS being opinionated and their impact on an established toolchain? I have no intention of changing half of my tooling just to be compatible with what fb thought would be a good idea, and even less so for ms. A build step…
Sublime TS support is top notch https://github.com/Microsoft/TypeScript-Sublime-Plugin
Re: Flow vs. Typescript
#26Earlier quoted context omitted.
> 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.
what if further JS will intersect with TS syntax ? IMO Typescript is "no go". We need clean break with transpile step (eg. Dart) or annotations.
> 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.
Re: Flow vs. Typescript
#27Earlier quoted context omitted.
> 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.
what if further JS will intersect with TS syntax ? IMO Typescript is "no go". We need clean break with transpile step (eg. Dart) or annotations.
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.
Re: Flow vs. Typescript
#28The 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 pr…
> 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?
No. With flow you can do both:
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*/ = ""`Re: Flow vs. Typescript
#29I like very much the last slide and the author's recommendation. Helpful and better than the admonitory 'yes you should use typed JS':
- if your project does not live for long: no
- if your project is really simple: no
- if there is a chance you will need to refactor the thing: yes
- if your system is very important or even crucial for the success of your company: yes
- if people enter or leave your team frequently: yes
Re: Flow vs. Typescript
#30I like very much the last slide and the author's recommendation. Helpful and better than the admonitory 'yes you should use typed JS': - if your project does not live for long: no - if your project is really simple: no - if there is a chance you will need to refactor the thing: yes - if your system is very important or even crucial for the success of your company: yes - if people enter or leave your team frequently:…
> - if people enter or leave your team frequently: yes
Interesting, I would put that one as a no, since introducing TS to you project means longer time train new employees. On the other hand it will make sure their commits break something less often, so not so sure about this one