You'll still get all the strong typing without have to wait for it to run.
For example an error in a little used branch would cause an error before the branch even runs.
Is it? My experience in the past decade is that there are more memes about people who confuse the 2 than people that confuse the 2.
It's also better if there's one ecosystem instead of one fragmented with different languages where you have to write bindings for everything you want to use.
The alternative is not "User sees no error", it's "user sees the error at runtime".
In which case, yeah, having the user see the type error is vastly preferable to having the user see a runtime JS error.
It is really powerful as compared to Javascript. It is even really powerful as compared to most other languages people normally use. But not very powerful as compared to languages that have 'proper' type systems. Typescript still relies on you writing tests for everything.
The type system is a huge boon for the developer experience, of course. It enables things like automatic refactoring that make development much more pleasant (although LLMs are getting better at filling that void in dynamically typed languages). But it doesn't save you from bugs in a way that the tests you have to write anyway won't also save you from. And those same tests would also catch the same bugs in Javascript, so you're in the same place either way with respect to that.
Put another way, I'm fine with the TS syntax (and use TS because there aren't other choices), but the TS semantics aren't a good long-term solution.
This argument is slightly backwards. This is essentially the argument used for "javascript in the backend" and "let's package the whole browser as application runtime so we can use javascript". The core of the argument is that javascript is ipso facto the best language/runtime to write any code in, including refactoring existing codebases. Bringing javascript out of the browser also means you have to write bindings for javascript and recreate the existing ecosystems anyway.
Even if you approach this from "single codebase across runtimes" angle, the conclusion to bridge the gap between browsers and languages with existing codebase, expertise and ecosystems is much more reasonable than rewrite everything in javascript.
Right now, sure.
But if TS is supported natively in the browser, wouldn't your editor highlight the errors as you type? In which case the chance of deploying a broken TS file to the browser is minimal - you'll have to go out of your way to do so, like writing the TS file in plain notepad.
To go even further, having TS supported in the browser does not mean that you are forced to abandon your build step(s). You are still free to run a build step that either:
1. Does the full compilation to JS, and that's what gets deployed.
or
2. Just lints the file, and has the original TS file deployed.
Nothing in "Native TS in the browser" enforces a no-build-step dev process; it just makes it optional.
There's also the fact that, if JS is no longer the target (either browser-byte-code or native-code will be the target), then type-checking can be improved even further because there will be no requirement to allow things purely due to JS compatibility.
Finally, there's an awfully large number of optimisations that can be done if JS is not the target and native-code is.
I'm not seeing any downside here.
So I'm not necessarily saying it's a bad thing, it's just that I don't see the point. And given that there's the major downside of having to go through the standards process, both now and in the future, which will likely involve breaking changes and making it harder to update, I don't see it happening. (Edit: I should add that I do think the "types as comments" proposal makes sense. I do see the advantage of being able to run TS code without a build step. It's just the part where we'd throw an error in the user's face that I don't see providing value to anyone.)
I do think TC39 is progressive enough to be OK with changes to JS if those would allow TS to have more effective type checking (as long as they're backwards compatible, of course, which would also be the case if TS got incorporated into JS), so I don't think it's necessary for that.
Performance improvements enabled by optimisations would be nice, but I believe I heard that no major gains would be expected there, especially compared to something like WASM.