9 ms·

It's very nice to see all of this consolidation going on in the Typescript ecosystem. For example Babel 7 shipping with direct Typescript support back in August

It's very nice to see all of this consolidation going on in the Typescript ecosystem. For example Babel 7 shipping with direct Typescript support back in August, https://blogs.msdn.microsoft.com/typescript/2018/08/27/typescript-and-babel-7 https://blogs.msdn.microsoft.com/typescript/2018/08/27/types... I am a Typescript convert myself and would suggest any daily JS developer give it an honest try.

52-6F-62 8y ago
I'm 100% with you. I find it far more sane, and encourages better practices (in my case). When I'm responsible for tooling in a JavaScript project, it's pretty well a given that I'll push for TypeScript.
celestialjeu 8y ago
Have you used flow at all in the past? If so what would you say the major differences are/how difficult was any process to convert over? I'm a huge fan of having the types defined just from a documentation perspective nevermind bug catching and debugging and all that. I feel relatively agnostic about the particular thing we use to do it so I'm curious as to what the differences are. But yeah it really has improved my day to day immensely and I really feel the difference when I'm working in legacy portions of our apps that pre-date the flow adoption.
- jameslk 8y ago
  I have used both TypeScript (for multiple projects) and Flow (at Facebook). TypeScript is much more feature-rich and looser in strictness. In practice, this looseness has been preferable, as I've seen many of my colleagues fighting Flow's type system vs TypeScript (prior to FB). In theory, perhaps Flow's type system prevents more bugs, but I've sometimes seen it circumvented with hacks just to get past its strictness. TypeScript's ability to infer types seems much smarter than Flow's as well. Besides that, TypeScript has much wider adoption and community support. Most issues I have with TypeScript I can find others who have had similar issues on the web, where as I can't say the same about Flow.
  - lhorie 8y ago
    There's been a lot of doubt cast on Flow outside of Facebook when Jest announced it was moving to TS. I'm curious to hear how Typescript vs Flow discussions go within Facebook, and what engineers there think of each.
    - deleted 8y ago
      [deleted]
    - ajbogh 8y ago
      I would also like to know how many projects within Facebook, if any, use Typescript. I'd be interested in the growth rate as well (how many projects over time).
- _robbywashere 8y ago
  I have never used Flow beyond a basic hello world. The syntax is very similar. Some of the nomenclatures vary. All and all they will both accomplish 99% of the same thing - statically typing a dynamic language. Which gives you much more code confidence, `foobar is undefined` is very less likely. self-documenting code. (see: vs-code intellisense) And code maintenance scale abilities currently not possible with such a loose language like javascript. So I would say if you're interested pick one and dive in. Right now typescript has a lot of community momentum: https://github.com/DefinitelyTyped/DefinitelyTyped https://github.com/DefinitelyTyped/DefinitelyTyped And an extremely fast, open sourced, plugin enabled editor, vs-code ftw! I am a convert after being a longtime diehard vim user. (vs-code has the best vim binding emulation I have ever used in a free open sourced editor) Facebook is deprecating their flow atom editor plugin; nuclide - https://twitter.com/fbopensource/status/1072928679695548416?lang=en https://twitter.com/fbopensource/status/1072928679695548416?... This is all why I would choose typescript over flow if it were up to me. maybe a flow user can chime in.
  - AgentME 8y ago
    I've used Flow very heavily and TypeScript a reasonable amount. They're pretty similar really, but I'd recommend TypeScript for its better tooling and larger available set of type definitions. Flow doesn't seem to be built with the (non-Facebook) developer experience in mind. It very frequently has breaking changes. The tooling is worse. There's no good official way to publish a package to npm with Flow type definitions included. Its alternative to DefinitelyTyped requires using their own CLI tool instead of copying DefinitelyTyped's simple npm-based strategy. There a few things Flow does better. Functions internal to a file often don't need their parameters to be typed because Flow infers their types, but honestly I don't think that's a very killer feature. I often type them anyway just to be explicit. Flow does model type variance better (a Promise<{a:string,b:string}> can be cast to Promise<{a:string}>, but not vice versa, and you can't do the same with mutable arrays, etc.) but variance doesn't come up often and you can always use the any-type escape hatch in TypeScript to make it through those uncommon situations. I do hope TypeScript gets better about that though. Flow isn't bad; a Flow codebase is still much better than an untyped Javascript codebase. But if you're starting a new project and have the choice, pick TypeScript.
