And I was replying based on what I've seen other people saying whenever the subject comes up; apologies if I misread.
Browsers doing type checking is a pretty fraught idea IMO, at least with Typescript and not some other statically typed language entirely.
And naive me hopes for a future where in my web-app I can set a policy that any non-ts, type-incompliant code is not allowed to run.
The amount of exceptions I get in the console from terrible garbage-code outside of my control but that I have to include because enterprise is staggering. Would love to have a meta-setting which would just kill them if they can't be arsed to even have a modicum of code-hygiene (sorry for the rant)
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.)
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.
This doesn't require the type annotations at runtime though, it's just a side effect of code being written against a static type system.
To take one extreme example, a library I work on includes an API for calling a JSON RPC server. Instead of manually implementing each call, we use a proxy object that converts any method call on it to a JSON RPC call. Then layer on types so given an RPC object you know every method on it and have typed input params and output. This means you can have any number of methods without increasing your bundle size, because all the types disappear at runtime. It also means you can add your own methods if you’re talking to a server that implements custom ones by just defining types. If you shipped this to the browser with the types then it’d be a much bigger bundle than without them.