Well, the first resource I would recommend you is my upcoming book by Packt Publishing, "Professional React Native", but it's due late January next year :) . Now jokes aside (the book's real by the way :) ), the easiest way to build a iOS/Android/Web app with React Native is to do: npm install -g expo-cli expo init some-project cd some-project expo eject

You might have heard of Expo, but trust me, stay away from it. Expo highest value is that it's an already pre-configured 3 platforms environment, but if you don't eject then you're vendor-locked to what Expo has to offer in iOS and Android, which is very poor compared to going full React Native on these platforms, they can't even handle Google Sign In properly and by the way, even if your app is 10 lines of code your app size will be over 40 MB if you don't eject, yep it's that bad, plus the performance is regular and the loading times slow, not to mention that you're stuck with their build service which the free tier makes you wait for hours for a free build slot. It's important to note that when ejecting you don't lose the Web, you simply do expo start --web to start your dev environment and expo build:web to build a static website that you can serve with any web server. Regarding state management, don't bother with "lifting state up" philosophies mixed with Context API to manage your state, lifting state is a great pattern and helps your codebase, Context is great to avoid prop-drilling, but NEVER mix them to achieve app-wide state management, for that, simply go for Redux or MobX, the hype is all about Redux, but I consider MobX far better in many aspects. However, as you're getting new into this I would recommend you start with Redux AND PLEASE grab yourself npm install @manaflair/redux-batch so that you can batch updates and don't bring your app to a crawl. Forget that "connect HOC" thing with React-Redux, don't bother for a second with it, go with Hooks and useSelector and useDispatch and the likes, it will make your code SO much cleaner and smaller. Adopt clean and new Hooks philosophy, avoid writing class components as much as possible and write function components augmented with Hooks.

I use TypeScript because:

• incredible developer tooling and community support
• actively developed and supported by Microsoft (yes, I like Microsoft) ;)
• easier to make sense of a TS codebase because the annotations provide so much more context than plain JS
• refactors become easier (VSCode has superb support for TS)

I've switched back and forth between TS and Flow and decided a year ago to abandon Flow completely in favor of TS. I don't want to bash Flow, however, my main grievances are very poor tooling (editor integration leaves much to be desired), a slower release cycle, and subpar docs and community support.

I use TypeScript because it isn't just about validating the types I'm expecting to receive though that is a huge part of it too. Flow (JS) seems to be a type system only. TypeScript also allows you to use the latest features of JavaScript while also providing the type checking. To be fair to Flow (JS), I have not used it, but likely wouldn't have due to the additional features I get from TypeScript.

We originally (in 2017) started rewriting our platform from JavaScript to Flow (JS) but found the library support for Flow was lacking. After switching gears to TypeScript we've never looked back. At this point we're finding that frontend and backend libraries are supporting TypeScript out of the box and where the support is missing that the commuity is typically got a solution in hand.

I use TypeScript because the tooling is more mature (the decision to discontinue TSLint in favor of moving all its checks to ESLint is a thoughtful and mature decision), there's a ton of examples and tutorials for it, and it just generally seems to be where the industry is headed. Flow (JS) is a fine tool, but it just hasn't seen the uptake that TS has, and as a result is lacking a lot of the nicer small things, like thorough Visual Studio Code integration, offered by TS.

We currently use TypeScript at work. Previously we used Flow (JS) but it was sometimes really difficult to make the types work the way you want. Especially non-trivial types were problematic. And the IDE support wasn't good, Flow took too much resources and sometimes remain stuck and do not show errors (I use Visual Studio Code). With TypeScript we almost do not have these problems. IDE support is superb, working with types is much easier and typing system seems more mature and powerful. There are some downsides (like partion inheritance etc.), but TS team is still pushing it forward. So for me TypeScript is clear winner.

We use Underscore because it's a reasonable library for providing all the reasonable helper functions missing from JavaScript ES5 (or that perform poorly if you use the default ES5 version).

Since we're migrating the codebase to TypeScript , we'll likely end up removing most usage of it and ultimately no longer needing it, but we've been very happy with the library.

I use TypeScript for Web Applications and for both frontend and backend because it has a lot of tooling around it and they really got the types and type safety right. Flow (JS) on the other hand lacks tooling and most of the times I scramble to find the right way of building my contracts in which TypeScript is very intuitive and natural. Additionally TypeScript is very similar to Java so your backend engineers and full stack engineers can work with it without much of context switch.

The only time I think Flow shines is (based on probably my outdated knowledge) Flow is/was the only option if you want/wanted to build a React Native application mainly because React Native transpiler at the time I was working with it would only work with flow.

I use TypeScript because it's adoption by many developers, it's supported by many companies, and it's growth. AngularJS, React, @ASP.NET Core. I started using it in .NET Core, then for a job. Later I added more Angular experience and wrote more React software. It makes your code easier to understand and read... which means it makes other people's code easier to understand and read.

I use TypeScript because I tried both on a Meteor project, and found the quantity of errors it enabled us to catch and the simplification of code it allowed was higher than Flow (JS).

I use TypeScript because it's the most mature/issue-free Javascript type-checker available, as far as I've seen.

I use TypeScript because of broad support, on tools, repos, community ... the only reason to consider flow is if you're a facebook employee

If you will start a project from scratch I recommend to use TypeScript. But, If you work with legacy projects written in JavaScript I recommend Flow (JS). Both tools have the same objective: reduce the bad code (which create illegible code, generate bugs e problems to maintenance). Flex helps you to avoid fall in bad codes, but TypeScript prevent you to c you to create bad codes. I believe cause this some JavaScript fans don't like TS, because TS block you to write some types o code. This is the fundamental difference between TS and Flow: Flow avoid problems, but no force. TS force you to prevent problems.

I recommend TypeScript. When used correctly, TypeScript can enable your application to be scalable, easy to refactor, safe, and stable. One of the biggest draws of working with any typed language is that it forces you to think about your functions' inputs and outputs. This is invaluable as it can lead to more declarative, functional style code that ultimately can be easier to reason about.

TypeScript is however not a silver bullet. Just like anything new it takes time to fully understand the concepts of types, interfaces, abstract classes, and enums. In my experience engineers who excel when using TypeScript are those who have experience working with a statically typed language.

I use TypeScript because i love to program in Angular and used in node as well