Rule about __proto__

[Alexsey]

For now Standard has a rule that prohibit __proto__ usage as deprecated. I agree that it could be considered as deprecated in the past, but now, when __proto__ is a part of a ES2016 standatd I don't see any reasons why it should be

[dougwilson]

I wouldn't consider anything in Annex B as being "standard", more of a "we really hate to add this stuff, but we're forced to.. but don't use it". See the opening paragraphs of the annex:

This annex describes various legacy features and other characteristics of web browser based ECMAScript implementations. All of the language features and behaviours specified in this annex have one or more undesirable characteristics and in the absence of legacy usage would be removed from this specification.

[dougwilson]

And Annex B continues to say this:

These features are not considered part of the core ECMAScript language. Programmers should not use or assume the existence of these features and behaviours when writing new ECMAScript code. ECMAScript implementations are discouraged from implementing these features unless the implementation is part of a web browser or is required to run the same legacy ECMAScript code that web browsers encounter.

[Alexsey]

Agree, we should not use it. It's pity... like getter/setter is somehow worser then methods

[LinusU]

It's pity... like getter/setter is somehow worser then methods

getters and setters has nothing do with __proto__? They are perfectly supported by standard and ES2016

const obj = {
  get test () {
    return 'Hello'
  }
}

console.log(obj.test) // Hello

[Alexsey]

I mean that __proto__ is a pair of getter and setter that acts common way as methods Object.getProptotypeOf and Object.setPrototypeOf. And I don't see why one way is better than other

[LinusU]

__proto__ feels very hackish just from the name, it implies that you shouldn't mess with it. Also, it was never standardised the way that the official functions where...

[Alexsey]

The thing is definitely not in standardization. Because now it is standardized but any way in deprecation zone. I agree that the name is not good. But there is no other reasons I can see

[feross]

I usually don't need to use __proto__ except in rare cases, like when IE8 needs to be supported. For example in buffer, which supports IE8, we just disable that rule like this.

See the compatibility table on this page and you can see that we hopefully shouldn't need to use __proto__ for much longer. :)

[Alexsey]

I have start to move this discussion from standard to why spec writers chose Object.getProptotypeOf and Object.setPrototypeOf to be common way to work with prototype but not __propto__ and this is definitely a flood, sorry. Initial question already got it answer, thank you all for you replies!