4 ms·

IMO the game changer in your scenario is when type annotations are added as a standard JS feature: https://github.com/tc39/proposal-type-annotations https://gi

IMO the game changer in your scenario is when type annotations are added as a standard JS feature: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations At that point (and with ES modules) you'd be able to run your TS code directly without any transpilation necessary. I'd love to remove all the build process junk from my projects and have them run quicker. I've written a few projects as plain ESM JS with JSDoc type annotations and it truly is a joy to bypass build steps. JSDoc type annotations do get annoying as a project grows to a certain size, though.

gbuk2013 2y ago
When I see “stage 1” and “if they stick within a certain reasonably large subset of the language” the cynical old dev in me starts waving a YAGNI sign. :)
- afavour 2y ago
  Honestly as you read through the proposal the immediate impression is "they're just describing TypeScript syntax", which is... fine, I think? But I do feel like it would be a considerably quicker process for Node to just add the ability to parse a TS file than it will be to go through this formal approval process.
  - eyelidlessness 2y ago
    The process is standardizing the ECMAScript language. It would make types (as comments) standard for all JS runtimes, not just Node. I don’t think the community at large wants more non-standard Node stuff, as that’s a frequent point of pain and complaint (see OP article as an example).
wokwokwok 2y ago
> 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, > if they stick within a certain reasonably large subset of the language. <-------- !!!!!!!!!! js + type annotations !== typescript The most recent discussion sums this up with, I think this comment: > EAO: Okay. So the sense I get overall of this whole proposal, that it’s more of a – it’s a solution looking for a problem that it’s trying to solve a year ago when this got accepted for Stage 1, the problem statement that was in fact considered then was only effective we made up or made concrete during the meeting itself, and then – so what it looks like now is that since then, that problem statement has evolved to this current form of unifying or unforking JavaScript and somehow then presenting type annotations as a way of achieving this result. However, I’ve not been able to find any conversation anywhere or description of how in practice this unification is supposed to happen as a consequence of accepting type annotations. No one had a good answer to that, because there isn't one. Anyhow, tldr; this has basically nothing to do with any tangible reason to think ESM is good or useful in anything other than a massively broad, speculative 'maybe in the future' kind of way. ...it is most certainly not any kind of advantage or reason to use ESM for anyone, right now.
- afiori 2y ago
  Being able to copy paste typescript snippets in the browser console is enough of a benefit in my opinion
- WorldMaker 2y ago
  > js + type annotations !== typescript It's very close though. The proposal is well written and covers the cases where existing Typescript code would not parse correctly/work as intended under the proposal. Most of those cases are pre-1.0 Typescript features still in the language for backwards compatibility but generally frowned upon and that you probably already have strict warnings and linter errors preventing you from using today. The big exception is a lot of TS codebases heavily use `enum` and I've still not seen enough suggestions to tighten the linter warning against it. (But there are at least some of us suggesting avoiding TS `enum` today.)
rty32 2y ago
I would argue the benefit is just making everything much simpler. You never need to think about module systems and interoperability -- there is only one module system to deal with. That proposal seems to have stalled, and I doubt it's going anywhere. Here is the thing: people want hard, strict compiler checks that can be enforced at all time, not Python-style type hints. If you want JavaScript but type checked, Typescript is the de-facto standard. Either do "checkJS" or convert the project to Typescript. In fact, the latter is much better in terms of expressiveness.
- tqwhite 2y ago
  It only makes it simpler if you have a new project and can be ESM pure. If you are working with existing code or need non-ESM modules, everything is much more complicated.
an1sotropy 2y ago
Fwiw the github page for that proposal isn't linking to what seems to be the most recent discussion *. I thought type-annotations-as-comments was a no-brainer, but it seems messy. The Sept 2023 discussion shows that it is complicated by the current variety of annotation schemes (TypeScript is not the only one), and the parsing subtleties, which gave rise to unresolved questions about what is the basic motivation. bummer. * https://github.com/tc39/notes/blob/main/meetings/2023-09/september-27.md https://github.com/tc39/notes/blob/main/meetings/2023-09/sep...

gbuk2013 2y ago

When I see “stage 1” and “if they stick within a certain reasonably large subset of the language” the cynical old dev in me starts waving a YAGNI sign. :)

afavour 2y ago
Honestly as you read through the proposal the immediate impression is "they're just describing TypeScript syntax", which is... fine, I think? But I do feel like it would be a considerably quicker process for Node to just add the ability to parse a TS file than it will be to go through this formal approval process.
- eyelidlessness 2y ago
  The process is standardizing the ECMAScript language. It would make types (as comments) standard for all JS runtimes, not just Node. I don’t think the community at large wants more non-standard Node stuff, as that’s a frequent point of pain and complaint (see OP article as an example).

wokwokwok 2y ago

> 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, > if they stick within a certain reasonably large subset of the language. <-------- !!!!!!!!!! js + type annotations !== typescript The most recent discussion sums this up with, I think this comment: > EAO: Okay. So the sense I get overall of this whole proposal, that it’s more of a – it’s a solution looking for a problem that it’s trying to solve a year ago when this got accepted for Stage 1, the problem statement that was in fact considered then was only effective we made up or made concrete during the meeting itself, and then – so what it looks like now is that since then, that problem statement has evolved to this current form of unifying or unforking JavaScript and somehow then presenting type annotations as a way of achieving this result. However, I’ve not been able to find any conversation anywhere or description of how in practice this unification is supposed to happen as a consequence of accepting type annotations. No one had a good answer to that, because there isn't one. Anyhow, tldr; this has basically nothing to do with any tangible reason to think ESM is good or useful in anything other than a massively broad, speculative 'maybe in the future' kind of way. ...it is most certainly not any kind of advantage or reason to use ESM for anyone, right now.

afiori 2y ago
Being able to copy paste typescript snippets in the browser console is enough of a benefit in my opinion
WorldMaker 2y ago
> js + type annotations !== typescript It's very close though. The proposal is well written and covers the cases where existing Typescript code would not parse correctly/work as intended under the proposal. Most of those cases are pre-1.0 Typescript features still in the language for backwards compatibility but generally frowned upon and that you probably already have strict warnings and linter errors preventing you from using today. The big exception is a lot of TS codebases heavily use `enum` and I've still not seen enough suggestions to tighten the linter warning against it. (But there are at least some of us suggesting avoiding TS `enum` today.)

rty32 2y ago

I would argue the benefit is just making everything much simpler. You never need to think about module systems and interoperability -- there is only one module system to deal with. That proposal seems to have stalled, and I doubt it's going anywhere. Here is the thing: people want hard, strict compiler checks that can be enforced at all time, not Python-style type hints. If you want JavaScript but type checked, Typescript is the de-facto standard. Either do "checkJS" or convert the project to Typescript. In fact, the latter is much better in terms of expressiveness.

tqwhite 2y ago
It only makes it simpler if you have a new project and can be ESM pure. If you are working with existing code or need non-ESM modules, everything is much more complicated.

an1sotropy 2y ago

Fwiw the github page for that proposal isn't linking to what seems to be the most recent discussion *. I thought type-annotations-as-comments was a no-brainer, but it seems messy. The Sept 2023 discussion shows that it is complicated by the current variety of annotation schemes (TypeScript is not the only one), and the parsing subtleties, which gave rise to unresolved questions about what is the basic motivation. bummer. * https://github.com/tc39/notes/blob/main/meetings/2023-09/september-27.md https://github.com/tc39/notes/blob/main/meetings/2023-09/sep...