5 ms·

Sounds like a bad idea. I get it that not specifying type syntax makes it the most flexible, but also prevents any actual checks and optimizations from being pe

Sounds like a bad idea. I get it that not specifying type syntax makes it the most flexible, but also prevents any actual checks and optimizations from being performed by the browser. So it’s just inflating bundle sizes for no reason. Might as well run them through something that checks then removes type annotations… which is what we already have

lagrange77 4y ago
> So it’s just inflating bundle sizes for no reason. When using a bundler, it will be trivial to remove the annotations in the build process. Using a TypeScript transpiler in that process is also trivial you might say. But static typing syntax and tooling as part of the language itself is the way to go imo.
- Matheus28 4y ago
  >But static typing syntax and tooling as part of the language itself is the way to go imo. But if the typing syntax is essentially just comments in very specific places... what advantage does it bring? Sure one can use tools to interpret those comments and check types... but at that point, isn't just using typescript tooling much superior (interface declaration, type declarations, etc. not just a type between : and =)? I will confess that I am guilty of having used JSDoc comments for quick and dirty .js scripts that I didn't want to grab the tsc compiler for, but still wanted vscode to check my types. But even being one of the likely users of this proposal, I feel that it's needlessly bloating the language.
  - lagrange77 4y ago
    > what advantage does it bring? The advantage would be, that static typing is part of the language. Don't you find it odd to use another language just for a missing language feature? For me it feels somewhat hacky and '// temp. solution!!! fix soon!'-worthy.
    - Matheus28 4y ago
      But with this proposal, static typing wouldn't be part of the language. It's just a fancy looking comment. No different than using JSDoc with a nicer syntax
      - lagrange77 4y ago
        Ok agreed, i would also like to have the type checker build into the language as well. But in the end, this is a scripting language. Maybe it's not too bad to not enforce it being typed, but provide a baseline to have it being typed optionally, in form of an 'official' annotation syntax. But i'm thinking out loud now.
        Matheus28 4y ago
        I just think it'd overcomplicate implementations. We already have typescript and such, and they work perfectly. It's my personal belief that integrating those things into the language would slow innovation.
        kaba0 4y ago
        But we are talking about a language that is streamed over the internet in absurd quantities, and thus has dedicated tools to make it unreadably small as to better utilize bandwidth. Adding any fluff that is not even useful/get utilized on the frontend side is not a good idea.
    - yakshaving_jgt 4y ago
      > Don't you find it odd to use another language just for a missing language feature? No. Why do you? For a language to not try and have all the features it possibly can is a feature.
      - lagrange77 4y ago
        > No. Why do you? I mean, i like TypeScript a lot. I think i do find it odd, because i'm used to using languages, that are constructed with a certain feature set. Obviously Java/ECMA Script evolved a lot more chaotic than most other languages. Transpiling a superset of a language to its subset introduces indirection, which makes it feel hacky imo. I feel like, if there is another language feature we want to add in the future, how should that be injected? In form of a superset of TypeScript? I would be cool with TypeScript as the target language, though.
  - rektide 4y ago
    > But if the typing syntax is essentially just comments in very specific places... what advantage does it bring? It means the supplemental information needed to run either static or dynamic type-checking is there & so that either browsers or toolchains can use it. And it means that the code would just run on existing systems. For production we'd probably want to strip out comments, but for production we already often do strip out comments (which I wish could be "undone" on most sites by users wanting to know! View source!!). Let's turn your question around: what advantage does existing typescript language have, over a backwards-compatible & type-carrying enhancement to JS?
    - Matheus28 4y ago
      >It means the supplemental information needed to run either static or dynamic type-checking is there & so that either browsers or toolchains can use it. The format isn't specified, it's just a comment. Browsers can't take advantage of it. Toolchains already do cross-compiling when they're bundling anyway, so it's not required on that front. >what advantage does existing typescript language have, over a backwards-compatible & type-carrying enhancement to JS? Typescript is on a much faster release schedule than the standards. Just think of how slowly its (amazing) type system would've evolved if designed by committee. I'd be all for a type system in javascript a couple of years ago. But seeing how fast typescript evolved when it's not limited by a committee, I think that keeping that separate of the main language is completely acceptable.
      - rektide 4y ago
        > The format isn't specified, it's just a comment The authors intend to support a variety of type systems, such as TypeScript & Flow. That TypeScript would need to define it's own grammar doesn't seem harmful, & would surely be standardized quickly, exterior to this more general spec. Latter you say: "Typescript is on a much faster release schedule than the standards." Well, since the format isn't specified, TypeScript is free to release at their leisure. Not bundling orthogonal concerns together, providing low-level extensible capabilities is a win. > Browsers can't take advantage of it. Why not? They could. > Toolchains already do cross-compiling when they're bundling anyway, so it's not required on that front. Ok, but you're ignoring the goal of this proposal: "The aim of this proposal is to enable developers to run programs written in TypeScript, Flow, and other static typing supersets of JavaScript without any need for transpilation"
