[MrJohz]

This is true but these are also old features, and the TS team have stated that they will not add any more features like those, and to a certain extent regret adding them initially (particularly decorators, which iirc were added because the Angular framework wanted to use them). You can also see that these features aren't really being updated to match recent Typescript developments (parameter properties can't do true private properties, const enums don't work with isolated modules, etc).

I don't think those features are ever going to go away, because they've been around for so long and are so widely used. But I generally use erasableSyntaxOnly in new projects, because I find it's useful when my typescript source matches the generated Javascript code as much as possible.

[lifthrasiir]

> I find it's useful when my typescript source matches the generated Javascript code as much as possible.

Is this that worth? In the past I was able to read past async/await desugaring generated by TypeScript, and there are several useful non-JS syntaxes that are much easier to read than that (e.g. enums). Of course it would be great if ECMAScript eventually adopts them, but that doesn't seem like a strict requirement for me.

[MrJohz]

Async/await was implemented according to the ECMAScript spec - for a while it existed in typescript but not yet in browser runtimes, but it was fully specced out as a javascript feature rather than a typescript one. And when configured to emit ESNext JS files, typescript would emit the async/await calls verbatim, rather than transpiling them. After all, at that time async/await was valid, spec-compliant javascript (that hadn't yet been implemented in all browsers).

This is true for a number of features, most recently explicit resource management, that required syntax that was part of ECMAScript, supported in typescript, but not yet implemented in mainstream runtimes. In these cases, typescript is doing the same thing as Babel and converting new JS to old.

The syntaxes under discussion are ones that were implemented in typescript without an ECMAScript proposal, and typically are completely non-standard, and may well never be implemented in browsers, or if they are, be implemented completely differently. For example, the original decorators implementation was completely different to the one now being proposed, and enums could well end up going in the same direction.

This confusion about what is typescript, and what is javascript is exactly why I think avoiding the typescript-only features is a good idea. I've seen a lot of people make this mistake (and it's a very reasonable mistake to make!) and I think it's easier to explain what typescript is actually doing if you make it clear that it's only doing type-level stuff.

[primering]

> because I find it's useful

How useful is it exactly that you accept to not use DX improving syntax like constructor properties, enums, etc? To me, someone who uses these features _a lot_, this would be a terrible trade. Seems more like people push this out of ideology and because TS is never going to be part of node itself (since its implementation is just way too slow)

[MrJohz]

It's useful as a tool for communication and simplification. Ignoring those features, typescript is just javascript with type annotations, which makes understanding how something works easier. I've worked with a number of developers who have been confused about what's a typescript feature, and what's a javascript feature, because this boundary feels blurred (particularly when working with modern ESNext syntax that might not be implemented in browsers but is understood by typescript). Being able to say clearly: everything after a colon (and some other places) is typescript, everything else is javascript is a great way of helping people understand what's going on.

In terms of the tradeoff, I rarely, if ever, use those features in the first place. For enums, I'd rather just use string literal types, which are slightly easier to write and compose, potentially assigning them to variable names if I think that's clearer for a given use-case. For constructor properties, they don't work for private properties which is the most common property I'm writing, so I don't really see the value.

The two other features that are disabled are namespaces and modules that contain code, and `import ... =`, both of which have clearer JS alternatives.

FWIW, you can enable those features in node, although that's still behind an experimental flag. It's marginally slower (because the translation is slightly more complex than replacing types with whitespace) and it requires sourcemaps under the hood, but if you really want those features you can have them. Or you can use an alternate runtime that supports them out of the box (Deno, Bun). But even then, I think they make teaching and understanding the language more complicated and I wouldn't personally recommend them. (Assuming someone might listen to the personal recommendation of a random HN comment!)

[epolanski]

Enums are crap and unsafe use union types.