Going by this Analyzing JavaScript Class Patterns Performance and my own tests, it seems that using public instance vars gives much better performance than private ones. For static vars whether private or public doesn’t seem to make a big difference - public seems a little faster when creating lots of instances of an object, otherwise private seems a little faster, but not much in it either way.
The big performance gain for public instance vars seems to be due to use of prototype instead of having to use a priviliged method as needed for private instance vars.
It seems to me that private instance vars should be avoided (unless you only have one instance), and public properties should be used instead (maybe prefixed by an underscore to indicate they are not meant to actually be public).
There are aspects of premature optimization (is evil) occurring here. In many cases, even if JavaScript was executing at infinite speed, taking no time at all, the performance benefits would still be negligible when compared with techniques to improve performance elsewhere, such as in minimising http requests or adjusting how and when you access the DOM.
I believe that understandability of the code takes precedence over raw execution speed, and that such performance numbers are a curiosity more than anything else, until performance profile metrics of your actual code demonstrates the need for such improvements.
I’d both agree and disagree with that. I agree that optimisations such as this are unlikely to make a noticeable performance difference in real life usage. However, I also think it is still useful to learn the most efficient ways to do things. Just because the way you write code at the moment isn’t currently causing you any issues doesn’t mean you shouldn’t try to learn better coding practices.
In terms of understandability of the code, I don’t see much difference between public and private instance vars. It could actually be argued that public instance vars are easier to understand, since you can easily tell they are tied to the current instance. (And you can indicate they are not meant to be public by prefixing with an underscore). Whereas with a private instance var, you need to look back up the stack to identify the scoping where they are defined.
That is a common convention, but can it be relied upon that other’s code will be following it?
■■■■ I’d be happy to see security, documentation and unit testing become more common practice let alone adherence to an established naming convention
Have you added in the maintenance cost in making that decision. The extra microsecond saved may be offset by a month of debugging due to a variable name clash.
I would have thought that you’re slightly more likely to have a variable name clash when using private instance vars as opposed to public properties? Of course, it depends on how your code is used.
If your code is a snippet or even a script that a user decided to concatenate with other (unencapsulated) scripts, then you could end up with a variable name clash when using private instance vars.
If your object is designed to be extensible and the person extending it doesn’t check the existing properties, then you could get a property name clash when using public instance properties.
Private properties in JavaScript are all encapsulated within the function they are private to so you can never have private properties that are not encapsulated. If they are not encapsulated then they are public.
I was wrong about the possibility of variable name clashes, it is not possible. I was thinking that if a variable name was previously assigned in the global scope, then the private var would actually be referencing that var, instead of being private. But that is not correct, the private var stays scoped to the object instance.