Also it's probably worth to mention that manipulation of DOM is not that fast. Every performance optimization article starts with "don't manipulate DOM directly, make a batch of your changes and then inject them in one step".
I don't see any reason for JSDOM in the server to be slow, the object tree being manipulated isn't all that complicated. They aren't suggesting the typical mess of putting useless markup on the wire and then conducting massive repairs to it in the browser's DOM, all while a rendering engine tries to repaint each change.
Seems like the complexity of the client-side code comes from rendering the DOM tree based on the CSS and constraints of the drawing area, hardware, etc. So yeah, just manipulating the tree would seem to be pretty fast.
Of course, it's being compared to spitting out an arbitrary stream of characters to the client without the need to parse HTML on the server side, which is probably faster. Years of experience with the string rendering approach tells us it's definitely more error prone. For example it's impossible to tell whether the character stream is well formed HTML without traversing all the code paths.
that's subjective (unless you can post tests). for example, one of the primary deficiencies of the dom is live node lists, which is an optimization option in jsdom. (also, we do create a fragment and then attach, as perf opts state)
