[hailk]

Interesting. Can you elaborate on this. What do you use this vanillaJS framework for? How do you do DOM manipulation? How much traffic do you get from what you've built using this?

I've heard doing document.getElement... and then modifying the DOM is costly.

[coffeefirst]

> 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.

[Widdershin]

The main performance gotcha to watch out for with hand rolled DOM manipulation is causing a reflow.

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.

[pjmlp]

It helps when one uses Java and .NET server side rendering frameworks, which offered component libraries before nodejs was even an idea, which also allow to package JavaScript and CSS.

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.