Probably depends on your application. You may also see slower construction time if you are creating thousands of objects.
I think which to use depends on whether you believe private methods/variables are helpful or not. Some argue they are unnecessary and it's better to keep everything public. Some like to use a naming convention like an underscore prefix on private items, but declare them publicly.
You could also argue that private items are problematic if you start composing classes from other classes by extending. Then the new methods can't access the private state because they're in a different scope, whereas if they were on the prototype they could find it through `this`.
I've used both approaches but nowadays tend towards the prototype style as that seems to be the more accepted.
There are also other problems such as nesting functions inside other functions inside other functions which is IMO much harder to maintain than a clean flat list of functions defined in the prototype. Don't even get me started on using "self", "that" or "me" instead of the built-in keyword "this".
It could be just me but I cannot understand how that was/is/has been acceptable at all in the first place. Doesn't functions nested 11 levels deep (true story) ring any alarm bells for people?
I think which to use depends on whether you believe private methods/variables are helpful or not. Some argue they are unnecessary and it's better to keep everything public. Some like to use a naming convention like an underscore prefix on private items, but declare them publicly.
You could also argue that private items are problematic if you start composing classes from other classes by extending. Then the new methods can't access the private state because they're in a different scope, whereas if they were on the prototype they could find it through `this`.
I've used both approaches but nowadays tend towards the prototype style as that seems to be the more accepted.