- When typescript came out, I was an early adopter, and a lot of it's touted benefits were the class-like syntax and constructors to make it more palatable to enterprise shops (not for me, but it was easier to sell to higher ups), this is mostly a moot point now.
- flow can be attached to any codebase as the codebase stands easily. It is, I have found, difficult to bring TS into an existing project.
- flow fits nicely into existing popular js tooling, mainly babel and react.
- no risk of vendor lock in. Maybe TS compiles to pure 100% syntactically correct javascript today, maybe it doesn't in the future. It isn't javascript, so I won't know.
At the risk of probably repeating myself, allow me to give my $0.02:
> - You are writing javascript, not typescript.
Flow's and TypeScript's distance to JS world are the same, and are very similar in most cases. If you want to add type to one, it's the same as in the other. The only difference here is the file extension, since TS tends to like .ts/.tsx.
> - When typescript came out, I was an early adopter, and a lot of it's touted benefits were the class-like syntax and constructors to make it more palatable to enterprise shops (not for me, but it was easier to sell to higher ups), this is mostly a moot point now.
True, although IMO the greatest feature of TS is making your code stronger, not compiling things that are already part of some ECMAScript version.
>- flow can be attached to any codebase as the codebase stands easily. It is, I have found, difficult to bring TS into an existing project.
True, with TS it's more of a lateral move rather than drops here and there.
>- flow fits nicely into existing popular js tooling, mainly babel and react.
TS works just as well; better, IMO, because dev tools (editors, linters) have better TS support in my experience. Writing React in JS to me makes me feel like I'm using Notepad since there's so much TS helps me with that is lost when using a purely dynamic language.
>- no risk of vendor lock in. Maybe TS compiles to pure 100% syntactically correct javascript today, maybe it doesn't in the future. It isn't javascript, so I won't know.
It does compile to pure JS so ejecting TS is easy; it's trying to follow future standards and proposed changes, not create something different; the project is open source. There is no vendor lock in.
There's a few subtle things here. Flow does support annotating types with comments, and can type check React's flowtypes, so you actually can get a fair bit without a compiler at all. In practice, no one does that, so you're still right, but it's worth nothing.
And it's worth noting that TypeScript having its own parser vs the rest of the world using Babel is a pain in the rear. See the time it took for ESLint (having to us TSLint in the meantime), now Prettier, having to use TypeScript with an ES6 target and piping the output in Babel to get proper plugin support, the difference between webpack's resolution mechanism and the one used by TypeScript in tools (an issue Flow also shares), and so on.
Some features like enums (omg, TS enums die die die) namespaces, decorators, and the old module system are also pretty awkward when blending with modern javascript. Makes you want to add lint rules to prevent them from being used.
One reason flow might be considered "better" (context is key) is that it plays well with the babel ecosystem, letting one pick and choose their language features.
Picking and choosing language features via babel plugins (many of which will never become part of JavaScript) is an anti-feature. You essentially are creating your own language that only you understand.
The parser features are fixed. The plugins enable/disable them, but they're already "there", just toggled. As far as I know at this point the parser is not pluggable. Babel is a playground for the official TC39 proposals so it might get stuff a little early, but that's about it.
Where the plugins shine is when compiling those (part of the standard) features to something interesting for production. Better inlining, adding debugging and instrumentation, compiling away certain things, optimizing your views for performance, etc.
All things that don't change the language whatsoever, but can improve your debugging or production experience.
That can be done in TS world (and is quite common) by targeting ES6 and piping the result in Babel though. It's just annoying.
You do have things like Prettier not being compatible with TS because different parsers, though.
We don't support custom syntax that isn't already a proposal (meaning it has potential to be in JS), and we also encourage using presets like https://github.com/babel/babel-preset-env instead of providing your own configuration of plugins unless you are more of a power user.
It's our intention as a tool to align with TC39 and transition users to using native JS when it's supported
Yeah, I personally don't mess around with Babel but I imagine you could just take TypeScript's ES6 output and feed it through babel in your gulp/webpack pipeline.
Some people were doing that before TS got async/await compilation directly to ES5 (in TS 2.1). Right now, having Babel in the TS pipeline is not that useful anymore.
I've had some major headaches getting TypeScript to work with Babel and Webpack 2. The main reason I had to use Babel was because I wanted to use Webpack 2's tree shaking feature. Do you know if it's possible to use just TypeScript and Webpack without Babel, and still take advantage of tree shaking?
Honestly this is the main thing keeping me from using TypeScript. I've spent hours, maybe days trying to deal with the mess of Babel/webpack/TS combined with ES6 modules (necessary for tree shaking).
Another problem I ran into was using various packages that weren't typed, but I suppose I can solve that by 'allowing' implicitAny.
I'd really love some advice on this because I want to use TypeScript. It's just been a major headache so far because things are complicated enough with all the other moving parts (Babel presets, import vs require, better but still not well documented Webpack 2, etc.).
Yeah, that's what I use with Webpack. It's just one more rule on Webpack config, so no reason not to do it. There's many things that are out of scope of TS that are better handled by Babel (like embedding corejs methods based on target browser versions).
If you're using Webpack is it possible to gradually opt files into TS type checking _without_ having to rename them, since you can specify which filename patterns loaders apply to?
It might be worth checking ts-loader or awesome-typescript-loader. I'm not sure how it detects js vs ts in those pipelines. TypeScript can also "compile" JS to check for syntax and other errors, so it may still be extension based. An interesting scenario though.
I believe you might be able to with --allowJs, but to be quite honest I haven't done so. All my projects were TypeScript-based from the start, even if sometimes I end up using JS dependencies.
Avoid vendor locking. Someday in near future if you don't like flow anymore, you can just strip all type annotations with Babel and move on. You are not risking ending up like coffeescript.
TypeScript compiles to JS in a straightforward manner as well. If you wanted to move away from TS, you could simply have the TS compiler compile to ES6 and you're done.
But that'd still be transpiled code, right? After getting rid of flow it will be exactly same minus the type annotations. Same cannot be said about typescript considering various language features and syntactic sugar TS offers. Will it run? Yes. Will it feel that it was written by me? That depends.
> Same cannot be said about typescript considering various language features and syntactic sugar TS offers
I think you're vastly misinterpreting what TS is.
It's not anything like CoffeeScript. It's JS plus types and a few other features like Interfaces or advanced ECMAScript features when targetting older versions of the standard.
If you strip away types by exporting to your ECMAScript target of choice, you'll get real JavaScript with the same style as it was written in TypeScript.
It's exactly the same thing you'd get with Flow in that sense. The only additional code you'd get would be for polyfills, but a) those are minimal and b) those will only appear if you export to an older ECMAScript version than the one you wrote it in.
there are a few minor things like enums and decorators that will need to be compiled because they're not standard and are not just types either (well, const enums are i think?, but the rest are not?).
Your equivalence with transpiling coffeescript is false. TS doesn't really have "syntactic sugars". Just about everything in it(less the types of course) is pretty far along in the ES adoption process. There are a couple exceptions like decorators that are called out in a very visible manner.
If you target ES6 your code may look identical. Even much of the ES5 down leveling produced code that looks like a person wrote it.
I converted a 10k line coffeescript project(with async/await !) to JS and then TypeScript. The similarities are so far apart they might as well be in different dimensions. But, if you don't want to take a rando posters word for it, it's pretty easy to make a little sample project and see if the output is to your liking.
That's an objectively incorrect assertion if you're applying that to TypeScript.
The same can be done to it that would be done to Flow: you can just either strip types manually, or just do a single export to your ECMAScripttarget of choice. It'll be native JavaScript. Even the little shims/polyfills it does (to support older ECMAScript versions if you wish to export to it) are optional and can be disabled.
TypeScript has `--target ESNext` this will strip out any TypeScript-specific type annotations, and leave you with standard-track-only JS code that looks identical to your input (modulo type annotations).
FYI we do have an issue open about TS https://github.com/babel/babylon/issues/320 so that we could eventually support TS in Babel as a plugin and then create the same strip-types-plugin just like Flow.
TypeScript type inference is minimal though and doesn't go very far. It falls back to "any" very quickly (and if you use the noImplicitAny option, then you have to type almost everything).
It does a decent enough job at return types, but not a whole lot beyond that.
- When typescript came out, I was an early adopter, and a lot of it's touted benefits were the class-like syntax and constructors to make it more palatable to enterprise shops (not for me, but it was easier to sell to higher ups), this is mostly a moot point now.
- flow can be attached to any codebase as the codebase stands easily. It is, I have found, difficult to bring TS into an existing project.
- flow fits nicely into existing popular js tooling, mainly babel and react.
- no risk of vendor lock in. Maybe TS compiles to pure 100% syntactically correct javascript today, maybe it doesn't in the future. It isn't javascript, so I won't know.