Z

39

1374

How would I go about removing all of the child elements of a DOM node in JavaScript?

Say I have the following (ugly) HTML:

<p id="foo">
    <span>hello</span>
    <div>world</div>
</p>

And I grab the node I want like so:

var myNode = document.getElementById("foo");

How could I remove the children of foo so that just <p id="foo"></p> is left?

Could I just do:

myNode.childNodes = new Array();

or should I be using some combination of removeElement?

I'd like the answer to be straight up DOM; though extra points if you also provide an answer in jQuery along with the DOM-only answer.

Zymogenic answered 17/10, 2010 at 20:51 Comment(0)

L

546

In 2022+, use the `replaceChildren()` API!

Replacing all children can now be done with the (cross-browser supported) replaceChildren API:

container.replaceChildren(...arrayOfNewChildren);

This will do both:

remove all existing children, and
append all of the given new children, in one operation.

You can also use this same API to just remove existing children, without replacing them:

container.replaceChildren();

This is fully supported in Chrome/Edge 86+, Firefox 78+, and Safari 14+. It is fully specified behavior. This is likely to be faster than any other proposed method here, since the removal of old children and addition of new children is done without requiring innerHTML, and in one step instead of multiple.

Lamia answered 22/12, 2020 at 18:17 Comment(12)

The MDN data has now been corrected, and shows full cross-browser support: caniuse.com/?search=replacechildren – Lamia 29/4, 2021 at 16:57

This is significantly slower than the other methods mentioned here, at least for me. – Spillman 4/7, 2021 at 14:3

Would you mind linking to your test, and the details like which browser/platform you used? That would surprise me greatly, at least on Chrome. – Lamia 16/7, 2021 at 2:5

Don't do this. It may seem nice but will trigger a separate MutationRecord for each removed child (when using a MutationObserver on the element). Setting textContent is much faster for hundreds of children. (I mean you can do this, but always set textContent to remove many existing children first.) – Intermix 25/6, 2022 at 10:52

@ygoe, that should not be the case. Can you show an example? Here is my example code: jsbin.com/xopapef, which uses a target element containing 10,000 children. At least in Chrome, it shows exactly one mutation observer call in both cases. Do you see something different? If so, please clarify what browser and platform you're using. (My demo, at least for me, also shows that replaceChildren() is at least as fast, and is typically faster, than textContent.) – Lamia 27/6, 2022 at 16:40

I ran the site I linked above on a Mac, on Chrome, Firefox, and Safari, and all three agree: only one mutation observer call. And replaceChildren() is very slightly faster on all three. Let me know if you see something different. – Lamia 27/6, 2022 at 17:4

Well, in a simple demo case, it looks good indeed. But in my application it results in that behaviour. Setting textContent = "" before calling replaceChildren(...newChildren) resolves the issue completely. Since mutation observer events are asynchronous, I cannot determine what the causing code is. But I'm happy with my working code. Others might need to inspect their own situation close enough to decide themselves. – Intermix 29/6, 2022 at 12:41

Ok. If you can post a minimized version of your problem code as a bug (crbug.com/new), I could take a closer look. – Lamia 30/6, 2022 at 13:42

Changing this to the accepted answer, since it's now the suggested modern approach :) – Zymogenic 15/10, 2022 at 23:55

It is slowest variant even tested. At least what I got in Firefox. – Kalgan 31/3, 2023 at 15:21

Interesting! On the test site I linked above? Or something else? – Lamia 1/4, 2023 at 16:58

This stopped working for some reason. – Octillion 25/6, 2023 at 21:40

L

2312

Option 1 A: Clearing `innerHTML`.

This approach is simple, but might not be suitable for high-performance applications because it invokes the browser's HTML parser (though browsers may optimize for the case where the value is an empty string).

doFoo.onclick = () => {
  const myNode = document.getElementById("foo");
  myNode.innerHTML = '';
}

<div id='foo' style="height: 100px; width: 100px; border: 1px solid black;">
  <span>Hello</span>
</div>
<button id='doFoo'>Remove via innerHTML</button>

Option 1 B: Clearing `textContent`

As above, but use .textContent. According to MDN this will be faster than innerHTML as browsers won't invoke their HTML parsers and will instead immediately replace all children of the element with a single #text node.

doFoo.onclick = () => {
  const myNode = document.getElementById("foo");
  myNode.textContent = '';
}

<div id='foo' style="height: 100px; width: 100px; border: 1px solid black;">
  <span>Hello</span>
</div>
<button id='doFoo'>Remove via textContent</button>

