Hacker News Reader

Comment by VeejayRampay | Hacker News Reader

Good thing that this is all coming to Javascript. But I can't help but think we're in bizarro land when the main language of the most ubiquitous medium of the 21st century is only getting all that rather basic stuff (at least by all the other languages' standards) in 2015 or something...

View on HN

Everything there besides Proxies and Symbols is already in common browsers, and I can't say I'm familiar with Proxies and Symbols in other languages (not to say some other languages necessarily don't have them, but I don't think most users consider them basic or encounter them often).

Proxies are like __get/__call in PHP, method_missing in Ruby and the similar magic methods Python has.

Symbols are sort of JavaScript's answer to private members. Closest to __ for members in Python.

I'm a bit puzzled what symbols are. If you want a unique thing that !== anything except itself, make an empty object. It seems to me: var foo = Symbol("foo") ought to let you dereference via bar.foo vs. bar[foo] (the latter shouldn't even work!) or it's not what it seems it wants to be.

Symbol has other traits beyond just not being unique. Properties added via symbols are not iterated over in a for in and do not show up in calls to Object. getOwnPropertyNames()

The point of it is you can implement private properties, as I understand it:

    function MyClass() {
        var mysymbol = new Symbol("foo");
        this[mysymbol] = 3;
    }

    var bar = new MyClass();
    bar.foo // this won't work

What a convoluted mechanism!

What a convoluted mechanism! But where do you keep your reference to the symbol to keep it private? Anywhere you keep it (e.g. in a closure somewhere) that's private doesn't need symbols, so what problem does this solve?

And surely in your private context, bar.foo should still work.

I think the slow browser updates that existed prior to Chrome might have contributed to a lull in developing the language. Some of these features can't be fixed for old browsers with a polyfill, but now that updates are happening quicker and there's a lot of excitement around the language I hope we see more of these.

I don't think there were ever any "slow updates" to Javascript, except maybe in the period of IE5/6 dominance to Firefox 1.0. In the Browser Wars, Microsoft and Netscape competed to add features as fast as possible. Firefox still has many additional features in its JS engine that aren't in ECMAScript (for each, coroutines).

I'm more concerned about adding features without fully considering the consequences. When you add a feature to Javascript, it's there forever. Rushed feature dumps are how we end up with things like the Web Audio API.

True, the early period had a furious pace of updates. I guess I was referring to the era of ES6, that lasted a long time. I think Microsoft at one point actually said that IE6 was the final browser and they wouldn't release a new version. IE6 was amazing when it first came out, but it became a blight in the end that hurt more than it helped.

That's why some features have been postponed from ES6 to ES7

Reply on news.ycombinator.com