JavaScript Getters/Setters Considered Slow
"considered harmful" is link bait
"considered harmful" is link bait
This title would have been warranted if there was actually a fundamental problem with JavaScript getter/setters. The idea is fine, the only problem is that presently, browsers are slow to process native getters/setters. That does not mean it will stay like that in the future (in fact, the Firefox caching feature that is mentioned in the article sounds perfect for this use case and should not be that hard to adapt).
Even if ECMAScript getters/setters were to remain slow forever, it is still a gross overstatement to say they should never be used (which is what "harmful" implies). Only in cases where performance is an issue should readability and robustness of code be sacrificed for performance gain.
In Java accessors are almost mandatory if you intend for your object's properties to be publicly available (even the IDEs imply it, by automatically creating them for you). Whereas in languages such as Python and JavaScript, the implementation of this "pattern" makes them optional. You don't have to use accessors if you don't need them right now, since you can always go back and create them later without affecting client libraries.
What the article shows is that, surprisingly, JavaScript's native feature to do this is actually slower than the Java way (what the author called old-fashioned). Is this really a reason to revert to a clumsier pattern because we're optimizing for speed?
Saying that it's "harmful" might get many newbie JavaScript programmers run to start peppering their code with getter and setter Java-style. What happens later when the different scripting engines fix the bottleneck.