I find string enums useful when I want nominal typing. However, I do think that it is a little confusing when most of the type system is structural, except for string enums. What complicates things further is that any number can be assigned to a number enum without casting, which I understand is so enums can represent bitfields (e.g. so Permissions.Read | Permissions.Write is still of type Permissions instead of number), but I wish numeric enums worked the same as string enums and doing bitwise operations on these enums would return the enum type and not a type-erased `number`.

I mostly agree with the rest of the article’s recommendations, but don’t fully agree with their reasoning.

- Yes, namespaces should be avoided, but not because they generate extra code. Namespaces are not recommended anymore and modules (actual JS modules not TS’ `module`) is the recommended approach now.

- Yep, private fields are better for ensuring a field is truly private.

- I think decorators are fine to use if you’re prepared for your code to potentially break in the future if they’re standardised. Developers use new/unstable features all the time (e.g. stage 0/1 JS proposals via Babel, nightly Rust toolchain). And I don’t believe the lack of standardisation of decorators should be a factor in deciding whether to use a library that requires these.