[RFC] Move to Typescript

[HenriBeck]

With more OS projects now planning to move to Typescript (jest, Vue.js, etc.), I think it would be time to think about doing the same. Typescript has matured and now with eslint and babel both supporting Typescript as well, it should be future proof.

Additionally, I think the tooling around Typescript (speed, autocompletion), etc. is far head of flow currently.

I would start with "rewriting" smaller packages (like css-functions and theming) in the beginning. Also, I started writing the new docs with Typescript.

Are you willing to implement it? Yes

EDIT: I started rewriting the core in my fork in Typescript as an experiment.

[TrySound]

Besides better tooling I saw a lot of unsoundness in TS which is "won't fix" when flow to gonna be and actually already safer than TS in some cases. For me it doesn't worth to switch. I'm quite happy with flow in big project and open source.

[HenriBeck]

Why would Typescript be less type-safe?

[TrySound]

Here guys from flow team provides some examples https://discord.gg/zGY9gW

For example TypeScript doesn't have exact types at all (https://github.com/Microsoft/TypeScript/issues/12936) when flow is gonna have them by default. Object spread is unsound (https://github.com/Microsoft/TypeScript/issues/15454) when flow is already more sound here and is gonna improve experience with exact by default.

[TrySound]

Flow has some problems but flow team is quite active and open last few weeks. They are going to the right direction but their plan is time consuming. Now they have resources to work with community.

[kof]

That's interesting, do you know how many people work on flow full time? I feel like flow with strict mode and better error descriptions would actually make the whole thing quite competitive. It's just a matter if companies are willing to invest enough to improve.

[TrySound]

This is just now. There are more people there

[kof]

Fulltime contributors? Where do you see it?

[TrySound]

It's a chat with flow team (facebook guys). The link I put above.

[HenriBeck]

I think flow error descriptions and reporting is quite better (especially when it comes to react props) than Typescripts.

What I now dislike the most about it is how slow the editor integration is and that types are an afterthought.

[TrySound]

Which editor do you use?

[HenriBeck]

Webstorm, and for me the autocompletion, auto-import etc. is really slow, I think in a recent release they improved the language server to handle request while they are recomputing all of the types though.

[TrySound]

There is one representative from webstrom team in flow chat. They are discussing better integration. Yeah, main problem is checking too much. Ignoring things usually helps.

[HenriBeck]

The reason why I proposed this change that a lot of quite large projects are moving into this direction. And yeah, TS maybe is sometimes unsafer, but I think this only applies for certain type definitions/operators.

The reason I got to like Typescript so much is that the language was designed with types in mind and not just an afterthought/addition like flow.

[TrySound]

Well, sorry, but herd instinct is a bad reason to refactor all the project. It looks like "flow is a shit and nobody will ever use, let's kill it". By doing this you just add fuel to the fire of hate which is really started by just one person.

By the way about big projects decisions. Here's another one https://github.com/mdn/mdn/pull/53/files#diff-992ca475abeb0c101165f19ff62d37e7R14

[TrySound]

And typescript was designed around the same javascript with all it's problem. It's not really different language. Reason/ocaml or haskell was designed with types.

[kof]

They seem to want to use flow without types or adding types gradually.

I think the goal for a library should be the highest type safety possible.

On Sat, Feb 16, 2019, 18:30 Bogdan Chadkin <[email protected] wrote:

Well, sorry, but herd instinct is a bad reason to refactor all the project. It looks like "flow is a shit and nobody will ever use, let's kill it". By doing this you just add fuel to the fire of hate which is really started by just one person.

By the way about big projects decisions. Here's another one

https://github.com/mdn/mdn/pull/53/files#diff-992ca475abeb0c101165f19ff62d37e7R14

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cssinjs/jss/issues/1035#issuecomment-464365342, or mute the thread https://github.com/notifications/unsubscribe-auth/AADOWH91H4o3okJ1IrHYS1yH7RhBJXo5ks5vOEA8gaJpZM4a-V26 .

[HenriBeck]

I never said that Typescript is a different language and has not the problems of javascript, but at the same time Typescript was designed around types (which in my opinion solves a few of them). The best comparison for that in my mind is how you import/export types in Typescript vs. flow.

[TrySound]

Flow was also designed around types. It's type system.

Well, I dont see any sense in import way. It's just a choice without "not types in mind"

Flow coming types first arch name is quite descriptive.

[HenriBeck]

What I mean by "designed around types" is that flow tries to add types on top of javascript, and Typescript is a superset of javascript which compiles down to js.

[kof]

That just means that flow is not going to add language features, just types, where typescript has done so and might do more. In that sense, ts has more power. At the same time, the more ts does so, the further away it is from js.

Most things other than that are basically implementation details and features which one has but another one doesn't and vise versa.

I think we need to clearly define the criteria for our choice first of all. Knowing we are working in a library context.

[TrySound]

Its not true. Both add types and invalid syntax to javascript. Both are compiled to javascript. But flow team just is a bit more careful with JS semantics.

[kof]

Where did flow add something that compiles to runtime javascript?

[TrySound]

Well exact types is a good reason to stay with flow.

[TrySound]

What babel compiles to JS from TS?

[kof]

For example

enum Direction {
    Up = 1,
    Down,
    Left,
    Right,
}

[kof]

Well exact types is a good reason to stay with flow.

Can you expand pls? Afaik both have this, but mb you know more than I do

[kof]

TBH my biggest problem with both flow and TS is to maintain types for both. Ideally I want to do it only once.

[TrySound]

Read the thread. TS doesnt have exact types.

[TrySound]

AFAIK enums are not compiled via babel.

[TrySound]

@kof Flow team is working on definitions generator which will allows simply map them to TS typings.