TypeScript Features to Avoid

But this doesn't justify removing every codegen feature. Namespaces and enums won't make your code less reasonable, and moreover they're just syntax sugar, they don't change actual JS semantics.

We use enums and private keywords. With the private keywords, all I care about is that it is logically correct. We use private when things are truly private, i.e. they are only called from within the same class and don't need to be made visible to the view template or outside of the class. I honestly don't care what this transpiles down to, the point for us at least is not to make things "truly private" (good luck with that in JavaScript). It's simply to compiler-enforce rules. We also have ESLint to ensure that our private fields are all below the public ones to keep things nice and neat.

I also enforce that we actually make things as public although that isn't needed, and I enforce returning void.

So instead of:

someMethod() {}

I have us use:

public someMethod(): void {}

Just to state what you intend.

I realize "I don't care what this transpiles down to" might really irk some people, but I really don't. In our C# back-end I am much more strict about this stuff, but in JS at the moment given the standardization of the #private fields and the fact I consider them really ugly, I honestly don't care. Just give me a clean code base that enforces we can't reference private fields and methods from our templates.

For enums, I recently wrote a method that does exactly what this article says not to do, use it for GET, POST, and PUT.

What would be a cleaner way to write this? If it has to be refactored into something much "uglier" I don't think I'd prefer it.

    this.downloadService.fileWithProgress(url, RequestType.post, ActionType.download, body)

The described features are not what TypeScript itself wants to be, and I think if it wasn't for backwards compatibility the team would remove some of them.

IIRC namespaces as well as the `import = ` syntax come from a time where ESM wasn't a thing yet but a module system was very much needed. So now that ESM can be used pretty much everywhere namespaces can be avoided and therefore reduce the learning surface of TypeScript.

Enums IMO have no advantage over union types with string literals, e.g. `type Status = 'fulfilled' | 'pending' | 'failed'`. They map way better to JSON and are generally easier to understand, while still benefiting from type safety and typo protection.

Well the private keyword is kind of like namespaces in that it came from a time where the feature was needed/wanted, but the EcmaScript spec was not moving fast enough. So they made their own version of it which is now obsolete.

And for decorators, IIRC the decorator spec has already moved on and TypeScript's implementation is no longer up to date with it. And the spec itself is only stage 2 as mentioned in the article, so I wouldn't recommend using decorators either, you will face breaking changes with them some time in the future.

Furthermore, it is far more likely that you run into trouble when using one of these features with a compiler that is not TSC, e.g. esbuild or Babel. Decorators have never been working all that well with the Babel plugin. Enums are probably fine here.

Do they?

It seems to me that namespaces are more powerful and convenient than JS modules as they enable more structure.

I have only dabbled in TS and am not sure how useful they are there. But I assume they would be similar to PHP/C#/Clojure namespaces on a conceptual level.

The private keyword is obviously preferable to "#" in environments in which you are targeting older ES versions.