[seniorsassycat]

Lots of comments seen to have missed that the article isn't recommending against private fields, only the private keyword.

Typescript and JavaScript have a newer brand # to make fields private. The native feature will have runtime benefits while the private keyword creates fields that's are public at runtime.

I still use the private keyword because constructor shorthand doesn't support brands.

    constructor (private field)
    constructor (#field) // error

[ironmagma]

> We'd like to maintain feature parity with JavaScript unless there's a compelling reason not to.

And ladies and gentlemen, the generated code...

var __classPrivateFieldGet = (this && this.__classPrivateFieldGet) || function (receiver, state, kind, f) { if (kind === "a" && !f) throw new TypeError("Private accessor was defined without a getter"); if (typeof state === "function" ? receiver !== state || !f : !state.has(receiver)) throw new TypeError("Cannot read private member from an object whose class did not declare it"); return kind === "m" ? f : kind === "a" ? f.call(receiver) : f ? f.value : state.get(receiver); };

Nothing about this says "native JavaScript" to me. Who cares that a private field is technically public at runtime?

[robpalmer]

You're looking at down-levelled code. Babel and esbuild would equally produce similar code. This is not a TypeScript issue.

If you want "native" JS output, use the tsconfig option... "target": "esnext