- ng12 8y ago
  Typescript's tooling is much better -- it's just a JS transpiler (and now you can use babel to do your transpiling if you prefer). Flow's daemon-style approach was a constant source of pain for me.
  - AgentME 8y ago
    Flow operates very similarly: the recommended setup is to use it with Babel. Babel just strips out the type annotations from your code to make it into legal javascript. The Flow daemon executable was just to provide type checking. Before TypeScript also got similar Babel support, I considered it a strong point in Flow's favor that it was so easy to drop in if you already had a Babel setup going.
    - ng12 8y ago
      > The Flow daemon executable was just to provide type checking. This is problematic. Now your webpack build is shelling out asynchronously to a second process. It makes it very hard to integrate type checking to a build system.
      - AgentME 8y ago
        I've never connected Flow to webpack or my compile process like that. When I've used Flow or TypeScript with Babel, the build process and type checking were always two separate things. I treated type checking like unit tests: something I'd frequently re-check while working on code, but not something connected to the path of getting code running somewhere.
        ng12 8y ago
        Don't you want your build to fail if the type checker fails? I think it's pretty important for a large project.
        williamdclt 8y ago
        Not necessarily locally. On CI/staging/prod yeah definitely, but when I'm hacking around I'm fine with having type errors ("yeah yeah I know this is nullable, I don't care right now I just want to investigate this bug")
- 4lejandrito 8y ago
  I found this post quite interesting. These guys migrated a big codebase from flow to typescript. https://davidgom.es/porting-30k-lines-of-code-from-flow-to-typescript/ https://davidgom.es/porting-30k-lines-of-code-from-flow-to-t...
- fibo 8y ago
  The main issue I found with flow is importing type packages.
- PhineasRex 8y ago
  I've deployed flow extensively and the biggest difference is that flow is horribly buggy (lots of false negatives) while typescript is mature. In theory flow's type system is stronger but it's so unreliable that 99% of the time I'd rather use typescript.
mirekrusin 8y ago
I still feel better with thin/no tooling for transpiling, flow types in comments. There’s something nice about no or ultra flat dependencies and instant npm i that keeps me there.
- nevir 8y ago
  Typescript also supports type checking pure JS files, as well as type annotations via JSDoc comments, if you don't want to transpile.
  - mifreewil 8y ago
    https://github.com/Microsoft/TypeScript/wiki/Type-Checking-JavaScript-Files https://github.com/Microsoft/TypeScript/wiki/Type-Checking-J...
  - deleted 8y ago
    [deleted]
- mLuby 8y ago
  100%! Whatever happened to progressive enhancement?
  - munchbunny 8y ago
    It's a design trade-off. TypeScript is close enough to JavaScript but adding the compiler step actually enables worthwhile changes to improve code safety. And Typescript can import JavaScript modules anyway, so really you just lose the ability to write both in the same file.
- lisowski 8y ago
  If you use VSCode just put `// @ts-check` at the top of your files. I find a bunch of bugs with just that.
- h1d 8y ago
  I like how TS also enables future JS features by transpilation. async / await was great to have quite early on.
