ES6

While I am not a big fan of kotlin but I guess for your use-case it would be better, since you need only an android app and learning es6 , react & react native will definitely be a time consuming task since it has a steep learning curve and has a lot to learn, but it is more flexible and useful than kotlin though.

I was asking myself this same question a few years ago. I felt that ES6 provided a terse, declarative syntax, that in combination with unit tests was reliable enough. Dynamic typing kept the code looking clean and left most functions generic and reusable for several data types. However, as your code base starts to grow and more and more "ad hoc" data types are introduced. It starts to become very hard to maintain and refactor code because you have to keep long call chains in your head and you sometimes don't know if you can remove a field from an object without introducing a runtime error. In essence, the less strict a programming language is the more you will have to test explicitly all the time. On top of that JavaScript is really good at coercing types in weird ways.

So the main benefit that TypeScript brings is static typing. You make your code more explicit, thereby limiting the number of unintentional behaviors that are possible. The compilers type checker can suddenly take care of testing these extra constraints for you and you start removing this burden from your unit tests. As a matter of fact TypeScript has a pretty advanced type system, a magnitude better than the current Java version (14) or Go-lang. One of these features are union types (aka. coproduct, sum type, etc). This lets you represent your types as "this thing" or "this other thing". Returning a disjoint union can make your code even more explicit and thus further limiting the number of unintentional behaviors. A simple example of this is the head function that returns the first element of a list. Either you get the value or you get undefined if the list is empty. A better approach is to return a Maybe type which is either an instance of Just(<value>) or Nothing. This tells you that the code calling head needs to handle exactly two possible cases. Languages with even stronger type systems like Elm and Haskell can even enforce that your code won't compile unless you handle all the possible cases for any union type. So again the compiler helps you avoid more runtime errors.

So to conclude the benefits of using a language with strong static typing:

• Compiler helps you avoid runtime errors
• Substantially reduce number of explicit unit tests
• Better security and reliability by preventing unintentional behavior
• Let's you refactor code with confidence
• Code becomes more self-documenting

I've been feeling the same way and it was almost too simple for me. First, strongly typed languages are objectively better for catching errors during development instead of during production so a small amount of work upfront pays huge dividends later. But the easy part is how actionable it is.

Find a codebase that you want to convert. For me, it was a server that I wanted to convert to Firebase cloud functions to go serverless. I took my server.js file and copied it as server.ts. I created a simple tsconfig.json file in the root with some standard settings online and then I let the VS Code IntelliSense guide the migration. It was so much easier than I expected and I learned TypeScript as I was converting my codebase.

It was almost too easy and now I have all of the benefits of feature-rich and built-in assistance in my code-editor. Documentation on hover, clear and clean errors. This was only about 2 weeks ago and I am not sure I'd ever go back to Vanilla JS now. It was love at first use with me.