6 ms·

It's about time for TC39 and Microsoft to standardize TypeScript as part of JavaScript. Not "types as comments" either, but actually TypeScript, minus the non-s

It's about time for TC39 and Microsoft to standardize TypeScript as part of JavaScript. Not "types as comments" either, but actually TypeScript, minus the non-standard runtime semantics and modulo whatever changes are necessary to integrate the grammar. So many runtimes and tools are integrating TypeScript now, and with multiple implementations, that a real standard is necessary. It'll be much harder to evolve TypeScript because it'll have to stay backwards compatible, but it's grown to that point now, imo.

vivzkestrel 2y ago
its about time google chrome started making a typescript engine maybe? and get rid of JS in phases?
- jjk7 2y ago
  There are a few optimizations that types can use but 99% of applications wouldn't benefit from them anyways.
  - Shacklz 2y ago
    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)
    - _flux 2y ago
      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-typescript-5-5/ 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.)
      - Shacklz 2y ago
        > 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.
  - flohofwoe 2y ago
    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.
- crabmusket 2y ago
  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.
  - dtech 2y ago
    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.
    - crabmusket 2y ago
      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.
- mcintyre1994 2y ago
  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.
- rty32 2y ago
  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.
mythz 2y ago
This has been proposed for several years now, but there's been very little progress on it: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations
- spankalee 2y ago
  That is "types as comments", not standardizing TypeScript.
  - dgellow 2y ago
    It is explicitly not type as comments, it is type erasure
    - spankalee 2y ago
      > This proposal aims to enable developers to add type annotations to their JavaScript code, allowing those annotations to be checked by a type checker that is external to JavaScript. At runtime, a JavaScript engine ignores them, treating the types as comments.
      - dgellow 2y ago
        Yes, that’s explaining what type erasure is. “type as comments” is what Flow supports, literal comments for type annotations. I think we disagree on the terminology but agree on the goal of the proposal
        eyelidlessness 2y ago
        The proposal would explicitly treat supported type annotation syntax as comments in the grammar. It is definitely types as comments, even if it is also type erasure. And it would apply to Flow’s type annotation syntax which is also not presently treated as comments, at least for the very large subset of that syntax which overlaps with the proposal.
paulddraper 2y ago
TypeScript used to have a standard. Years and years ago. Now it's whatever the compiler does. Which to be fair, is evolving quite rapidly.
- spankalee 2y ago
  Yeah, that was from 2016 or so. But a TypeScript spec is different than folding TypeScript into the ECMAScript standard. Some parts of TypeScript would have to be dropped or changed for that to work.
  - paulddraper 2y ago
    Right, having a spec is easier (and effectively prerequisite) to your suggestion. But they don't have it.
tylerchilds 2y ago
i’m not sure i buy the “company floods the industry with broken tooling and deserves to be standardized” narrative. yeah, the ecosystem sucks, but rewarding the system incentivized to co-opt the system will actually make things worse in the long run, not better. for example, internet explorer failed why?
- dgellow 2y ago
  What broken tooling are you talking about? tsc is broken? IE failed because it was a horrible browser that didn’t evolve for years and was incompatible with major web standard developments. Nothing to do with typescript, an open source, best in class type system and type checker.
  - tylerchilds 2y ago
    IE failed because they tried to define the standard as themselves. i argue we’re witnessing that again from the same company that only gave up that strategy once they had typescript, github, npm locked in. i’m not bullish on political strategies being technical solutions, which is the premise. typescript has nothing to do with internet explorer, true, but is it really not obvious that it is the same tactic as a different brand? become the standard, steer the committee. and broken in that copying code between systems requires compatibility between configurations, which should be a red flag for any language.
  - tylerchilds 2y ago
    “During the transpilation process, no type checking is performed, and types are discarded.” this node feature is primarily around disregarding typescript in favor of the underlying javascript it represents. that reminds me of this fun article: https://www.richard-towers.com/2023/03/11/typescripting-the-technical-interview.html https://www.richard-towers.com/2023/03/11/typescripting-the-...
    - dgellow 2y ago
      Yes, the feature is about being able to run typescript scripts. It’s not a type checker, it is similar to ts-node, deno, bun, etc. Typescript has been designed for that specific purpose.
