In practice, that turns into far too many ways of defining classes in Javascript. There are at least four major approaches, and that was last year.

If you want something that isn't in the language, you build it yourself. If what you build becomes popular, in the fullness of time it gets built into the language as a full feature or as syntactic sugar. That's exactly how we got the class keyword, modules, everything.

But if you choose the wrong thing, one day your choice is obsolete. That is a risk, and it's prudent consider the consequences carefully.

If that troubles you, by all means write your code without any encapsulation, and wait for the language to acquire the feature in a few years. In the mean time, your code base will grow without that kind of encapsulation. Only you can determine whether this is a bad thing or not. YMMV, and all that.

This is a very common problem to ponder, we end up arguing about whether you should be an early adopter, a main streeter, or a laggard.

But really, the post isn't a screed in favour of using private properties, it's a suggestion that making classes out of first-class values in the language gives us the flexibility to build whatever we think we need.

Private properties is a particularly simple example. Traits and mixins are also useful, but would take even more space to articulate. But the general point is still that making new things ("classes") out of the existing materials ("functions and prototypes") is a win in general.

That's part of why I think CoffeeScript isn't going anywhere anytime soon.

Sure thing, but could you show an example? Let's say we want the `rename` function be private, this is what I came up with: https://gist.github.com/ravicious/5412eebf8a1934ec7886

I don't particularly like this solution, because now I can't just write `this.rename()` in other Person functions. That's why I'd rather have a baked-in way to define private properties & functions instead of having to use (in my opinion) this weird syntax and later explain the whys and hows to other developers.

Writing this[rename](...) instead of this.rename(...) is hardly onerous.

Your solution mostly works, but a simpler one takes advantage of combining computed property keys and compact method syntax:

https://gist.github.com/raganwald/18f8c179101cfd93c291

Okay, now this certainly feels better than my example and is much more bulletproof than prefixing function names with `_`, thanks.

You wouldn't be able to simply; the same issues exist as in ES3 in this regard.

(I wrote about them extensively years back here: http://mikegerwitz.com/papers/coope/coope.pdf.)