I've heard doing document.getElement... and then modifying the DOM is costly.
So, manipulating the DOM uses more memory than, say, manipulating strings.
But assuming you're going to change something on the DOM anyway, the framework has the exact same API's to manipulate the DOM that you do. And they have their own overhead to figure out what operations they want to run.
Almost by definition, vanilla will always be faster.
That doesn't mean it's always better. If you need the DOM to reflect changing states in complex ways (think Trello or Notion) I'll be the first to admit it's simpler to let someone else's algorithm morph the DOM. And that's okay.
Pretty much if you make changes to a DOM element and then read a computed value from it before a new frame renders (like dimensions etc), the browser has to recalculate the page layout before it can return an answer.
Fast: Read -> Modify -> Paint
Slow: Modify -> Read (reflow!) -> Paint
This generally isn’t an issue but if you’re seeing hiccups it’s either GC run wild, synchronous code chewing up the frame budget or frequent reflows.
Then only use JavaScript where it makes sense.
For example, using Angular, React, Vue to display text or encapsulate three.js is probably not the best use case of customers CPU and bandwidth.