5 ms·

As someone who doesn't really work with neither JS or TS, the proposed JS type system looks superficially very similar to TS. Is this "backporting" TS to JS or

As someone who doesn't really work with neither JS or TS, the proposed JS type system looks superficially very similar to TS. Is this "backporting" TS to JS or is there something else I'm missing?

icholy 5y ago
It's the TS team making the proposal.
idontknowifican 5y ago
this is common in ECMAScript. see coffeescript and arrow functions
jayrhynas 5y ago
As far as I understand it, this is allowing TS types to be valid JS syntax that are just ignored by vanilla JS engines. So it is intentionally identical to TS, it just won’t have any affect on the execution of your code.
- Ndymium 5y ago
  It's not identical as features that have a difference on the runtime behaviour / code generation such as enums are deliberately omitted. It's intended to be a large subset of TS at first. [0] [0] https://devblogs.microsoft.com/typescript/a-proposal-for-type-syntax-in-javascript/ https://devblogs.microsoft.com/typescript/a-proposal-for-typ...
- nerdponx 5y ago
  For perspective, this is more or less what Python did. Originally Mypy was supposed to be a Python superset, like TypeScript, but instead its variable annotation syntax was adopted as Python syntax. It has been an interesting journey for Python, with a lot of ups and downs. Type hints, for all their productivity and bug-safety benefits in most cases, still feel like a bolt-on feature that requires developers to change how they write code, and in many cases favors less-performant idioms and/or extra boilerplate compared to un-hinted Python. Whereas TypeScript has a lot more freedom to mess with how things work, because it's a superset that compiles to JavaScript and not actual JavaScript. So it's somewhat surprising to see this proposal for JavaScript, because the TypeScript model always seemed better in hindsight than the Python model! But maybe it's just a "grass is greener" situation.
IshKebab 5y ago
Yeah that's deliberate. They're proposing that Typescript should be valid JavaScript, just with the type hints ignored by JS engines. Seems like a very reasonable proposal to me. It is quite similar to Python's type hint system. Python's is kind of rubbish because there are multiple competing type checkers with different semantics and most people use the crap one (Mypy). I can't see that being a problem here - essentially everyone uses Typescript and it's very good.
- hexane360 5y ago
  >most people use the crap one (Mypy) idk, I wouldn't go this far. Mypy is slow, but it's probably the most correct, and it allows for configurations pyright refuses to. For instance, the maintainers won't add an option to allow variable redefinition/shadowing, seemingly because they don't understand the difference between a variable and a binding (https://github.com/microsoft/pyright/discussions/2441 https://github.com/microsoft/pyright/discussions/2441). As for Pyre, last I checked it had a lot of false positives that Mypy doesn't. Besides all that, some people want to use a checker that isn't exclusively developed by a huge company (Microsoft, Google or Facebook).
  - IshKebab 5y ago
    I dunno I've run into very basic bugs in Mypy and I even went as far as trying to fix them myself. If you had read the code you wouldn't have such a high opinion of it! In contrast Pyright seems to get pretty much everything right, even really subtle things, and if it is really a bug then the guy that maintains it is insanely good at fixing them. Seriously check out how many open/closed issues there are. As for variable redefinition, Python stupidly doesn't prescribe semantics so it's perfectly valid for it to behave like that. Definitely arguable which way it should go and I think for clarity it's much better to use different names anyway. It's not because they don't understand anything. Mypy has way crazier behaviours anyway, e.g. implicit making types optional. Different behaviour depending on the syntax used to add types, etc.
    - hexane360 5y ago
Aldo_MX 5y ago
It is proposing a subset of TS (type annotations) to become a part of JS.

As someone who doesn't really work with neither JS or TS, the proposed JS type system looks superficially very similar to TS. Is this "backporting" TS to JS or is there something else I'm missing?

icholy 5y ago

It's the TS team making the proposal.

idontknowifican 5y ago

this is common in ECMAScript. see coffeescript and arrow functions

jayrhynas 5y ago

As far as I understand it, this is allowing TS types to be valid JS syntax that are just ignored by vanilla JS engines. So it is intentionally identical to TS, it just won’t have any affect on the execution of your code.

Ndymium 5y ago
It's not identical as features that have a difference on the runtime behaviour / code generation such as enums are deliberately omitted. It's intended to be a large subset of TS at first. [0] [0] https://devblogs.microsoft.com/typescript/a-proposal-for-type-syntax-in-javascript/ https://devblogs.microsoft.com/typescript/a-proposal-for-typ...
nerdponx 5y ago
For perspective, this is more or less what Python did. Originally Mypy was supposed to be a Python superset, like TypeScript, but instead its variable annotation syntax was adopted as Python syntax. It has been an interesting journey for Python, with a lot of ups and downs. Type hints, for all their productivity and bug-safety benefits in most cases, still feel like a bolt-on feature that requires developers to change how they write code, and in many cases favors less-performant idioms and/or extra boilerplate compared to un-hinted Python. Whereas TypeScript has a lot more freedom to mess with how things work, because it's a superset that compiles to JavaScript and not actual JavaScript. So it's somewhat surprising to see this proposal for JavaScript, because the TypeScript model always seemed better in hindsight than the Python model! But maybe it's just a "grass is greener" situation.

IshKebab 5y ago

Yeah that's deliberate. They're proposing that Typescript should be valid JavaScript, just with the type hints ignored by JS engines. Seems like a very reasonable proposal to me. It is quite similar to Python's type hint system. Python's is kind of rubbish because there are multiple competing type checkers with different semantics and most people use the crap one (Mypy). I can't see that being a problem here - essentially everyone uses Typescript and it's very good.

hexane360 5y ago
>most people use the crap one (Mypy) idk, I wouldn't go this far. Mypy is slow, but it's probably the most correct, and it allows for configurations pyright refuses to. For instance, the maintainers won't add an option to allow variable redefinition/shadowing, seemingly because they don't understand the difference between a variable and a binding (https://github.com/microsoft/pyright/discussions/2441 https://github.com/microsoft/pyright/discussions/2441). As for Pyre, last I checked it had a lot of false positives that Mypy doesn't. Besides all that, some people want to use a checker that isn't exclusively developed by a huge company (Microsoft, Google or Facebook).
- IshKebab 5y ago
  I dunno I've run into very basic bugs in Mypy and I even went as far as trying to fix them myself. If you had read the code you wouldn't have such a high opinion of it! In contrast Pyright seems to get pretty much everything right, even really subtle things, and if it is really a bug then the guy that maintains it is insanely good at fixing them. Seriously check out how many open/closed issues there are. As for variable redefinition, Python stupidly doesn't prescribe semantics so it's perfectly valid for it to behave like that. Definitely arguable which way it should go and I think for clarity it's much better to use different names anyway. It's not because they don't understand anything. Mypy has way crazier behaviours anyway, e.g. implicit making types optional. Different behaviour depending on the syntax used to add types, etc.
  - hexane360 5y ago

Aldo_MX 5y ago

It is proposing a subset of TS (type annotations) to become a part of JS.