JavaScript Getters/Setters Considered Harmful(labs.transloc.com)
labs.transloc.com
JavaScript Getters/Setters Considered Harmful
http://labs.transloc.com/?p=21
5 comments
You're correct, we didn't test on server implementations like V8 and Rhino... You make a good point though, it would be interesting to test the results in those environments.
JavaScript Getters/Setters Considered Slow
"considered harmful" is link bait
"considered harmful" is link bait
You read my mind. I am growing tired of this "considered harmful" hype.
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.
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.
"Considered harmful" considered harmful?
In this context it is. There may be some serious implications when saying that x or y pattern in language z is considered harmful.
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.
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.
No I don't think so. Considered harmful should mean a serious reason why the aforementioned is a bad thing. "Considered harmful" is just being grossly misapplied as unmerited linkbait, but it's still quite beneficial when occasion calls for it.
You can read it here: http://meyerweb.com/eric/comment/chech.html
[deleted]
This is a prime example of pre-mature optimization. This, but itself, although interesting theoretically provides no practical information and should not dictate most application use or non-use of getters and setters.
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).
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).
It is true that you won't see much benefit when doing only a few operations, but we were interested because we do perform many object accesses/writes a second.
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.
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.
Someone reported this to Bugzilla back in January. https://bugzilla.mozilla.org/show_bug.cgi?id=626021
They may be slow today, but they may get a lot faster tomorrow. Also I would be interested to see this in action in a real world app, rather than just 'let's see how many get/set we can perform'.
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?