Actually, I find the main case for type systems in JS (no matter if flow or typescript) to be in-code documentation, with the added advantage that it doesn't inflate your code as much as JSdoc or similar syntax extensions do, so it doesn't break my reading flow.
For teams of more than 2-3 persons, I would definitely recommend using a type system. If you have an existing code base, flow with its powerful type inference and the ability to add type descriptions in comments (so you don't even need to change your build chain) will be the better choice in my opinion. If you have a new project, either choice is fine.
I'm a fan of Open Source and have a growing interest in serverless and edge computing. I'm not a big fan of spiders, but they're doing good work eating bugs. I also stream on Twitch.
The in-code documentation is great. I mention it indirectly, i.e. Intellisense. I might update the article to mention that point more explicitly.
Switching build chains is not really pertinent to this article as the premise is to use TypeScript. I understand though that the Babel ecosystem is what most are used to, so transitioning to the TS build chain could be a pain to some.
Thanks for your answer. About the in-code documentation: even if you don't use Intellisense, it helps: you can get an idea about how to use a library much faster with type annotations.
As about the transitioning Even if the legacy project doesn't use babel, but plain ES5, maybe with jQuery, you can still add some type comments like /* : string[] */ (or even let flow's type inference do its magic; it will usually cover ~50% of your project without you doing anything) and enjoy at least a bit of type safety without changing anything else.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Actually, I find the main case for type systems in JS (no matter if flow or typescript) to be in-code documentation, with the added advantage that it doesn't inflate your code as much as JSdoc or similar syntax extensions do, so it doesn't break my reading flow.
For teams of more than 2-3 persons, I would definitely recommend using a type system. If you have an existing code base, flow with its powerful type inference and the ability to add type descriptions in comments (so you don't even need to change your build chain) will be the better choice in my opinion. If you have a new project, either choice is fine.
Thanks for the feedback.
The in-code documentation is great. I mention it indirectly, i.e. Intellisense. I might update the article to mention that point more explicitly.
Switching build chains is not really pertinent to this article as the premise is to use TypeScript. I understand though that the Babel ecosystem is what most are used to, so transitioning to the TS build chain could be a pain to some.
Thanks for your answer. About the in-code documentation: even if you don't use Intellisense, it helps: you can get an idea about how to use a library much faster with type annotations.
As about the transitioning Even if the legacy project doesn't use babel, but plain ES5, maybe with jQuery, you can still add some type comments like /* : string[] */ (or even let flow's type inference do its magic; it will usually cover ~50% of your project without you doing anything) and enjoy at least a bit of type safety without changing anything else.