I disagree with this. We have a reasonably large Angular application that is only going to get much bigger (hard to define what that means ... big telephony app with tens of thousands of customers). I am the lead and architect.

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)

This is a service I wrote that handles real-time progress (i.e. show an accurate progress bar when downloading files). I think this is clean and logical.