4 ms·

>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 specif

>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"

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"