Why is taking out the part that actually checks the types at the developer's side a huge blessing?

Or if you are hoping to get the benefit of type checking in the browser itself (taking the same sweet time as tsc, but this time on every browser instead of once in the CI), then how long would you want to wait to be able to actually use the new typing functionality described in e.g. the latest TS annoucement? https://devblogs.microsoft.com/typescript/announcing-typescr... .

Because it would take a while until that would then become the standard and then become available in every browser. And you still need to provide the JS versions, because not every browser is going to support TS.

In the meanwhile you could just keep using tsc just as before and get access to new functionality immediately.

(I imagine you could run tsc in the browser right now if you really wanted to.)

> Why is taking out the part that actually checks the types at the developer's side a huge blessing?

Oh, no, certainly we want to keep type-checking in the pipeline, somewhere.

However, if the browser "understood" typescript, your codebase could have immediate hot-reload, without any transpilation in-between. The type-checking could then be (and already is when using something like esbuild/swc) an entirely separate process that happens independently.

Webpack's HMR is pretty good, but not having to modify the code at all to have it work in the browser, that'd be much much better :)

... the browser being able to typecheck (and reject violating code) itself is certainly something I'd love to see eventually, but fully agreed, this is not happening anytime soon.