If you are working in your own bubble with few outside dependancies it works very well. I have been learning WebGL lately, and have found it extremely useful in that regard. Things get hairy dealing with external libraries with often flakey type definitions.
I would still use Typescript on new projects where I can. I have come to accept that I will often just need to use "any" in place of a proper type. There is the temptation to spend a lot of time creating complex types with generics but I've found it to be a can of worms. I'm always looking for new ways leverage the type system, and feel like I often hit dead ends.
Generally I think using Typescript to be an improvement over plain ES6. It catches a lot of bugs, and allows me to refactor with more confidence, but it is very far from ideal.
I've never seen such a powerful type system that's so easy to use. While the advanced stuff can be quite complex (as a consequence of its power), the experience of working with the compiler is made pleasant by good IDE support, fast type-checking, and readable syntax. Also, the level of type safety you want to go for is totally up to you.
The one frustrating thing can be using frameworks and libraries that don't have good type definition files. React and TypeScript are actually a slightly awkward fit, because React's component classes and idiomatic HOCs are quite difficult to type correctly, even though TypeScript has built-in React support. In my own code, I've ditched React's component classes for this reason.
The front end world is a land of sand castles. If you put in the work and care to make yours wonderful then I'm sure there is a sense of pride and accomplishment at what can be done with the tools.
However, the tide will come in and it feels like it comes in daily to threaten to wash away all of your work. You do not control the tide.
-----------------
By the above I mean that you will need to fully own the application life cycle management and realize that for as great as Typescript is virtually _none_ of the examples you see will be based in it and there will always be some level of disconnect between what you are doing and what most everyone else is doing.
I think Typescript is a great fit _if_:
a) You ship a part of the project that _only_ has to interface with your TS code post compilation/transpiling. For example a little proxy shim responsible for server round trips or the business logic that the front end devs will call.
b) You are using Angular.
Otherwise use whatever the core framework you adopt is using. Usually just ES6 + Babel + a nice linter + tests.
Hope that helps. I'm a C# dev and I've tried and failed to use TypeScript for years. Mainly because the buy in is usually for React/Vue/etc and the JS front end land is squirrely enough without my having to mentally translate every example I see into TS. I've come to terms with doing one mental switch during my day between logical tiers (front end, middleware, backend). I try to limit the additional context switching I have to do once in those spaces.
Hope that helps.
Interesting. Those are the type of day-to-day details that I'm curious about when I see cross platform solutions like Xamarin, Kotlin Native, or React Native.
A good build system and tests can but don’t have to be overly tricky to set up and support improves all of the time.
I’ve tried to get good projects going with React but unfortunately many packages haven’t been typed (though it’s getting better).
I definitely prefer it for any work with data. I don’t know if you’d consider it a benefit that you can break out of the type system if you need to do so.