pjmlp 8y ago
A tiny part of me still hopes that one day JS standard adopts 100% of TypeScript features.
- bauerd 8y ago
  Is JS a strict subset of TypeScript?
  - steadicat 8y ago
    Yes. All JS code – including recent ES* flavors – is valid TypeScript.
    - recursive 8y ago
      Almost. This is valid javascript. [1].push("foo");
      - alangpierce 8y ago
        TypeScript code can be transpiled and executed even if there are type errors (just like how a linter doesn't stop you from running your code), so in that sense, it's also valid TypeScript.
    - thomasfoster96 8y ago
      This is true of syntax, but it’s not true of the language semantics. There is plenty of perfectly valid JavaScript that isn’t valid TypeScript, so integrating TypeScript into the ECMAScript standard would require something similar to ES5’s “use strict”. I can’t find the link which details this right now, but I believe there are/were some cases where Flow’s syntax isn’t strictly a superset of JavaScript (to do with generics and comparison operators). I’m not sure whether TypeScript has the same problem or not.
  - tazard 8y ago
    Technically typescript is a strict superset of JS, but yes
burtonator 8y ago
Typescript is amazing! I spent the last 90 days porting about 350k lines of code to Typescript plus implementing another 400k. https://getpolarized.io/ https://getpolarized.io/ It's basically a document and annotation manager for PDF and notes. Kind of an Open Source Mendeley/Evernote/Github if you will. This code base is changing often and I really hit a dead in in terms of JS scalability. I was just refactoring too much, breaking things, etc. Now I can just rely on the compiler when I break things. If I want to change a function type in TS it's no problem. In JS it's a nightmare.
- misiti3780 8y ago
  your project is amazing, i would love to help contribute as i have time. please reach out if you need development help.
  - burtonator 8y ago
    Definitely always need help even if it's just feedback on releases. The issue tracker is a good place to start looking :)
  - jondubois 8y ago
    WTF. The project seems completely useless and gimmicky to me. My problem is that I read a LOT of articles and publications. If I started highlighting things in articles, I would never have enough time to go back to them. Besides, why would I want to? I already read it, which means that it's already in my mind! What's the point of reading stuff if not to put information inside your mind? I'd rather use my time to read more new stuff than to revisit things I already know. Maybe the solution is not more tools, it's just to stick to topics that interest you and to pay attention and put more thought into what you're reading.
    - misiti3780 8y ago
      maybe you should be a little less critical about someone who actually built something extremely useful and spend some time investigating the topic of "incremental reading" -- reading info and retaining info are two different things https://www.supermemo.com/help/read.htm https://www.supermemo.com/help/read.htm
atombender 8y ago
How's the migration path? I use TypeScript for new React apps I build, but I'm dealing with some JS projects where there's just no way to convert everything to TS all at once. Does TS work well alongside legacy JS so you can update individual files incrementally as you go along? I remember trying it once and facing some unexpected blockers, but I don't remember what they were.
- ng12 8y ago
  It's very seamless. There's a flag, allowJs, that lets you import js files with only sanity checks (no actual typechecking). You can then start converting individual files to Typescript as you go.
  - atombender 8y ago
    Thanks! I wish I could remember what I ran into the last time. I guess I'll just have to try.
    - addicted 8y ago
      I believe the allowJS flag is new and disabled by default. It may not have existed when you last tried. That’s what happened with our team. We tried to switch in either 0.x or low 1.x and at the time I believe we had to convert everything to TS (although, we may just not have been aware of the allowJS flag at the time).
coldtea 8y ago
I'd like to see at some point browsers treating TS as a typed JS variant, and using the hints to speed up things perhaps too.
- h1d 8y ago
  Would be nice if Chromium picks it up which can be propagated to Chrome and Safari on desktop and mobile and Edge then to nodejs and others will surely pick it up if those adopt it.
  - koolba 8y ago
    That’d be terrible as the language version changes semantics.
    - coldtea 8y ago
      So same as with plain JS?
- nicoburns 8y ago
  I think if you make things consistently typed (as typescript will help enforce), then your JS will run faster already. Because a lot of techniques JS JITs use are basically guessing the type of variables, and then bailing out into a slow path if it turns out they guessed wrong. Codebases like lodash make use of this, which is one reason why they're so fast.

52-6F-62 8y ago

I'm 100% with you. I find it far more sane, and encourages better practices (in my case). When I'm responsible for tooling in a JavaScript project, it's pretty well a given that I'll push for TypeScript.

celestialjeu 8y ago

Have you used flow at all in the past? If so what would you say the major differences are/how difficult was any process to convert over? I'm a huge fan of having the types defined just from a documentation perspective nevermind bug catching and debugging and all that. I feel relatively agnostic about the particular thing we use to do it so I'm curious as to what the differences are. But yeah it really has improved my day to day immensely and I really feel the difference when I'm working in legacy portions of our apps that pre-date the flow adoption.

jameslk 8y ago
I have used both TypeScript (for multiple projects) and Flow (at Facebook). TypeScript is much more feature-rich and looser in strictness. In practice, this looseness has been preferable, as I've seen many of my colleagues fighting Flow's type system vs TypeScript (prior to FB). In theory, perhaps Flow's type system prevents more bugs, but I've sometimes seen it circumvented with hacks just to get past its strictness. TypeScript's ability to infer types seems much smarter than Flow's as well. Besides that, TypeScript has much wider adoption and community support. Most issues I have with TypeScript I can find others who have had similar issues on the web, where as I can't say the same about Flow.
- lhorie 8y ago
  There's been a lot of doubt cast on Flow outside of Facebook when Jest announced it was moving to TS. I'm curious to hear how Typescript vs Flow discussions go within Facebook, and what engineers there think of each.
  - deleted 8y ago
    [deleted]
  - ajbogh 8y ago
    I would also like to know how many projects within Facebook, if any, use Typescript. I'd be interested in the growth rate as well (how many projects over time).
_robbywashere 8y ago
I have never used Flow beyond a basic hello world. The syntax is very similar. Some of the nomenclatures vary. All and all they will both accomplish 99% of the same thing - statically typing a dynamic language. Which gives you much more code confidence, `foobar is undefined` is very less likely. self-documenting code. (see: vs-code intellisense) And code maintenance scale abilities currently not possible with such a loose language like javascript. So I would say if you're interested pick one and dive in. Right now typescript has a lot of community momentum: https://github.com/DefinitelyTyped/DefinitelyTyped https://github.com/DefinitelyTyped/DefinitelyTyped And an extremely fast, open sourced, plugin enabled editor, vs-code ftw! I am a convert after being a longtime diehard vim user. (vs-code has the best vim binding emulation I have ever used in a free open sourced editor) Facebook is deprecating their flow atom editor plugin; nuclide - https://twitter.com/fbopensource/status/1072928679695548416?lang=en https://twitter.com/fbopensource/status/1072928679695548416?... This is all why I would choose typescript over flow if it were up to me. maybe a flow user can chime in.
- AgentME 8y ago
  I've used Flow very heavily and TypeScript a reasonable amount. They're pretty similar really, but I'd recommend TypeScript for its better tooling and larger available set of type definitions. Flow doesn't seem to be built with the (non-Facebook) developer experience in mind. It very frequently has breaking changes. The tooling is worse. There's no good official way to publish a package to npm with Flow type definitions included. Its alternative to DefinitelyTyped requires using their own CLI tool instead of copying DefinitelyTyped's simple npm-based strategy. There a few things Flow does better. Functions internal to a file often don't need their parameters to be typed because Flow infers their types, but honestly I don't think that's a very killer feature. I often type them anyway just to be explicit. Flow does model type variance better (a Promise<{a:string,b:string}> can be cast to Promise<{a:string}>, but not vice versa, and you can't do the same with mutable arrays, etc.) but variance doesn't come up often and you can always use the any-type escape hatch in TypeScript to make it through those uncommon situations. I do hope TypeScript gets better about that though. Flow isn't bad; a Flow codebase is still much better than an untyped Javascript codebase. But if you're starting a new project and have the choice, pick TypeScript.
