5 ms·

I don't get it why the hell is TypeScript still not nativly supported in modern browsers?

by Curosinono 4mo ago

tuananh 4mo ago
JS promise to never break the web. can't say the same about TS
- bel8 4mo ago
  JS can't really break the web. It's a trillion+ market. If that ever happens for some exquisite reason, it would be forked in under 2 milliseconds by the browser consortium.
vmg12 4mo ago
Likely because everybody would still strip types, bundle and minify their typescript code anyway.
- brazukadev 4mo ago
  it is still a DX improvement
hollowturtle 4mo 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?
- VerifiedReports 4mo ago
  All good questions. But... it would simply eliminate a step and result in a single language. Python supports types and is interpreted, right?
  - hollowturtle 4mo ago
    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
    - sirsinsalot 4mo ago
      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.
    - ngrilly 4mo ago
      Python type annotations are available at runtime, which can be used for serialization and validation (for example in FastAPI).
  - antod 4mo ago
    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.
    - sirsinsalot 4mo ago
      As I understand it you can, in fact node 23 has a type stripping feature. I could be wrong.
- Curosinono 4mo ago
  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.
- wpollock 4mo ago
  > 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.
  - sirsinsalot 4mo ago
    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.
    - wpollock 4mo ago
      > 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.
  - pjmlp 4mo ago
    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.
    - wpollock 4mo ago
      > Typescript is only a linter... I never thought of Typescript (TS) that way. I believe TS is a language addition that enabled smarter JavaScript linters; TS is not a linter program per se. However, TS is more than that now. The extra annotations enable optimizing transpilers and even compilers (to WASM, for instance). This makes TS much more than just a better linter; I think of TS as a better language.
      - pjmlp 4mo ago
- lelanthran 4mo ago
  > 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.
WorldMaker 4mo ago
Because standardization is a political process that takes time and consensus to achieve? https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations
- Curosinono 4mo ago
  TypeScript is now 13 years old. They could have, by now, made it a lot easier to be able to use Typescript in a browser out of the box without magic behind it.
  - WorldMaker 4mo ago
    Typescript certainly hasn't been resting on its laurels. Typescript has always worked pretty well in the browser. You can use the full Typescript LSP in vscode.dev or github.dev just fine. I've even seen websites ship the Typescript compiler as a part of their bundle. It's not the most efficient use of bandwidth, but especially for corporate internal sites if it increases velocity it might not be a bad trade-off. Though it made more sense in the AMD and SystemJS days than in the ESM. Typescript also support JSDoc mode very well where you have all your types in comments instead of inline. JSDoc type checked files run just fine in the browser without transpilation. Typescript has also invested a lot into "Isolated Modules" and "Verbatim Module Syntax" and linting for such. This tooling makes it easier to keep modules cleanly type strippable without needing to run the full compiler. (This is something that Node support for Typescript requires, for example.) "Isolated Modules" also get code ready for the Type Annotations support if that gets to the next stage with TC-39. It also makes it possible to bundle a small, fast type stripper in the browser as a module loading plugin, should ESM get module loading plugins ahead of Type Annotations support. (There are proposals for that in front of TC-39 as well.)
  - pier25 4mo ago
    True but it only became the "default" choice a couple of years ago. Before eg 2020 it still wasn't clear if TS was another CoffeeScript.
IshKebab 4mo ago
There wouldn't be any benefit. It's not sound so it can't really be used to improve performance. There was a proposal to support TypeScript syntax, but ignore the actual types (this is basically how Python works). That would be kind of nice because you can skip the compilation step completely (less faff for small projects), but I don't think it went anywhere... or if it is it's getting there at a snail's pace: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations
yoyohello13 4mo ago
My gripe is why doesn't Webassembly fully support dom manipulation. If we got that working anyone could just bring any language to the browser and we would finally be free from the shackles of JS.
- sirsinsalot 4mo ago
  Or at least some kind of cursor based text buffer tree that wasm can bind to the dom/shadow tree, rather than a fuller API
deleted 4mo ago
[deleted]
pier25 4mo ago
It's probably coming: https://tc39.es/proposal-type-annotations/ https://tc39.es/proposal-type-annotations/
yesbabyyes 4mo ago
Just make it a habit to write your types in JSDoc and be done with it. It's so much nicer in every way. Typescript checks your types, you are incentivized to write some brief documentation, and (self promotion) if you use something like my library testy you get your JSDoc examples tested. https://github.com/linus/testy https://github.com/linus/testy

