Adding new methods does seem clearer than overloading existing ones.  Is there any reason to overload here?  Are there other methods in the web platform that are overloaded like this?  One advantage of not overloading is it allows easier feature-testing -- you don't have to try calling it and see if it throws.

FormData.append(), XMLHttpRequest.send(). Are there methods not overloaded like this?

FormData and XHR methods aren't performance-vise hot.

And even more importantly, is there any reason why append/replaceChild etc
need to be overloaded, and new methods can't be created?

In Opera this would not be a performance hit. WebKit representatives seemed okay with it as well.

Having additional methods is not at all JavaScript-like.

> In Opera this would not be a performance hit.

On this testcase:      

   (function() {
      var d = document.createElement("div");
      var d2 = document.createElement("div");
      var start = new Date;
      for (var i = 0; i < 1000000; ++i) d2.appendChild(d);
      alert(new Date - start);
    })()

Opera is about 4x slower than Gecko on my machine.  Overloading wouldn't be a performance hit for us either if we were that slow.

And we expect this to become much faster, so the relative cost of the overload stuff will be even higher.

I'm not really a benchmark expert but how is that testing appendChild() functionality? After the first time appendChild() could effectively be a no-op in that test if the implementation had some optimization check for that.

(And WebKit appears a lot faster than Gecko on that test.)

> After the first time appendChild() could effectively be a no-op
> in that test if the implementation had some optimization check for that.

Sure.  Here's a version of the test test that doesn't have that problem:

    (function() {
      var d = document.createElement("div");
      var ds = [ document.createElement("div"), document.createElement("div") ];
      var start = new Date;
      for (var i = 0; i < 1000000; ++i) d.appendChild(ds[i % 2]);
      alert(new Date - start);
    })()

or

    (function() {
      var d = document.createElement("div");
      d.appendChild(document.createElement("div"));
      d.appendChild(document.createElement("div"));
      var start = new Date;
      for (var i = 0; i < 1000000; ++i) d.appendChild(d.firstChild);
      alert(new Date - start);
    })()

which amusingly enough are much slower in WebKit; there is no real difference in Gecko or Presto.

> (And WebKit appears a lot faster than Gecko on that test.)

Sure.  Is I said, we plan to make it a lot faster in Gecko in any case.  I was simply commenting on your claim that there is no performance hit in Presto.

We should (if we don't yet) have a constructor for Text.  Then you can do

  e.appendChild(new Text("abc"));

which ain't so bad.

I reverted this change for now. I do not think adding Text node specific methods is the way to go here.

Adding a constructor for Text makes sense, but I'm not sure how it should work for Element.

The change in comment 0 was reverted. If anything else needs to happen please file a new bug.