- asddubs 4y ago
  it should also be enforced by the language. and then you can still check and remove it using a transpiler, if you want (for smaller sizes + speedup due to lack of type checks). but if you're gonna add type annotations, they should do something
  - lagrange77 4y ago
    > it should also be enforced by the language. yes maybe with a 'use typestrict' directive or something.
jupp0r 4y ago
It would be great to be able to have access to types at runtime in order to change behavior based on types. That would make TypeScript so much more useful but it does require javascript support.
- Matheus28 4y ago
  You should try decorators for that. They're pretty decent
  - jupp0r 4y ago
    Yeah it's a workaround, but not really ergonomical for the library author (for example they can't modify the type being decorated).
- mixedCase 4y ago
  You can use a runtime type system like io-ts or something like reflect-metadata. Let's not pay the cost when we don't need it.
  - jupp0r 4y ago
    The compiler knows when this is used and can only insert type metadata when needed. io-ts and reflect-metadata are unwieldy crutches compared to a type system that's designed to influence runtime behavior (ie Rust, C++, etc).
    - rektide 4y ago
      https://github.com/tc39/proposal-decorator-metadata https://github.com/tc39/proposal-decorator-metadata is where we'd probably need to begin to store this information. It's still need a transpiler to generate the necessary decorators. Decorators are still in progress (but kind of seemingly shaping up these days).
cookiengineer 4y ago
I don't understand what effect it would have on bundle sizes? If you are going to transpile/bundle your assets, you're probably using webasm at some point...or not!? And nobody forces you to have typed minified JS in your bundles?
- Matheus28 4y ago
  But if you're already transpiling/bundling your assets, why not use typescript? Instead of bloating the language and browsers even more. Not only that, but solidifying an interface there. Once it's done, it'll be very hard to change, as people will rely on all sorts of quirky behaviors.
hardwaregeek 4y ago
By that same logic, comments are inflating the bundle size. Both can be stripped out using a minifier or bundler.
Matheus28 4y ago
footnote: Looking at my phone's browser history, I read the article at https://tc39.es/proposal-type-annotations https://tc39.es/proposal-type-annotations when making this comment. Not the github repo. I hadn't dove too deep into it, but it does seem that it specifies a syntax for the top level type declaration. I initially believed it was entirely unspecified what the contents between the : and = were. But it does try to specify some rules, but leaving anything inside a {}, [], <> and such completely unspecified. My feelings are still the same in that I don't support the proposal.

lagrange77 4y ago

> So it’s just inflating bundle sizes for no reason. When using a bundler, it will be trivial to remove the annotations in the build process. Using a TypeScript transpiler in that process is also trivial you might say. But static typing syntax and tooling as part of the language itself is the way to go imo.

Matheus28 4y ago
>But static typing syntax and tooling as part of the language itself is the way to go imo. But if the typing syntax is essentially just comments in very specific places... what advantage does it bring? Sure one can use tools to interpret those comments and check types... but at that point, isn't just using typescript tooling much superior (interface declaration, type declarations, etc. not just a type between : and =)? I will confess that I am guilty of having used JSDoc comments for quick and dirty .js scripts that I didn't want to grab the tsc compiler for, but still wanted vscode to check my types. But even being one of the likely users of this proposal, I feel that it's needlessly bloating the language.
- lagrange77 4y ago
  > what advantage does it bring? The advantage would be, that static typing is part of the language. Don't you find it odd to use another language just for a missing language feature? For me it feels somewhat hacky and '// temp. solution!!! fix soon!'-worthy.
  - Matheus28 4y ago
    But with this proposal, static typing wouldn't be part of the language. It's just a fancy looking comment. No different than using JSDoc with a nicer syntax
    - lagrange77 4y ago
      Ok agreed, i would also like to have the type checker build into the language as well. But in the end, this is a scripting language. Maybe it's not too bad to not enforce it being typed, but provide a baseline to have it being typed optionally, in form of an 'official' annotation syntax. But i'm thinking out loud now.
      - Matheus28 4y ago
        I just think it'd overcomplicate implementations. We already have typescript and such, and they work perfectly. It's my personal belief that integrating those things into the language would slow innovation.
      - kaba0 4y ago
        But we are talking about a language that is streamed over the internet in absurd quantities, and thus has dedicated tools to make it unreadably small as to better utilize bandwidth. Adding any fluff that is not even useful/get utilized on the frontend side is not a good idea.
  - yakshaving_jgt 4y ago
    > Don't you find it odd to use another language just for a missing language feature? No. Why do you? For a language to not try and have all the features it possibly can is a feature.
    - lagrange77 4y ago
      > No. Why do you? I mean, i like TypeScript a lot. I think i do find it odd, because i'm used to using languages, that are constructed with a certain feature set. Obviously Java/ECMA Script evolved a lot more chaotic than most other languages. Transpiling a superset of a language to its subset introduces indirection, which makes it feel hacky imo. I feel like, if there is another language feature we want to add in the future, how should that be injected? In form of a superset of TypeScript? I would be cool with TypeScript as the target language, though.