deleted 2y ago
[deleted]
dgellow 2y ago
I would rather let Typescript evolve a few more years before freezing its development via standardization
- suby 2y ago
  I'm interested to know what are some things that you (or anyone reading this) feels that Typescript is missing / should change?
  - _flux 2y ago
    I don't have a list and I don't even write TS (or do much web dev in general), but I do follow their announcements and it seems every one of them brings new big type things. Nevertheless, I don't see TS support in e.g. browsers being anything useful, as in practice all JS code deployed is already packaged somehow, so the stage to convert TS to JS (and then also checking the types..) fits that just fine. It's useful for hobbyists, but I don't that is a reason enough to come up with a standard.
  - rty32 2y ago
    One example: https://github.com/microsoft/TypeScript/issues/30551 https://github.com/microsoft/TypeScript/issues/30551 Which goes to https://github.com/microsoft/TypeScript/issues/9998 https://github.com/microsoft/TypeScript/issues/9998 which captures a lot of such scenarios And just a few releases ago there were some big problems with handling recursive types. I think most are fixed but there may still be a few around. These are things that you run into on a daily basis if you write enough TypeScript. I doubt we should standardize TypeScript before we have definitive solutions to all these. And I 100% agree with the parent's comment.
  - low_tech_punk 2y ago
    Maybe it's helpful to analyze TypeScript's track record in deprecating features and creating breaking changes, which could be a big red flag to TC39. I'm all for typing support but my work is mostly prototyping on short lived projects. People maintaining production systems that will eventually become legacy systems might have a different opinion.
silverwind 2y ago
Imho standardizing the syntax is enough and this is what https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations does. The type checker is immensely complex and should be left out so that other type checkers can be developed, e.g. similar to how it's for Python today.
- spankalee 2y ago
  That doesn't standardize the syntax, only types-as-comments. It would have to standardize some delimiters for type expressions, but that's it. I do think that the semantics should be standardized too, otherwise you have non-interoperable types. The goal should be that you can use two libraries together without having to make sure they use the same type-checker.
pier25 2y ago
Another reason is probably performance. Executing TS would require a lot of extra CPU and even more energy than JS. A lot of effort and money has been invested into JS engines. I wonder if making a TS native engine (which nobody has made yet) from scratch might make more sense than adapting JS engines to run TS.
hajile 2y ago
TS is an intentionally unsound type system that tries to allow you to type your code no matter if it will run like garbage, is unreadably complex, and uses terrible parts of the language. What TC39 needs is a type system that limits what you can do to things that are sound, performant, and good practice. TS is the exact opposite of this.
nektro 2y ago
TC39 standardizing TypeScript as part of JavaScript would be a critical error. TC39's job is to look at all the options and make something better. TypeScript won out in popularity due to its tight integration with VSCode. it's not necessarily the best route for the core language.

vivzkestrel 2y ago

its about time google chrome started making a typescript engine maybe? and get rid of JS in phases?

jjk7 2y ago
There are a few optimizations that types can use but 99% of applications wouldn't benefit from them anyways.
- Shacklz 2y ago
  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)
  - _flux 2y ago
    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-typescript-5-5/ 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.)
    - Shacklz 2y ago
      > 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.
- flohofwoe 2y ago
  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.
crabmusket 2y ago
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.
- dtech 2y ago
  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.
  - crabmusket 2y ago
    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.
mcintyre1994 2y ago
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.
rty32 2y ago
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.

mythz 2y ago

This has been proposed for several years now, but there's been very little progress on it: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations

spankalee 2y ago
That is "types as comments", not standardizing TypeScript.
- dgellow 2y ago
  It is explicitly not type as comments, it is type erasure
  - spankalee 2y ago
    > This proposal aims to enable developers to add type annotations to their JavaScript code, allowing those annotations to be checked by a type checker that is external to JavaScript. At runtime, a JavaScript engine ignores them, treating the types as comments.
    - dgellow 2y ago
      Yes, that’s explaining what type erasure is. “type as comments” is what Flow supports, literal comments for type annotations. I think we disagree on the terminology but agree on the goal of the proposal
      - eyelidlessness 2y ago
        The proposal would explicitly treat supported type annotation syntax as comments in the grammar. It is definitely types as comments, even if it is also type erasure. And it would apply to Flow’s type annotation syntax which is also not presently treated as comments, at least for the very large subset of that syntax which overlaps with the proposal.

paulddraper 2y ago

TypeScript used to have a standard. Years and years ago. Now it's whatever the compiler does. Which to be fair, is evolving quite rapidly.

spankalee 2y ago
Yeah, that was from 2016 or so. But a TypeScript spec is different than folding TypeScript into the ECMAScript standard. Some parts of TypeScript would have to be dropped or changed for that to work.
- paulddraper 2y ago
  Right, having a spec is easier (and effectively prerequisite) to your suggestion. But they don't have it.

