Not necessarily:
http://stackoverflow.com/questions/8461851/what-is-better-ap...
That's an old post, but even then the conventional wisdom didn't hold up.
Of course there are situations when these two methods of DOM update are on par.
But in any case I agree with one of answers there:
"If you don't mind the fact that innerHTML is a bit limiting (only total replacement of DOM sub-tree rooted at target element) and you don't risk a vulnerability through injecting user-supplied content, use that. Otherwise, go with DOM."
When you do for example this: element.setAttribute("a","b"); browser
1. drops all resolved CSS rules on element, its siblings, its parent and all children. Just in case you have CSS rules like:
element[a="b"] > span { display:none }
And when you do element.appendNode(node):
it does the same as above + plus ensures consistency of HTML DOM (<select> cannot contain <div>s for example).
If you have multiple calls like these then all steps above need to be done for each of them. Engines can optimize such cases but not that much in some cases.
While browser do element.innerHtml it does each step strictly once: build consistent DOM, resolve styles, build rendering tree and mark window [area] as needed painting - request painting.
Browsers optimize this, too - they try hard to keep up metadata structures that tell them whether they need to invalidate styling or not. (This is why mutating the stylesheet is so expensive - browsers have to freshly rebuild the supporting data structures. They could optimize that too, but it's a lot of effort for a rare case.)
So if there's no rules mentioning an [a] attribute in the page, el.setAttribute("a", ...) will generally not do anything.
(One of the benefits of shadow DOM is that the shadow trees are scoped away from the main tree and each other, so you can have more expensive rules in them without making the rest of the page slow. Yay for componentization!)
That's true in general but there are exceptions as usual. Changing @href may trigger not only [href] rules but also :link ones. And :link rules are always present at least in default style sheet. @value triggers :empty. And so on.
But if someone in some library in galaxy far far away (small library used by your application) will add that [a] rule then magically you will get a spike on innocuous el.setAttribute("a", ...) calls in your code.
That's one of points of having transactional yet explicit DOM update mechanism. We have jQuery, Angulars, React, Ember, Vue, (you name it) that definitely need such thing. Sites/webapps that do not use one of those are quite rare these days.