I have to agree with you, if nothing else because existing debugging tools just aren't very good at dealing with the privacy-through-closures pattern. In many cases, it's essentially impossible to inspect the state of a variable that is made private this way, and it's not clear how you would even design a debugger that gave a reasonable interface for doing so.
Its annoying, but certainly possible to inspect the state of a local variable inside of a closure. Set a breakpoint inside of one of the exported functions, call it, and you have access to all the local variables within the closure.
I do dislike this pattern as I find the code is less structured, harder to debug, and less performant than attaching functions on the prototype. This outweighs the benefits of encapsulation to me.
I have never, ever come across a scenario where assigning to the object instead of the prototype has made any meaningful impact on performance.
The only scenario I can even think of where it would maybe possibly matter would be a tight loop where you are doing little else except just accessing properties.
I can imagine it having an impact on a graphics app where a `Point` class might be instantiated thousands of times, or even if the Backbone.Model constructor were hundreds of lines long to attach all the public methods. It would be weird to me to have to spend a few seconds of thought on a per-object basis to think how I should structure the code based on how often I think it will be instantiated.
But yes, I also have not been bitten by this. Its just something I've read about how the v8 engine works (and makes sense intuitively). I agree you shouldn't base coding style decisions soley on hearing one way is faster, but I think its a minor point and worth noting.
That's true, but it requires that you have a side-effect free exported function for each scope. Adding such a debugger function is probably a smart move if you're using that pattern, but it is not standard practice, and as you said, it's still a hassle.
