>
`this` is awkward`this` is excellent for maintenance (being able to easily distinguish between instance variables and other things is very valuable), and generally good for performance (more subjective and nuanced involving runtime and memory and consideration of how often you instantiate and how often you use and I won’t provide any citation).
> No private properties
This is where the article falls down; and everything after it is suspect. Because all browsers have supported private class fields since mid-2021. For almost all purposes, this has fairly recently become good enough to depend on. Private class methods is right on the verge, since Safari added it in 15.0 (September 2021) rather than 14.1 (April 2021) like private class fields; I’d say that most purposes can safely depend on this now.
Reference: https://developer.mozilla.org/docs/Web/JavaScript/Reference/...
> No readonly properties
class MyClass {
static get prop() {
return 123;
}
}
MyClass.prop = 456;
In strict mode (e.g. ECMAScript Modules), that last line will throw a TypeError; otherwise, it will silently do nothing. (That’s how non-writable properties work in JavaScript.)
The more-efficient-but-less-friendly-to-some-tooling alternative is placing this after the class:
Object.defineProperty(MyClass, "prop", { value: 123, writable: false });
>
Poor bundler optimizationThere is some legitimacy to this claim, but it’s entirely because all relevant tooling is surprisingly primitive. And most of the places where it seems legitimate, your replacement will suffer from the same issue.
But a lot of it is actually not legitimate: if you only used private fields, they would be optimised, detected as unused, &c. in all these ways.
The example is also a bit dubious in points like the AVERAGE_HEIGHT_FT field on Dog: writing it that way rather than as private or (typically my preference) as a const adjacent to Dog implies it’s supposed to be public (and the naming of these static fields supports this).
And .height and .weight being part of the public interface? I expect that to be a feature, not a bug. .weight is not unused, unless you check the whole code base and find it so. (And the surprisingly-primitive tooling can’t do that whether you use a class or an object.)
> Closures to the rescue! […] Immediately, we see several advantages:
Four are listed. Numbers 1, 2 and 4a are broadly or completely false because you just needed to use private fields. 4b has also been addressed (readonly is just spelled using a getter function).
The only interesting claim is the third:
> 3. We have lesser code bloat thanks to removing this. and Dog. prefixes.
You probably have a smaller bundle size, but it wasn’t bloat: by removing it, you’ve vastly increased memory usage requirements and normally slowed things down, because now instances share almost nothing (only static fields), instead of almost everything (all except for instance data).
—⁂—
All up, I say: try using private properties for a while, and measure various aspects of performance: actual bundle size savings, plain and gzipped; memory usage; and performance if you have any places slow enough to actually measure anything. Then come back and we can consider the topic anew.