- rektide 4y ago
  > But if the typing syntax is essentially just comments in very specific places... what advantage does it bring? It means the supplemental information needed to run either static or dynamic type-checking is there & so that either browsers or toolchains can use it. And it means that the code would just run on existing systems. For production we'd probably want to strip out comments, but for production we already often do strip out comments (which I wish could be "undone" on most sites by users wanting to know! View source!!). Let's turn your question around: what advantage does existing typescript language have, over a backwards-compatible & type-carrying enhancement to JS?
  - Matheus28 4y ago
    >It means the supplemental information needed to run either static or dynamic type-checking is there & so that either browsers or toolchains can use it. The format isn't specified, it's just a comment. Browsers can't take advantage of it. Toolchains already do cross-compiling when they're bundling anyway, so it's not required on that front. >what advantage does existing typescript language have, over a backwards-compatible & type-carrying enhancement to JS? Typescript is on a much faster release schedule than the standards. Just think of how slowly its (amazing) type system would've evolved if designed by committee. I'd be all for a type system in javascript a couple of years ago. But seeing how fast typescript evolved when it's not limited by a committee, I think that keeping that separate of the main language is completely acceptable.
    - rektide 4y ago
      > The format isn't specified, it's just a comment The authors intend to support a variety of type systems, such as TypeScript & Flow. That TypeScript would need to define it's own grammar doesn't seem harmful, & would surely be standardized quickly, exterior to this more general spec. Latter you say: "Typescript is on a much faster release schedule than the standards." Well, since the format isn't specified, TypeScript is free to release at their leisure. Not bundling orthogonal concerns together, providing low-level extensible capabilities is a win. > Browsers can't take advantage of it. Why not? They could. > Toolchains already do cross-compiling when they're bundling anyway, so it's not required on that front. Ok, but you're ignoring the goal of this proposal: "The aim of this proposal is to enable developers to run programs written in TypeScript, Flow, and other static typing supersets of JavaScript without any need for transpilation"
asddubs 4y ago
it should also be enforced by the language. and then you can still check and remove it using a transpiler, if you want (for smaller sizes + speedup due to lack of type checks). but if you're gonna add type annotations, they should do something
- lagrange77 4y ago
  > it should also be enforced by the language. yes maybe with a 'use typestrict' directive or something.

jupp0r 4y ago

It would be great to be able to have access to types at runtime in order to change behavior based on types. That would make TypeScript so much more useful but it does require javascript support.

Matheus28 4y ago
You should try decorators for that. They're pretty decent
- jupp0r 4y ago
  Yeah it's a workaround, but not really ergonomical for the library author (for example they can't modify the type being decorated).
mixedCase 4y ago
You can use a runtime type system like io-ts or something like reflect-metadata. Let's not pay the cost when we don't need it.
- jupp0r 4y ago
  The compiler knows when this is used and can only insert type metadata when needed. io-ts and reflect-metadata are unwieldy crutches compared to a type system that's designed to influence runtime behavior (ie Rust, C++, etc).
  - rektide 4y ago
    https://github.com/tc39/proposal-decorator-metadata https://github.com/tc39/proposal-decorator-metadata is where we'd probably need to begin to store this information. It's still need a transpiler to generate the necessary decorators. Decorators are still in progress (but kind of seemingly shaping up these days).

cookiengineer 4y ago

I don't understand what effect it would have on bundle sizes? If you are going to transpile/bundle your assets, you're probably using webasm at some point...or not!? And nobody forces you to have typed minified JS in your bundles?

Matheus28 4y ago
But if you're already transpiling/bundling your assets, why not use typescript? Instead of bloating the language and browsers even more. Not only that, but solidifying an interface there. Once it's done, it'll be very hard to change, as people will rely on all sorts of quirky behaviors.

hardwaregeek 4y ago

By that same logic, comments are inflating the bundle size. Both can be stripped out using a minifier or bundler.

Matheus28 4y ago

footnote: Looking at my phone's browser history, I read the article at https://tc39.es/proposal-type-annotations https://tc39.es/proposal-type-annotations when making this comment. Not the github repo. I hadn't dove too deep into it, but it does seem that it specifies a syntax for the top level type declaration. I initially believed it was entirely unspecified what the contents between the : and = were. But it does try to specify some rules, but leaving anything inside a {}, [], <> and such completely unspecified. My feelings are still the same in that I don't support the proposal.