Question

ES5 added a number of methods to Object, which seem to break the semantic consistency of JavaScript.

For instance, prior to this extension, the JavaScript API always revolved around operarting on the object itself;

var arrayLength = [].length;
var firstPosInString = "foo".indexOf("o");

… where as the new Object methods are like;

var obj = { };
Object.defineProperty(obj, {
    value: 'a',
    writable: false
});

… when the following would have been much more conformative:

var obj = { };
obj.defineProperty({
    value: 'a',
    writable: false
});

Can anyone cool my curiosity as to why this is? Is there any code snippets that this would break? Are there any public discussions made by the standards committee as to why they chose this approach?

Answer 1

This is all explained very nicely in “Proposed ECMAScript 3.1 Static Object Functions: Use Cases and Rationale” document (pdf) by Allen Wirfs-Brock himself (editor of ES5 spec, and a member of TC39).

I would suggest to read all of it. It’s pretty short, easily digestible, and gives a nice glimpse of the thought process behind these ES5 additions.

But to quote relevant section (emphasis mine):

A number of alternatives API designs were considered before the
proposed API was chosen. In the course of considering alternatives we
developed a set of informal guidelines that we applied when
considering the alternatives. These guidelines are:

• Cleanly separate the meta and application layers.
• Try to minimize the API surface area (i.e., the number of methods and the complexity of their arguments).
• Focus on usability in naming and parameter design.
• Try to repeatedly apply basic elements of a design.
• If possible, enable programmers or implementations to statically optimize uses of the API.

[…]

Here are some of the alternatives that were considered that lead to
the selected design.

The obvious initial idea, following the example of the already
existing standard method Object.prototype.propertyIsEnumerable, was to
add additional “propertyIs…” query methods on Object.prototype for
the other attributes and a parallel set of attribute changing methods.

[…]

As we considered this approach there were a number of things about it
that we didn’t like and that seemed contrary to the above API design
guidelines:

• It merges rather than separates the meta and application layers. As methods on Object.prototype the methods would be part of the public
  interface of every application object in a program. As such, they need
  to be understood by every developer, not just library designers.

[…]