[jmisavage]

The only problem is you run the risk of implementing a still developing standard that might be vastly different than the finalize version. You then have code and programmers trained in doing something the old "wrong" way.

This happened in TypeScript when they added support for an early version of decorators and now the TC39 version (which is still only Stage 3) is just different enough to cause issues.

[evilduck]

They have been labeled experimental the entire time and off by default. That specific TC39 proposal is also approaching a decade of feet dragging and has been exceptionally slow to make progress. In Typescript if you aren’t opting into using decorators through a library that forces you to use them, they’re entirely avoidable (and some would argue, decorators make code worse and this failure to launch is a good thing).

I think the Typescript creators themselves learned a lesson with decorators and enums which is why we haven’t seen other JS language proposals get added until they’re actually in the process of being adopted (e.g. matchers).

[tentacleuno]

> That specific TC39 proposal is also approaching a decade of feet dragging and has been exceptionally slow to make progress.

So... like the pipeline operator? Pretty much given up on that being included now. They can't make up their minds over two competing syntaxes (and, FWIU, it has taken them years to decide).

[maxloh]

Why did you mention enum? Is it designed badly?

[tylerchurch]

I think the main complaints are:

1. Enums are one of the few TypeScript features that isn't a type annotation that can simply be erased. Enums emit code and don't have an equivalent JS feature.

2. Const enums are unsupported by some bundlers/build tools, and so people try to use them and then got burned at build time.

3. The use cases covered by enums are often better served by union types.

None of the above is necessarily fatal for the feature. Certainly people used to enums in other languages still like them. But all 3 combined and the general recommendation these days ends up being just don't use them.

[AprilArcus]

FWIW, Babel has supported const enums for a few years now (since 7.15)

https://babeljs.io/blog/2021/07/26/7.15.0

[rictic]

Yeah, tools can add support for them, but they're fundamentally a whole-program-optimization in a build chain that's 99.9% file-by-file.

Supporting const enums will, by necessity, greatly reduce the maximum performance that toolchain can achieve, because you have to evaluate the entire project to tell whether `Foo.BAR` should be left alone or replaced with a constant defined elsewhere. And in the worst case of an ambient declaration, "elsewhere" could be any file in the project.

[moogly]

You mean the feature that was gated behind an opt-in switch called `experimentalDecorators' and documented from the start with "Experimental support for decorators is a feature that is subject to change in a future release"?

This was only really added to appease Google and Angular 2.0.

[jmisavage]

Yeah Microsoft didn’t want AtScript to steal the little thunder TypeScript had at the time, but we’re still left with that one experimental feature all over Angular codebases.

[leptons]

People who chase "new, shiny" often get rewarded with stupid prizes.