ng12 8y ago
Typescript's tooling is much better -- it's just a JS transpiler (and now you can use babel to do your transpiling if you prefer). Flow's daemon-style approach was a constant source of pain for me.
- AgentME 8y ago
  Flow operates very similarly: the recommended setup is to use it with Babel. Babel just strips out the type annotations from your code to make it into legal javascript. The Flow daemon executable was just to provide type checking. Before TypeScript also got similar Babel support, I considered it a strong point in Flow's favor that it was so easy to drop in if you already had a Babel setup going.
  - ng12 8y ago
    > The Flow daemon executable was just to provide type checking. This is problematic. Now your webpack build is shelling out asynchronously to a second process. It makes it very hard to integrate type checking to a build system.
    - AgentME 8y ago
      I've never connected Flow to webpack or my compile process like that. When I've used Flow or TypeScript with Babel, the build process and type checking were always two separate things. I treated type checking like unit tests: something I'd frequently re-check while working on code, but not something connected to the path of getting code running somewhere.
      - ng12 8y ago
        Don't you want your build to fail if the type checker fails? I think it's pretty important for a large project.
        williamdclt 8y ago
        Not necessarily locally. On CI/staging/prod yeah definitely, but when I'm hacking around I'm fine with having type errors ("yeah yeah I know this is nullable, I don't care right now I just want to investigate this bug")
4lejandrito 8y ago
I found this post quite interesting. These guys migrated a big codebase from flow to typescript. https://davidgom.es/porting-30k-lines-of-code-from-flow-to-typescript/ https://davidgom.es/porting-30k-lines-of-code-from-flow-to-t...
fibo 8y ago
The main issue I found with flow is importing type packages.
PhineasRex 8y ago
I've deployed flow extensively and the biggest difference is that flow is horribly buggy (lots of false negatives) while typescript is mature. In theory flow's type system is stronger but it's so unreliable that 99% of the time I'd rather use typescript.

mirekrusin 8y ago

I still feel better with thin/no tooling for transpiling, flow types in comments. There’s something nice about no or ultra flat dependencies and instant npm i that keeps me there.

nevir 8y ago
Typescript also supports type checking pure JS files, as well as type annotations via JSDoc comments, if you don't want to transpile.
- mifreewil 8y ago
  https://github.com/Microsoft/TypeScript/wiki/Type-Checking-JavaScript-Files https://github.com/Microsoft/TypeScript/wiki/Type-Checking-J...
- deleted 8y ago
  [deleted]
mLuby 8y ago
100%! Whatever happened to progressive enhancement?
- munchbunny 8y ago
  It's a design trade-off. TypeScript is close enough to JavaScript but adding the compiler step actually enables worthwhile changes to improve code safety. And Typescript can import JavaScript modules anyway, so really you just lose the ability to write both in the same file.
