Symbols in ES6: Worth the Weight?

After initially appreciating the "sugar" of classes in ES6, and the accompanying reduction of boilerplate, it hit me that it is problematic to get "private" members with this construct.

Well, it seems that you'll need to wait until ES7 (or beyond) for "private", and you are left to your own devices - modules, closures, or weakmaps (new in ES6) - which to me defeats the purpose of using the new class syntax to begin with.

The Main Reason Symbols were Introduced... Didn't Work

ES6 started out with the intention of using the concept of "Symbol" to get the private member stuff. And it turned out not to work, and so "private" was deferred.

Enabling private properties ... was indeed the original motivation for introducing symbols into JavaScript. Unfortunately, however, they ended up being severely downgraded, and not private after all.

They are now known as unique symbols, and their only use is to avoid name clashes between properties....Whether that is strong enough a motivation to add symbols to the language is debatable.

A Rossberg in this stackoverflow answer (Mar 2014)

And here's more info on symbols and private from a couple of months ago:

Ultimately it was decided that Symbol is just a symbol and that "private" things will be dealt with orthogonally (and at a later date).

R. Waldron, as part of this response to a proposal about a private symbol (Dec 2014)

So What Good are Symbols?

A. Rauschmayer has a long and detailed post on what symbols are and how they work, and some ways to use them. The main use seems to be when you need a object property key, but want to be 100% sure it won't conflict with an existing property.

This seems like a rarified use case (for me, at least), but Rauschmayer brings up two main examples (see section 3 of Rauschmayer's note):

• If several parties contribute internal properties to the same object, via mixins
• To keep meta-level properties from clashing with base-level properties

Have these been enough of a problem for people to justify adding Symbols? I really don't know. Rauschmayer has much more info on other potential uses, and I guess it's not simply post-facto justification.

Performance? 4esn08k has some interesting symbol tests on jsperf that seem to indicate that, at the moment at least, access via symbols is very very slow (I used 40.0.2214.111 on OS X 10.10.1).

And Brendan Eich's Take?

What does Brendan Eich's think? I haven't found recent info, but here's a quote from a couple of years ago (while the use of them for private was still in the picture then, I think some of this is still applicable in spirit):

Symbols (private or public, don't forget the latter) are crucial to ES6 and not going away :-|.

Besides the property access and GC costs of WeakMaps (which are probably fine, but at least inevitable, when you really do need a WeakMap), symbols allow coordination between friendly objects by name, without exposing a map full of names, plural....

Different tools in your belt are a good thing. We don't fault the screwdriver for being a poor hammer, or vice versa!

Brendan Eich, in this ES discussion (Jan 2013)

So, unless they are voted out in the vote by the ECMA General Assembly June 18, 2015, a new "screwdriver" in the javascript toobelt - Symbols - will become part of ES6 come August 14, 2015.

Maybe I'll run up against one of the use cases some day.