I don't get it why the hell is TypeScript still not nativly supported in modern browsers?

tuananh 4mo ago

JS promise to never break the web. can't say the same about TS

bel8 4mo ago
JS can't really break the web. It's a trillion+ market. If that ever happens for some exquisite reason, it would be forked in under 2 milliseconds by the browser consortium.

vmg12 4mo ago

Likely because everybody would still strip types, bundle and minify their typescript code anyway.

brazukadev 4mo ago
it is still a DX improvement

hollowturtle 4mo 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?

VerifiedReports 4mo ago
All good questions. But... it would simply eliminate a step and result in a single language. Python supports types and is interpreted, right?
- hollowturtle 4mo ago
  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
  - sirsinsalot 4mo ago
    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.
  - ngrilly 4mo ago
    Python type annotations are available at runtime, which can be used for serialization and validation (for example in FastAPI).
- antod 4mo ago
  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.
  - sirsinsalot 4mo ago
    As I understand it you can, in fact node 23 has a type stripping feature. I could be wrong.
Curosinono 4mo ago
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.
wpollock 4mo ago
> 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.
- sirsinsalot 4mo ago
  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.
  - wpollock 4mo ago
    > 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.
- pjmlp 4mo ago
  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.
  - wpollock 4mo ago
    > Typescript is only a linter... I never thought of Typescript (TS) that way. I believe TS is a language addition that enabled smarter JavaScript linters; TS is not a linter program per se. However, TS is more than that now. The extra annotations enable optimizing transpilers and even compilers (to WASM, for instance). This makes TS much more than just a better linter; I think of TS as a better language.
    - pjmlp 4mo ago
lelanthran 4mo ago
> 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.

WorldMaker 4mo ago

Because standardization is a political process that takes time and consensus to achieve? https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations

Curosinono 4mo ago
TypeScript is now 13 years old. They could have, by now, made it a lot easier to be able to use Typescript in a browser out of the box without magic behind it.
- WorldMaker 4mo ago
  Typescript certainly hasn't been resting on its laurels. Typescript has always worked pretty well in the browser. You can use the full Typescript LSP in vscode.dev or github.dev just fine. I've even seen websites ship the Typescript compiler as a part of their bundle. It's not the most efficient use of bandwidth, but especially for corporate internal sites if it increases velocity it might not be a bad trade-off. Though it made more sense in the AMD and SystemJS days than in the ESM. Typescript also support JSDoc mode very well where you have all your types in comments instead of inline. JSDoc type checked files run just fine in the browser without transpilation. Typescript has also invested a lot into "Isolated Modules" and "Verbatim Module Syntax" and linting for such. This tooling makes it easier to keep modules cleanly type strippable without needing to run the full compiler. (This is something that Node support for Typescript requires, for example.) "Isolated Modules" also get code ready for the Type Annotations support if that gets to the next stage with TC-39. It also makes it possible to bundle a small, fast type stripper in the browser as a module loading plugin, should ESM get module loading plugins ahead of Type Annotations support. (There are proposals for that in front of TC-39 as well.)
- pier25 4mo ago
  True but it only became the "default" choice a couple of years ago. Before eg 2020 it still wasn't clear if TS was another CoffeeScript.

IshKebab 4mo ago

There wouldn't be any benefit. It's not sound so it can't really be used to improve performance. There was a proposal to support TypeScript syntax, but ignore the actual types (this is basically how Python works). That would be kind of nice because you can skip the compilation step completely (less faff for small projects), but I don't think it went anywhere... or if it is it's getting there at a snail's pace: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations

yoyohello13 4mo ago

My gripe is why doesn't Webassembly fully support dom manipulation. If we got that working anyone could just bring any language to the browser and we would finally be free from the shackles of JS.

sirsinsalot 4mo ago
Or at least some kind of cursor based text buffer tree that wasm can bind to the dom/shadow tree, rather than a fuller API

deleted 4mo ago

[deleted]

pier25 4mo ago

It's probably coming: https://tc39.es/proposal-type-annotations/ https://tc39.es/proposal-type-annotations/

yesbabyyes 4mo ago

Just make it a habit to write your types in JSDoc and be done with it. It's so much nicer in every way. Typescript checks your types, you are incentivized to write some brief documentation, and (self promotion) if you use something like my library testy you get your JSDoc examples tested. https://github.com/linus/testy https://github.com/linus/testy