JavaScript Getters/Setters Considered Harmful(labs.transloc.com) |
JavaScript Getters/Setters Considered Harmful(labs.transloc.com) |
Bizarre, but it really emphasizes that where implementation performance is concerned, you have to test, test, test, and test some more. Your intuition about what is fast and what is slow is probably 99% correct. But the other 1% may surprise the whumpus out of you.
Also, I would consider things like this to be highly unstable unless I read a white paper from the implementation team saying that this is by design. If you hurriedly remove all of your dot references and replace them with functions, you may find a point release of the implementation changes everything again.
You have control over your implementation on the server, but users can upgrade their browsers at will without consulting you first :-)
p.s. Did I miss it, or did they only test browsers without looking at server implementation like V8 or Rhino?
"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.
Unless you're doing many millions of get/set operations a second, you will not see any benefit and time is more likely better spent in other areas (selectors, caching, DOM element reduction, etc).
That said, I am very interested why the prototype getter/setter is also bad. I wasn't expecting this to be quite as awful. I would imagine the javascript engine could cache or dynamically create an organic function from a prototype style reference (so there would be huge performance gains over many iterations).
My guess as to why the prototype getters/setters are slow is that the prototype list has to be traversed and this requires a bunch of lookups that are not necessary when dealing with direct properties of the object.