I've been using the two together recently and its been great. Like you I don't think I could ever go back to not using typescript for anything but the smallest projects.

However, often times I've found some common react patterns to be difficult to express in typescript. Namely default props and high order components. The type signatures I'v ended up with for my HoCs aren't as simple as I'd like, but I guess there is no way getting around that.

I've actually started to prefer render props over HoCs simply because the type signatures are simpler. Still no idea how to handle default props correctly.

https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in...

The React typescript definitions are still on 2.8 [1], and I imagine that they plan to stick with 2.8 until maybe the next major react release? I have no idea where people discuss things like react types for DefinitelyTyped. Github issues seem like a mess due to the sheer number of different projects sitting in a single repo.

[1] https://github.com/DefinitelyTyped/DefinitelyTyped/blob/1d96...

[1] https://github.com/DefinitelyTyped/DefinitelyTyped/blob/1d96...

Little things like this can add up to subtle bugs and tech debt if you're not careful.

That did not mean jQuery wasn't better than the ugly ad-hoc kludges in vanilla JS most web developers used at the time.

IMO, using such early proposals isn't worth the risk in production. Especially for proposals that are so young that they haven't even settled on a clear spec as to its behavior, like the pipeline operator.

It's also ironic that I couldn't write this in Typescript because I simply couldn't figure out how. These days when I use my helper, I just use any and cast the result. It sucks but until I figure out how to type proxies and use variadic generic type parameters (if and when these are supported) I don't have another solution.

Goddamn time travelers, stop messing with chronology!

Either way it wasn't Typescript itself that made it difficult. There wasn't as large of community yet, documentation was much less, editor support wasn't as great and very few packages had type definition files. Definitely typed could show all or most of their packages on GitHub at the time and many were incomplete. That was the sole way to get any type definitions.

Agreed with your comment on early proposals. Still would like to have the option to use it and double check the transformation of how it outputs. And not everything needs to be for production use. Writing for fun is an enjoyable hobby.

As I’m starting to get into the modern front end world… I do want the safety of a stronger type system but it doesn’t look like the React ecosystem has really decided which way to go.

TypeScript is popular. But flow was developed by Facebook and so it’s obviously heavily used by some of the top people.

I’ve only been reading about them, I haven’t chosen to use one yet. But I’ve been leaning on flow since it’s developed by the React team at Facebook.

That's what really frustrates me about Flow after using it for many years. We shouldn't have to rewrite valid code, write unreadable workarounds or add // $FlowFixMe annotations to avoid Flow's issues. I lead a small team of junior developers to whom I presented Flow. We now use it everywhere. But they often experience difficulties when they try to type their code. When I see what blocks them, my answer is too often "oh yeah, it's a bug in Flow. There is an issue about it on GitHub opened in 2016".

I'm right now waiting for this https://github.com/facebook/create-react-app/pull/4837 to be merged to move all my projects to TS.

Edit: and I don't blame the devs working on Flow. I guess it's more a priority issue at Facebook. Or maybe they just gave up on the community support since TS is too ahead.

The main large project you're likely to use that does not really play well with TypeScript yet is create-react-app. There's a TypeScript fork [1] which works reasonably well, but "reasonable" is not really what you'd hope.

That said, the strong community push means that they're at least considering it. [2]

[1] https://github.com/wmonk/create-react-app-typescript [2] https://github.com/facebook/create-react-app/pull/2815

Also, the CRA-TS fork runs, but the one time I played with it was when I tried to help another team set up their project, and that's when I found out it has _ridiculously_ restrictive default linting rules. Every lint error is a compile error, and it flags things like using arrow functions in render methods, which is absurd (see discussion at https://github.com/wmonk/create-react-app-typescript/issues/... ).

I have been maintaining some boilerplate to demonstrate TypeScript + React SSR that should point the reader in the right direction https://github.com/styfle/react-server-example-tsx

I'm waiting it to be merged to switch to TS.

https://github.com/Microsoft/TypeScript-React-Starter#typesc...

It does work fine, but sometimes you don't get some of the gooddies that you get in the latest js version.

Edit: oh and it’s worth noting that I’ve had much more luck finding TS definitions for third party packages than I have with Flow.

I’ve only done a cursory look. My editor (IntelliJ) supports both to some level. Webpack/Babel do too.

I’m very new to writing React and modern front end JS so it’s quite possible there are things that I should be looking out for that I don’t even know about.

I think that’s what differentiates TS from flow. Typescript thought about the whole developers workflow while flow is just a compile time typechecker.

https://github.com/flowtype/flow-language-server#supported-f...

I still have found TypeScript to be an overall more pleasant developer experience, though.

That's not to say that either TypeScript or Flow are perfect - they both are constraining with typing when it comes to composing functions last I checked.

It's not something you'd want to find in the middle of your code, yet you may have to if you want to do generic/functional programming in TS.

EDIT: one thing I miss from flow is https://github.com/gcanti/babel-plugin-tcomb - it's quite handy to spot data errors (before you have big static coverage)

But is not developed by the same developers/company as React.

I will say given what TS is competing against the fact that it so well used is rather compelling. I know all of Angular is also written in TS. It’s clearly very heavily used.

Being able to use good code completion when using other people’s components is a huge boon.

I'm really interested in this, as I'm a happy Angular user. (I'm primarily a non-frontend dev/tech/ops, but I occasionally I do frontend development.) So every time I look at a React component/codebase I'm completely lost, and I'd like to understand why and what and how.)

https://blogs.msdn.microsoft.com/typescript/2018/08/27/types...

But I am less excited about projects containing TypeScript plus the large number of transitive dependencies from a typical Babel set up; I've been greatly enjoying TypeScript instead of that.

https://github.com/denoland/deno

Edit: wait it looks like they’ve changed to all Rust with C++ for the libraries. I haven’t looked at the codebase since the spring. Am I crazy that i could have sworn it was written in Go previously?

https://github.com/denoland/deno/pull/276

If I were looking for a regular job, I would probably filter employers based on whether they use TypeScript or not at this point (assuming it was some JavaScript-adjacent project). I'm not sure if there's really a good way of doing this sort of filtering.