Good follow up question.
The first issue is the context. Your code kept adding the class to the same parent node, not a newly appended child node. The div with class 'list' is the parent of the div with class 'item' (in the correct code). All the text was piled into one container in your code.
A minor but pertinent concern is, using the tag name in the selector. It does not raise the specificity by much, and in our case since there is only one element with the class, the class is the more specific and all we need.
A more oblique issue is the chaining, notwithstanding the above note what the correct code will do.
adds the class to the current context object, the parent node in this case. From a vanilla perspective, in pseudo code,
this is the context object,
We could do some variations on the earlier posted model, but what if we approach this from the child node point of view, and build the child, then append to the parent?
Here the idea is to create the child node in memory, tagname, classname and textnode, then append the completed object to the object of our choice. Now the chaining is in the context of the new object, not the parent. Making sense?
The target object does not need to be a jQuery object. (note)
var toAdd = "some value"
This is because
appendTo creates a transient object using our selector.
jQuery helped to bridge that gap so we could think in OOP terms, and let JS do the heavy lifting. jQuery is an abstraction, and consequently its code is, too. It never hurts to investigate into what JS is doing under the hood when we give jQuery something. The more we understand vanilla code, the more we can do with jQ.
is the alias for