Strange proposition. No dev I know who has professionally worked with both would claim the same, even the skeptics long term ended up grokking types as a way to make it easier to understand the intent behind a piece of code, even when they prefer JS for writing, never for reading other people's code.
How long have you worked with each? What editor tools have you used for TS? I'm really curious about your experience.
Interesting. Was that your first time reading TS? Higher order functions, specially when combined with optional arguments, in JavaScript are an easy source of bugs for me but never when using TS, since I can simply see what I'm being asked for and getting back.
>Also I am a solo developer in my company
I actually forgot that scenario. Yes, unless you have adapted to the type-driven development way of thinking you will hardly see many of the benefits of maintaining code that has types vs code that does not.
When you're the one that wrote the code, you'll have an unfair advantage at understanding how the author meant the code to be used. When you don't have that luxury, types can be a great aid in most situations. Of course, it's a question of time and codebase size until you break your own preconditions when changing something, but you'll not notice how the type system can save you from that until it you actually learn how to take advantage of it.
It's a catch-22, so if you're curious and want to see what's meant by "taking advantage of the type system", I can only suggest you that you give something like Elm a try. There you'll see many times in the first couple of weeks what types can do for you when changing code.
But for a backend I would certainly have used static types as it's way more critical.
The getting started, learning curve, and "wtf is happening here" curve is rather high. Especially once you add in Redux and React Navigation.
It doesn't help that all of the "getting started with RN and TS!" assume a decent understanding of TS.
I eventually got TSX working, but yeah, figuring out what you need to declare to make it all work is not easy.
Redux having 5 major ways (or whatever it is) of using it didn't help any. I use the shorthand form of mapDispatchToProps in my connect call, which none of the "TS in Redux" tutorials seem to use. (Why not? It is so much easier and shorter!)
I eventually gave up on typing Redux, IMHO the last thing Redux needs is more boilerplate! I rarely have type problems in my Redux code anyway. I probably understand enough to do it now (or maybe not, haven't investigated what typing redux-thunk looks like), but I'm going for "less bugs" not ideological purity in my code.
The tl;dr is that you have to declare an interface for your props, an interface for your state, and your props interface has to include a NavigationScreenProp which I honestly declared as
navigation: NavigationScreenProp<any>;
All that said, the one time learning curve was worth it.
Typescript definitions can get super complicated though, my 90% use case is preventing typos and allowing for refactoring, so I only type objects I pass around as interfaces and I type functions that have been the source of bugs. Mostly anything that comes from my backend DB I want typed end to end. The majority of my REST endpoints use Typescript to pull from the DB so I just share interfaces across my backend and frontend.
It has been worth the hassle just for that.