tylerchilds 2y ago

i’m not sure i buy the “company floods the industry with broken tooling and deserves to be standardized” narrative. yeah, the ecosystem sucks, but rewarding the system incentivized to co-opt the system will actually make things worse in the long run, not better. for example, internet explorer failed why?

dgellow 2y ago
What broken tooling are you talking about? tsc is broken? IE failed because it was a horrible browser that didn’t evolve for years and was incompatible with major web standard developments. Nothing to do with typescript, an open source, best in class type system and type checker.
- tylerchilds 2y ago
  IE failed because they tried to define the standard as themselves. i argue we’re witnessing that again from the same company that only gave up that strategy once they had typescript, github, npm locked in. i’m not bullish on political strategies being technical solutions, which is the premise. typescript has nothing to do with internet explorer, true, but is it really not obvious that it is the same tactic as a different brand? become the standard, steer the committee. and broken in that copying code between systems requires compatibility between configurations, which should be a red flag for any language.
- tylerchilds 2y ago
  “During the transpilation process, no type checking is performed, and types are discarded.” this node feature is primarily around disregarding typescript in favor of the underlying javascript it represents. that reminds me of this fun article: https://www.richard-towers.com/2023/03/11/typescripting-the-technical-interview.html https://www.richard-towers.com/2023/03/11/typescripting-the-...
  - dgellow 2y ago
    Yes, the feature is about being able to run typescript scripts. It’s not a type checker, it is similar to ts-node, deno, bun, etc. Typescript has been designed for that specific purpose.

deleted 2y ago

[deleted]

dgellow 2y ago

I would rather let Typescript evolve a few more years before freezing its development via standardization

suby 2y ago
I'm interested to know what are some things that you (or anyone reading this) feels that Typescript is missing / should change?
- _flux 2y ago
  I don't have a list and I don't even write TS (or do much web dev in general), but I do follow their announcements and it seems every one of them brings new big type things. Nevertheless, I don't see TS support in e.g. browsers being anything useful, as in practice all JS code deployed is already packaged somehow, so the stage to convert TS to JS (and then also checking the types..) fits that just fine. It's useful for hobbyists, but I don't that is a reason enough to come up with a standard.
- rty32 2y ago
  One example: https://github.com/microsoft/TypeScript/issues/30551 https://github.com/microsoft/TypeScript/issues/30551 Which goes to https://github.com/microsoft/TypeScript/issues/9998 https://github.com/microsoft/TypeScript/issues/9998 which captures a lot of such scenarios And just a few releases ago there were some big problems with handling recursive types. I think most are fixed but there may still be a few around. These are things that you run into on a daily basis if you write enough TypeScript. I doubt we should standardize TypeScript before we have definitive solutions to all these. And I 100% agree with the parent's comment.
- low_tech_punk 2y ago
  Maybe it's helpful to analyze TypeScript's track record in deprecating features and creating breaking changes, which could be a big red flag to TC39. I'm all for typing support but my work is mostly prototyping on short lived projects. People maintaining production systems that will eventually become legacy systems might have a different opinion.

silverwind 2y ago

Imho standardizing the syntax is enough and this is what https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations does. The type checker is immensely complex and should be left out so that other type checkers can be developed, e.g. similar to how it's for Python today.

spankalee 2y ago
That doesn't standardize the syntax, only types-as-comments. It would have to standardize some delimiters for type expressions, but that's it. I do think that the semantics should be standardized too, otherwise you have non-interoperable types. The goal should be that you can use two libraries together without having to make sure they use the same type-checker.

pier25 2y ago

Another reason is probably performance. Executing TS would require a lot of extra CPU and even more energy than JS. A lot of effort and money has been invested into JS engines. I wonder if making a TS native engine (which nobody has made yet) from scratch might make more sense than adapting JS engines to run TS.

hajile 2y ago

TS is an intentionally unsound type system that tries to allow you to type your code no matter if it will run like garbage, is unreadably complex, and uses terrible parts of the language. What TC39 needs is a type system that limits what you can do to things that are sound, performant, and good practice. TS is the exact opposite of this.

nektro 2y ago

TC39 standardizing TypeScript as part of JavaScript would be a critical error. TC39's job is to look at all the options and make something better. TypeScript won out in popularity due to its tight integration with VSCode. it's not necessarily the best route for the core language.