Comment by hollowturtle
1 day ago
Because "it doesn't exist". It's just a layer on top of js, it doesn't have its own runtime, and btw what would supporting ts a the browser level mean? If you want to support a static typed language then you could just compile it down to wasm, if you just want to support types and ignore them at runtime there's an overhead price to pay, or should do runtime type checking? And with which tsconfig? Strict or not?
It is a language, it doesn't matter to what it is downcompiled to be able to be run in a browser.
Its now 13 years old, not a hard language to have a proper runtime for it and it would just get rid of all the npm stuff.
And for the amount of typescript we now have, it would be worth it to have proper native support.
> It's just a layer on top of js, it doesn't have its own runtime, and btw what would supporting ts a the browser level mean?
It means that `<script src="some-url.ts">` works.
All good questions. But... it would simply eliminate a step and result in a single language.
Python supports types and is interpreted, right?
Interpreted that's right, in fact it's super slow and adding types adds up to parsing time. Javascript is jitted. Python types serves no purpose if not for documenting or letting the lsp doing some lightweight type checking. And btw typescript introduced many breaking changes and the spec is managed by microsoft something you don't want for the open web. What we would really benefinit from would be having WASM being able to do more inside the browser, like rendering, managing user input, accessibility, dom manipulation. Then u could compile your favorite static types lang down to wasm. Hell even a strictier version of TS could be made to do that, iirc there's something similar called assembly script
Python type annotations are available at runtime, which can be used for serialization and validation (for example in FastAPI).
I mean, all typescript does is serve no purpose except for an LSP and documenting type intention really. It isn't much different to Python type annotation.
Python containing type hints doesn't get transpiled the way typescript does. The transpiling rewrites the TS to varying degrees depending on the target and the extra TS features being used.
Python "just" (that word is doing a lot of work) updated the interpreter to ignore the type hints. It still runs the same way as code without hints.
There's a bit more going on with TS that you couldn't just have the runtime ignore the types.
As I understand it you can, in fact node 23 has a type stripping feature. I could be wrong.
> Because "it doesn't exist". It's just a layer on top of js, ...
C++ was originally a layer on top of C. The first C++ compiler, "cfront" was actually a transpiler to C.
There is nothing preventing TypeScript from becoming "native" in a similar way.
Typescript is only a linter, except for types annotations it is regular JS, quite different from C with Classes.
If you are going to mention enum and namespaces, the team considers them a design error, and only keeps them around due to backwards compatibility.
It doesn't make any sense tho. Typescript is nothing much to do with runtime. It's a build/dev concern. To get JS from TS you're mostly removing the type annotations.
Theres no reason to ship TS to an end user browser.
> Theres no reason to ship TS to an end user browser.
As things are now, developers write code in TypeScript, then debug and update code in Javascript. It might not be much of a reason, but a single language throughout is surely easier on developers and maintainers.