Option 2 A: Looping to remove every `lastChild`:

An earlier edit to this answer used firstChild, but this is updated to use lastChild as in computer-science, in general, it's significantly faster to remove the last element of a collection than it is to remove the first element (depending on how the collection is implemented).
The loop continues to check for firstChild just in case it's faster to check for firstChild than lastChild (e.g. if the element list is implemented as a directed linked-list by the UA).

doFoo.onclick = () => {
  const myNode = document.getElementById("foo");
  while (myNode.firstChild) {
    myNode.removeChild(myNode.lastChild);
  }
}

<div id='foo' style="height: 100px; width: 100px; border: 1px solid black;">
  <span>Hello</span>
</div>
<button id='doFoo'>Remove via lastChild-loop</button>

Option 2 B: Looping to remove every `lastElementChild`:

This approach preserves all non-Element (namely #text nodes and  ) children of the parent (but not their descendants) - and this may be desirable in your application (e.g. some templating systems that use inline HTML comments to store template instructions).
This approach wasn't used until recent years as Internet Explorer only added support for lastElementChild in IE9.

doFoo.onclick = () => {
  const myNode = document.getElementById("foo");
  while (myNode.lastElementChild) {
    myNode.removeChild(myNode.lastElementChild);
  }
}

<div id='foo' style="height: 100px; width: 100px; border: 1px solid black;">
  <!-- This comment won't be removed -->
  <span>Hello <!-- This comment WILL be removed --></span>
  <!-- But this one won't. -->
</div>
<button id='doFoo'>Remove via lastElementChild-loop</button>

Bonus: `Element.clearChildren` monkey-patch:

We can add a new method-property to the Element prototype in JavaScript to simplify invoking it to just el.clearChildren() (where el is any HTML element object).
(Strictly speaking this is a monkey-patch, not a polyfill, as this is not a standard DOM feature or missing feature. Note that monkey-patching is rightfully discouraged in many situations.)

if( typeof Element.prototype.clearChildren === 'undefined' ) {
    Object.defineProperty(Element.prototype, 'clearChildren', {
      configurable: true,
      enumerable: false,
      value: function() {
        while(this.firstChild) this.removeChild(this.lastChild);
      }
    });
}

<div id='foo' style="height: 100px; width: 100px; border: 1px solid black;">
  <span>Hello <!-- This comment WILL be removed --></span>
</div>
<button onclick="this.previousElementSibling.clearChildren()">Remove via monkey-patch</button>

Lazy answered 17/10, 2010 at 20:52 Comment(27)

From jQuery these two issues might be considered: This method removes not only child (and other descendant) elements, but also any text within the set of matched elements. This is because, according to the DOM specification, any string of text within an element is considered a child node of that element. AND "To avoid memory leaks, jQuery removes other constructs such as data and event handlers from the child elements before removing the elements themselves." – Laudanum 21/11, 2011 at 5:26

@micha I think your test is not right. I have written my one on jsfidle (jsfiddle.net/6K6mv/5) and here is the result. WHILE: 14ms; INNERHTML: 7ms; TEXTCONTENT: 7ms – Bergeman 2/2, 2013 at 19:1

@m93a: running your fiddle multiple times gives me results all over the place between 6ms to 11ms. This is basically telling me nothing. The results are closer together than the variance in ms between each testrun for the same test. For the record: It's not MY script, its jsperf.com. Look at this for a better understanding of the test results: https://mcmap.net/q/46353/-explain-this-jsperf-com-result and https://mcmap.net/q/46352/-how-does-jsperf-determine-which-of-the-code-snippets-is-fastest/… – Muddle 2/2, 2013 at 20:51

@Muddle Yes, I know what the test results mean, but it seems strange. It shows me thas innerHTML is 98% - 99% slower. And my tests show the opposite. But this is not a chat, I'm leaving discussion. – Bergeman 4/2, 2013 at 15:32

innerHTML only works if you are only dealing with HTML. If there is e.g. SVG inside only Element removal will work – Petula 27/3, 2013 at 14:45

NEVER NEVER NEVER use innerHTML = ''. Don't. The problem is that the items look like they're removed but internally, nodes persist and slow things down. You have to remove all the individual nodes for a reason. Tested in both Google Chrome and IE. Please consider removing the innerHTML "solution" since it's wrong. – Topazolite 21/9, 2013 at 15:40

@Muddle jsperf.com/innerhtml-vs-removechild/151 using .remove() is even faster. – Bolan 11/2, 2014 at 12:33

@joeytje50 Nice one! Unfortunately it's DOM4 and not available everywhere. I'm sticking with .removeChild() for better compatibility. Besides, the gain of .remove() is only 2%. – Muddle 12/2, 2014 at 3:21

I put this in a prototype so I could use it more easily: Element.prototype.clear = function(){while (this.firstChild) {this.removeChild(this.firstChild);}} – Bewray 17/9, 2014 at 14:24

@Topazolite - what if I do document.documentElement.replaceChild(newBody, document.body) ? would the "old" elements and their events persist in memory? (when replacing the whole body element) – Karmenkarna 18/9, 2014 at 13:18

@Andrey Lushnikov: Depends on which browser and which version. Actually firstChild ist best overall: jsperf.com/innerhtml-vs-removechild/250 – Chalco 9/1, 2015 at 9:10

@Karmenkarna I don't believe Kenji's comment is well-founded. Doing innerHTML = '' is slower, but I don't think it's "wrong". Any claims of memory leaks should be backed up with evidence. – Douglassdougy 13/5, 2015 at 0:17

@Andrey Lushnikov firstChild and lastChild are pretty equivalent on my Chrome 43.0.2357.52 (first run removeChildFirst was a little faster, second run removeChildLast won), but both are winners over innerHTML. – Lanta 13/5, 2015 at 7:25

@Kenji, Surely the browser is smart enough to prevent a memory leak. Have you managed to cause a memory leak in the browser? – Breaking 3/6, 2015 at 4:45

Your examples aren't wrong, but I think there's a pretty good case in this answer that the jsperf test was flawed, and didn't measure what it's supposed to. (The claim in the linked answer is that they were only removing empty divs, as they erroneously assumed that the DOM would be repopulated between each test.) In other words, innerHTML is faster, and there's an even faster method (replacing nodes with empty ones). Since your answer is so highly upvoted, it would be nice if you'd revert that part. – Affrica 13/2, 2016 at 5:33

@Bewray Proceed with care and make sure your target audience's browsers work with it. perfectionkills.com/whats-wrong-with-extending-the-dom – Chihli 1/10, 2016 at 10:24

function emptyElement(element) { var myNode = element; while (myNode.firstChild) { myNode.removeChild(myNode.firstChild); } } emptyElement(document.body) – Unconnected 19/10, 2016 at 17:41

(assuming its true) it would be nice to have the reason in the answer – Ideatum 27/1, 2017 at 19:18

I tried myNode.childNodes.forEach(function (c) { c.remove() }), but this doesn't remove all the children. I realize some browsers don't support the method, but for the browsers that do support it, it doesn't remove all the nodes. Why does the while loop work better than NodeList#forEach()? – Antimalarial 27/11, 2017 at 4:50

@Antimalarial You are modifying a collection that you are actively iterating over when you use forEach in that manner. – Jessikajessup 3/3, 2018 at 15:38

This is ridiculous. Why performance matters here? Is it 120 fps or one-off operation? – Skeet 23/12, 2018 at 19:42

I agree with @MichalStefanow. In this case, simplicity of code should precede the minimal performance gain, unless you are working on a specific scenario that requires this level of meticulous optimization. It will not make a difference when removing 5-15 nodes. – Moneybag 11/1, 2019 at 20:39

As a new web developer, just wanna say u sir are a god. Thanks for both the methods. I have been playing around with both! – Gough 3/2, 2020 at 2:46

remove gives an infinite loop for me on Brave 80.1.5.123. removeChild works fine – Northwester 7/5, 2020 at 9:27

If I have 10 children elements I want to remove and each of them has an event attached to it, should I remove the event first then element itself or I don't need to remove the event, I can just remove the element itself??(vanilla javascript) – Fleury 13/1, 2021 at 16:29

Concerning @stwissel’s remark about innerHTML not working on SVG elements: that was fixed across all browsers by the start of 2015, except of course for IE that was no longer being developed by then (only maintained). So long as you’re not supporting IE11 (which you actively shouldn’t, let it die!), you can happily use innerHTML on SVG elements. – Mcneely 22/9, 2021 at 14:52

I feel like this answer should be edited to list textContent first, since that's the faster and safer option – Accroach 18/6, 2022 at 17:3

L

546

In 2022+, use the `replaceChildren()` API!

Replacing all children can now be done with the (cross-browser supported) replaceChildren API:

container.replaceChildren(...arrayOfNewChildren);

This will do both:

remove all existing children, and
append all of the given new children, in one operation.

You can also use this same API to just remove existing children, without replacing them:

container.replaceChildren();