lisowski 8y ago
If you use VSCode just put `// @ts-check` at the top of your files. I find a bunch of bugs with just that.
h1d 8y ago
I like how TS also enables future JS features by transpilation. async / await was great to have quite early on.

pjmlp 8y ago

A tiny part of me still hopes that one day JS standard adopts 100% of TypeScript features.

bauerd 8y ago
Is JS a strict subset of TypeScript?
- steadicat 8y ago
  Yes. All JS code – including recent ES* flavors – is valid TypeScript.
  - recursive 8y ago
    Almost. This is valid javascript. [1].push("foo");
    - alangpierce 8y ago
      TypeScript code can be transpiled and executed even if there are type errors (just like how a linter doesn't stop you from running your code), so in that sense, it's also valid TypeScript.
  - thomasfoster96 8y ago
    This is true of syntax, but it’s not true of the language semantics. There is plenty of perfectly valid JavaScript that isn’t valid TypeScript, so integrating TypeScript into the ECMAScript standard would require something similar to ES5’s “use strict”. I can’t find the link which details this right now, but I believe there are/were some cases where Flow’s syntax isn’t strictly a superset of JavaScript (to do with generics and comparison operators). I’m not sure whether TypeScript has the same problem or not.
- tazard 8y ago
  Technically typescript is a strict superset of JS, but yes

burtonator 8y ago

Typescript is amazing! I spent the last 90 days porting about 350k lines of code to Typescript plus implementing another 400k. https://getpolarized.io/ https://getpolarized.io/ It's basically a document and annotation manager for PDF and notes. Kind of an Open Source Mendeley/Evernote/Github if you will. This code base is changing often and I really hit a dead in in terms of JS scalability. I was just refactoring too much, breaking things, etc. Now I can just rely on the compiler when I break things. If I want to change a function type in TS it's no problem. In JS it's a nightmare.

misiti3780 8y ago
your project is amazing, i would love to help contribute as i have time. please reach out if you need development help.
- burtonator 8y ago
  Definitely always need help even if it's just feedback on releases. The issue tracker is a good place to start looking :)
- jondubois 8y ago
  WTF. The project seems completely useless and gimmicky to me. My problem is that I read a LOT of articles and publications. If I started highlighting things in articles, I would never have enough time to go back to them. Besides, why would I want to? I already read it, which means that it's already in my mind! What's the point of reading stuff if not to put information inside your mind? I'd rather use my time to read more new stuff than to revisit things I already know. Maybe the solution is not more tools, it's just to stick to topics that interest you and to pay attention and put more thought into what you're reading.
  - misiti3780 8y ago
    maybe you should be a little less critical about someone who actually built something extremely useful and spend some time investigating the topic of "incremental reading" -- reading info and retaining info are two different things https://www.supermemo.com/help/read.htm https://www.supermemo.com/help/read.htm

atombender 8y ago

How's the migration path? I use TypeScript for new React apps I build, but I'm dealing with some JS projects where there's just no way to convert everything to TS all at once. Does TS work well alongside legacy JS so you can update individual files incrementally as you go along? I remember trying it once and facing some unexpected blockers, but I don't remember what they were.

ng12 8y ago
It's very seamless. There's a flag, allowJs, that lets you import js files with only sanity checks (no actual typechecking). You can then start converting individual files to Typescript as you go.
- atombender 8y ago
  Thanks! I wish I could remember what I ran into the last time. I guess I'll just have to try.
  - addicted 8y ago
    I believe the allowJS flag is new and disabled by default. It may not have existed when you last tried. That’s what happened with our team. We tried to switch in either 0.x or low 1.x and at the time I believe we had to convert everything to TS (although, we may just not have been aware of the allowJS flag at the time).

coldtea 8y ago

I'd like to see at some point browsers treating TS as a typed JS variant, and using the hints to speed up things perhaps too.

h1d 8y ago
Would be nice if Chromium picks it up which can be propagated to Chrome and Safari on desktop and mobile and Edge then to nodejs and others will surely pick it up if those adopt it.
- koolba 8y ago
  That’d be terrible as the language version changes semantics.
  - coldtea 8y ago
    So same as with plain JS?
nicoburns 8y ago
I think if you make things consistently typed (as typescript will help enforce), then your JS will run faster already. Because a lot of techniques JS JITs use are basically guessing the type of variables, and then bailing out into a slow path if it turns out they guessed wrong. Codebases like lodash make use of this, which is one reason why they're so fast.