Because dynamic typing is terrible for big projects, and typescript's fake sense of security doesn't cut it. When you know that your code works you don't need to check it in your browser every nanosecond (although you could).
Updating and checking over and over is usually more about getting the ux right than making it work or fixing bugs. A tight feedback loop makes a huge difference when you're iterating on look and feel. If you have to wait 10 seconds and fill out a form or two to restore the full app state after each change, it becomes a nightmare and you'll likely just give up on making a good ux.
There are also lots of frontend bugs that aren't really bugs in the compiler sense, but just cause the user to see a slightly wrong or confusing thing for a given state. Tests can help, but for a UI with a lot going on, there are usually too many possible paths to write tests for them all, so doing a lot of QA as you go is hard to avoid.
Typescript offers a pretty good balance here since you can turn off typechecking for live reloading and instead check types in the background or as part of the test suite.
You don’t need to check it in your browser at all if you wrote proper tests for it. TypeScript (with proper lint rules) is a huge win in my book compared to vanilla JS. That said, Rust’s compiler guarantees are best in class. The hot-reload, want to see it happen immediately, is great for quick prototypes but for large projects, nothing beats full coverage.