This Vue project I took over uses document.getElementById(...).innerHTML = stuff in its async created method.

That's the rant.

y tho

So you know, that's also been my experience and is the level of ability I've come to expect out of Vue projects.

Isn't async different in JS though? Everything is synchronous technically because it just gets SMOOSHED into the event loop when it's ready?

So really that should be fine, no? Usually this is bad thanks to thread safety and all that, but there are no such worries in JS.

@AlgoRythm The problem is that it's now uncertain what Vue thinks of the component state when it creates it. It has no way of reading the dom, so when you modify it in this way you end up with all kinds of deep voodoo. The async is just icing on the cake.

It's often the very first warning you run into when diving into getting started guides. Bold. With a red background.

And this is a 4 year old project with page after page after hundreds (after thousands?) of lines with this stuff.

@ltlian I see, thanks for the info. Never used Vue before.

@AlgoRythm
On top of Vue specific issues, InnerHTML usage should be avoided in most cases. Even though It's not as bad as it used to be (won't execute scripts anymore), it's behavior is still obliterative.

Innerhtml always causes a full dump and reevaluation of whatever text was placed into it. The correct way to go about it is usually to work directly with the DOM Element API so you impact the smallest change possible.

@SortOfTested I think the only use case that is legitimate for it is to empty an element, like clearing a list or something.

Obliterative is a good word.

@AlgoRythm
For consistency, I tend to follow the discrete practice and create a new instance of the root element and then add it to the contextual parent using replaceChild.

Frameworks that handle the rendering tend to use this approach as well; compose the whole modified graph and apply once. This can be further optimized using requestIdleCallback if your SLA allows for it.