This is a persistent meme that has no basis in reality. A TypeScript engine is a JavaScript engine, since everything that can be done in JS can be done in TS. It's plausible, maybe, that there could be some additional optimisations on TS code where the engine is sufficiently happy with all types in a subset of the program. But that would be on top of all existing JS engine features, unless you want your engine's performance to suddenly degrade if you stray outside the fully-statically-verifiabe-TS happy path.
That's a pretty obtuse interpretation of the comment. Browsers natively being able to run Typescript code / .ts files instead of requiring transpiling to plain Javascript would be a large boon to the TS ecosystem by making basically everything easier. Even if it's just stripping the TS and running the plain JS it would already be helpful, but it running the typechecking beforehand would be wonderful.
Maybe I was reading too much into the comment I replied to, but to me "a typescript engine" implied more than "ignoring the types" (which is the current TC39 proposal).
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.
Taking one link out of the toolchain (tsc) would already be a huge blessing.
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)
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.
One advantage of Typescript in context of performance should be that it nudges one to not change the 'shape' of runtime objects too much, this should allow less runtime overhead in JS engines because code doesn't need to be re-jitted as often.
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.
A lot of apps would (or at least should) still want to strip types for bundle size reasons though.
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.
My take as an outsider: Google has absolutely no interest in this, especially with their recent cost-cutting measures. Google cares about things that make the "web" better for the end users so that they can sell more ads, not developer tools. TypeScript or JavaScript doesn't matter that much to Google, and actually Google probably doesn't want to see TypeScript files distributed over network (which doesn't make much sense in the first place). In all honesty, Microsoft understands development experience much better than Google and most other companies. They literally own Visual Studio, Visual Studio Code and GitHub and sell products/services for money.
