Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript Getters/Setters Considered Harmful

labs.transloc.com

Post reply on HN
Print view View original

1–10 of 14 posts

Re: JavaScript Getters/Setters Considered Harmful

#2

Post by raganwald »

Firefox 4 would rather you write getters and setters the old fashioned way for every single object you create than reference objects’ member variables directly via dot-notation.

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?

Re: JavaScript Getters/Setters Considered Harmful

#4

Post by jasonfeinstein »

raganwald wrote: post #2

Firefox 4 would rather you write getters and setters the old fashioned way for every single object you create than reference objects’ member variables directly via dot-notation. 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…

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.

Re: JavaScript Getters/Setters Considered Harmful

#7

Post by micheljansen »

seles wrote: post #3

JavaScript Getters/Setters Considered Slow "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.

Re: JavaScript Getters/Setters Considered Harmful

#8

Post by iamleppert »

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).

Re: JavaScript Getters/Setters Considered Harmful

#9

Post by IgorPartola »

iamleppert wrote: post #8

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…

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.

Post reply on HN