JavaScript DOM remove node method design, why involve parent node? (2026)
dom remove node design
DOM design seems idiotic.
if you want to remove a child ‹x›, you have this function ‹x_parent›.removeChild(‹x›)
which requires to get the parent. why didn't they have
‹x›.remove()
ai answer
They did add x.remove(). The old API is the part that feels idiotic.
x.remove(); // modern x.parentNode.removeChild(x); // 1998-era DOM
Element.remove() / ChildNode.remove() has been in the DOM spec since around 2011 and in every current browser since about 2015. If there is no parent, it is a no-op. removeChild still exists because it is older, returns the detached node, and throws if you pass the wrong parent.
Why the original design looked like that
DOM Level 1 treated the tree as a list of children owned by the parent. Mutation was defined as operations on the parent:
appendChildinsertBeforereplaceChildremoveChild
Removal is not “destroy this object.” It is “break the parent→child edge.” The parent holds the child list, so the spec made the parent the thing you call. That also gives a cheap sanity check: parent.removeChild(x) throws NotFoundError if x is not actually a child of that parent. x.remove() cannot do that check in the same way.
There is a real difference besides spelling:
parent.removeChild(x) |
x.remove() |
|
|---|---|---|
| Needs parent | yes | no |
| Returns | the node x (still usable) |
undefined |
| No parent | throws if you call it on the wrong parent | does nothing |
| Old IE | works | no |
The “you already have the parent” style also matches how engines actually splice the child list. A self-remove() is just a wrapper that looks up parentNode and does the same splice.
So the complaint is fair for the 90s API. The platform eventually agreed with you; people kept writing parentNode.removeChild out of habit, IE inertia, and copy-paste from old Stack Overflow. Today x.remove() is the normal call unless you specifically want the returned node or the “must be my child” exception.