So, getting the elephant out the way first. "Append" means "Insert at the end [of something]" and "Prepend" means "Insert at the beginning [of something]".
Now that we know the difference between "append" and "prepend". I'd like to mention that <Element>.append() exists.
And also that the ".appendChild()" is, more specifically: <Node>.appendChild().
It makes more sense now to compare <Element>.append() with <Node>.appendChild() than <Element>.prepend() with <Node>.appendChild(), now that we know the difference between the words "prepend" and "append".
So, first. Note that one is a method of <Element> whilst the other is a method of <Node>. If you look at the linked MDN page of <Element> you'll see that an <Element> "is" a <Node> (but not all nodes are elements).
If you're reading this, you probably know what an element is, but what is a node? Well, a simple way to figure out that is to look at the types of nodes that exist. You can also find that information on MDN, but for your convience, a screenshot has been provided below:
Most notably, however. Or rather, the only other node that I remember is the "text node". This is an example of a text node:
I'm sure you've seen this before, it's an example of a child node, that isn't an element.
This distinction is important, since you may be iterating on <Element>.childNodes, and wondering why all of a sudden ".append() is not a function" when you've obviously used in a million times. The solution there would be to use <Element>.children or .appendChild().
Let's start talking about some of the differences.
TL;DR .append() is better than .appendChild() in practically every way.
For starters, you can directly append text nodes as strings:
- parent.appendChild('This is some text.'); // Error
+ parent.append('This is some text.'); // Totally fine.
You would need to create a text node:
+ parent.appendChild(document.createTextNode('This is some text.')); // Fine.
Also, .appendChild() returns the Node. Whereas, .append() simply returns undefined. Wait, this is actually inconvenient.
But, .appendChild() is also just much more stricter, take a look at the list of throw cases for this exception:
Versus (for .append())...
You can also .append() multiple nodes at once... whereas you can only .append[ASingleNode]Child() at a time.
Which means this will work:
// Move all pinned tasks to the top of the to-do list.
todoListElem.prepend(...todoListElem.childNodes.values().filter((taskElem) => taskElem.classList.includes('pin'));
Okay, but I why?
Well, it's quite simple. <Node>.appendChild() is old. It comes from the original, foundational, DOM API. And that API was designed to be very precise, low-level, or let's just say, it was a lot more "computer scientist" than "web developer". After all, those the were the people who created it. The generic idea was "This method will do one thing, and do it explicitly".
That's why .appendChild() is purposefully so strict.
.append(), is a modern "addition" - actually, the whole "Element" API is an "addition", that was built "on top" of the "Node". So, it contains everything from the past... and more (for backwards-compatiability, ensuring all old websites still work and whatnot).
This newer API, developed by web developers, just looked at how people (and themselves ig) were using the existing methods and just made life more convenient for everyone. So, now we don't have to manually create a text node.. every. single. time. The .append() does that for us internally.
One thing that is less convenient though, is the return value. If everything is supposed to be easier - why the hell would you return "undefined"? Method-chaining is awesome!
The reason is quite simple. Since you can append multiple elements, what should the return value be?
Okay, the natural conclusion is an array of nodes (included newly created nodes, e.g; String -> TextNode, return TextNode). But now, if there's one node, do we return just that one node and array... with just one node inside of it? There's pros and cons to both (I'd recommend the array).
Another issue is just performance, creating an array every single time you append, is too much - maybe not for your web project, but JavaScript (and the DOM API) is built for a wide variety of project types, and for some, performance is important (JS is already slow enough as it is - compared to other languages), and the DOM API is a very critical point. Simply put: undefined is the cheapest and fastest option.
And finally, you could say it's also to encourage best practices. While method-chaining is really useful sometimes, it can lead to unreadable code. The forceful removal that, makes your code a more straight-forward list of excutable tasks. Like:
// 1. Create and collect your nodes
const div = document.createElement('div');
const span = document.createElement('span');
const nodesToAdd = [div, span];
// 2. Configure them
nodesToAdd.forEach(node => node.classList.add('new'));
// 3. Perform the DOM operation
parent.append(...nodesToAdd);
// 4. ...
Which is a lot more nicer than...
parent.append(document.createElement('div'), document.createElement('span')).forEach(node => node.classList.add('new'));
Albeit, I'd say that a competent developer would learn to not do that anyways, and the programming language shouldn't be the one to enforce best practices. However, I don't think this is actually the case, since modern JS usually does what I prefer: a slight nudge / encouragement, like how: <Document>.getElementById('myElement') (old & strict method, heavily encourages you to use only one, unique ID in your HTML code). But modern JS gives you the option of document.querySelectorAll('#myElement');. Although, you could also argue that that is just an "unfortunate" consequence / a "negative" side-effect of using CSS selectors.
Anyways, I went on a little tangent - hope all your questions were answered.
