I'm using WebStorm mostly but I'm not "married" to any particular IDE, I've used others and I switch around relatively easily.
I'm doing a slightly different programming style when it comes to types: I don't use "no types" or TypeScript or Flow, but I do use "types", sort of. What I've done is JSDoc the hell out of my code. There is not a variable without a JSDoc or Closure compiler type annotation. Those are all just comments, so I don't need to "Babel" my code. Since I'm using the latest node.js and only those ES 2015+ features that it happens to support that is enough.
It works because the IDE (WebStorm) uses the JSDoc comments to infer types, and the IDE itself provides the equivalent of what something like Flow or TypeScript wold do.
Well - to a point. I'm not really satisfied. I always keep submitting tickets for WebStorm, and while they have solved a lot there still are too many fundamental issues with how they infer types. For example, I get offered object properties from files I don't even include in the file I'm in, not even indirectly! For example, "mocha" might have an internal (!) variable somewhere that has a property "data". Since I have a property "data" too I get the definition inferred from that mocha file, which makes no sense, since a) I'm not even in a test file that includes mocha, and b) even if I was, that is an internal variable that's not exported.
They don't seem to be able to solve this issue, and with new EAPs I often get two steps back for very hard-fought step forward. To be honest, I believe their code for inferring types in Javascript is just too messy, it seems each time they plug a hole it doesn't last long and two new ones appear.
However, when I try VStudio it seems that I only get type inference if I use TypeScript?
I would be open to using "Flow", but I really, really don't want to have a different language. I just want types and standard Javascript! Yes I know TypeScript appears pretty much the same as ES 2015, but it still rewrites my code. I would not mind, except that there really is no reason at all since ES 2015 has everything I need (I don't use classes or even prototypical inheritance, no inheritance at all, only composition and functions).
From my limited research the best albeit not quite satisfactory solution for my case still remains only WebStorm? I mean, if they fix the problems introduced with the EAP version a few weeks ago when all JSDoc based type suggestions stopped working I can live with that state.
It would be nice though if I could have a "comment based type system" (JSdoc/Closure compiler) or Flow. How would VStudio do in this scenario?
Still, I don't want to use TypeScript for the reasons I wrote. I'm as minimalist as possible, and I don't want to use a language that changes my code to something else without any gain for me since I can write exactly what I want in ES 2015+ already. So it's just those types, and I could get them from "Flow" too and in that case keep my ES 2015+ code. Yes I know TypeScript is very close to ES 2015+, but I never know when it does change the code unless I look at the transpiled result.
EDIT: Actually, I did know that, looking at that page I remember why I dismissed it:
> Note any tags not listed explicitly below (such as @typedef, or @constructor) are not yet supported.
But that is something I make heavy use of. It would be really messy if I wasn't able to introduce "custom types" even in my limited "IDE based static type system".
> I don't want to use a language that changes my code to something else
TypeScript doesn't change your code. If you're writing ES2015 code and targeting ES2015 emit, the output code is always exactly what you put in. There isn't any difference.
Right, most of the code changes Typescript performs are the equivalent of babel plugins: the closer you write to the target output version of the language the fewer changes there between the input/output. The further back compatible you try to target the more "polyfills" and reconfiguring Typescript needs to do to support the older versions of JS.
Most of Typescript's output changes when you are writing for the same version of JS that you are outputting are simply just removing the type hints from the final output.
That said, with allowJS "mixed" mode of Typescript now you can also try for a hybrid approach of JS and TS files in the same project and that hybrid approach gets more powerful and capable with each release. I think with some effort you can even get somewhat close enough to the point that you can have some Flow-like behavior by using JS for most files and .d.ts and .ts files for only the really type-dependent stuff.
Also you could just add types to your JavaScript code with TypeScript and nothing else; the result of running through the TS compiler is just the same code with the types removed.
I'm using WebStorm mostly but I'm not "married" to any particular IDE, I've used others and I switch around relatively easily.
I'm doing a slightly different programming style when it comes to types: I don't use "no types" or TypeScript or Flow, but I do use "types", sort of. What I've done is JSDoc the hell out of my code. There is not a variable without a JSDoc or Closure compiler type annotation. Those are all just comments, so I don't need to "Babel" my code. Since I'm using the latest node.js and only those ES 2015+ features that it happens to support that is enough.
It works because the IDE (WebStorm) uses the JSDoc comments to infer types, and the IDE itself provides the equivalent of what something like Flow or TypeScript wold do.
Well - to a point. I'm not really satisfied. I always keep submitting tickets for WebStorm, and while they have solved a lot there still are too many fundamental issues with how they infer types. For example, I get offered object properties from files I don't even include in the file I'm in, not even indirectly! For example, "mocha" might have an internal (!) variable somewhere that has a property "data". Since I have a property "data" too I get the definition inferred from that mocha file, which makes no sense, since a) I'm not even in a test file that includes mocha, and b) even if I was, that is an internal variable that's not exported.
They don't seem to be able to solve this issue, and with new EAPs I often get two steps back for very hard-fought step forward. To be honest, I believe their code for inferring types in Javascript is just too messy, it seems each time they plug a hole it doesn't last long and two new ones appear.
However, when I try VStudio it seems that I only get type inference if I use TypeScript?
I would be open to using "Flow", but I really, really don't want to have a different language. I just want types and standard Javascript! Yes I know TypeScript appears pretty much the same as ES 2015, but it still rewrites my code. I would not mind, except that there really is no reason at all since ES 2015 has everything I need (I don't use classes or even prototypical inheritance, no inheritance at all, only composition and functions).
From my limited research the best albeit not quite satisfactory solution for my case still remains only WebStorm? I mean, if they fix the problems introduced with the EAP version a few weeks ago when all JSDoc based type suggestions stopped working I can live with that state.
It would be nice though if I could have a "comment based type system" (JSdoc/Closure compiler) or Flow. How would VStudio do in this scenario?