I’m really not sure what problems you have in mind here. I’ve found TS to be really useful with very few caveats.
The biggest problem you’re likely to hit in TS is when things subtly lose their strong typing accidentally -- for example, you need to use some API that works with untyped JSON blobs. But the you’re no worse off than if you were just using plain JS in the first place.
TS is especially great when you’re using libraries with good type annotations -- your IDE can give you useful live typechecking and autocompletion, even if your own code is in JS!
In React code, TS is really good because you can statically check your prop types. There is a little bit of a learning curve to doing that both correctly and tersely, but I think it’s more than worth the effort.
As the OP specifically said they wanted strong typing, TS seems like an obvious choice over vanilla JS. I suppose you could consider other things like Flow or Reason, but TS is the most widely-used by far.
What problems specifically do you have with TS on the frontend?
The benefits to using Typescript are immense.
For a beginner, my experience is that TS is a good way of discovering and working with the complexity and feature set of HTML and web browsers.
TS, in my experience, has limited benefit when it comes to building a UI, and frontend JS is heavily married to UI programming. For guaranteeing UI functionality, writing years is a better use of one's time. What's more important with UI development is the ability to change visual components fast, and TS often gets in the way of that because it's strict as a feature.
Someone who is deep into TS may have the experience such that they are an exception, and can really benefit from using TS across the board. Since the OP is asking for a frontend framework, I would not assume they are one of these exceptions.
Where TS really shines, IMO, is in business logic and library code, because that's where concrete expectations and promises typically lie. TS is also really good for writing backends for similar reasons.
This might be most appropriate for the OP:
Frontend: Some TS for logic that's well separated from the UI, but don't try to make TS work within code that is rendering stuff. Major frameworks put in lots of effort to support TS in the view layer and, with some exceptions, it usually comes with caveats
Tests: Use JS. Your tests should not be an app in and of itself.
Shared libraries: Use TS only if you prefer it or if other entities are using it, in which case TS helps your code fulfill it's promise to third parties.
And if the OP really ends up hating Typescript, then they should just not use it. TS is not a requirement.