When it comes to CP2077, given that it's a programming shit-show that after multiple patches STILL can't get anything right, I'm not sure it's something I'd hold up as an example of good design either... and remember it has a menu option to turn that crap and much of the visual FX off for users with accessibility needs, that many NORMAL users dive for just to get rid of the fantasy-land crap nobody should actually deploy real-world.

Kind of like LCARS which is utter garbage from a UX perspective and is a poster child for an artists undr the DELUSION they're a "designer" being involved in building a UI. (wow, did I just piss on 'Trek?)

Even if it is "flat design". /FAIL/ on both font legibility and colour choices.

As to DOM insertion and deletion such as in a table, removeChild on a TR isn't rocket science, and really neither is Element.insertBefore with a little DOM construction like my "make" routine.

As to getting "desynced" that's not a thing if you just store your data on the DOM, which I would in a situation like that. Even if I'm tracking client-side in an isolated scope -- such as generating a object or function related to the element -- when it comes to what I'd send server-side I'd store it in the form so I can easily serialize it, instead of crapping it into a bunch of variables I don't need as some sort of "state".

Because again, I think the notion of "state" is largely trash when you start scaling upwards, adding needless complexity and extra steps you just don't need in the first place. "State" as a separate entity client side is, well... the way it ends up with people implementing it just doesn't seem to be a good idea.

And finally it's not like you can't move an item around on the DOM without recreating it if all you're doing is moving it.

Let's say you wanted to move a TR up one row, and you have a reference to it's Element in the variable "tr"

if (tr.previousElementSibling) tr.parentNode.insertBefore(tr, tr.previousElementSibling);

The use of previousElementSibling being to avoid how some browsers treat whitespace or comments as nodes. (probably not needed

To move it down one?

if (tr.nextElementSibling) tr.parentNode.insertBefore(tr.nextElementSibling.nextElementSibling);

There really should be an insertAfter :D

If you have an element, let's call it "#cart" and you want to move it to before after element like say #mainMenu...

var
  cart = document.getElementById("cart"),
  mainMenu = document.getElementById("mainMenu");
mainMenu.parentNode.insertBefore(cart, mainMenu.nextSibling);

And if what that does "confuses" the rest of your scripting or magically gets "desynced' you're probably doing something horrifically wrong. Like not storing the reference (aka pointer to real programmers) or failing to have a proper "get" method.

Honestly I kind of wish JS had these permanently attacked as methods on Element. Being able to go cart.insertBefore(mainMenu) and/or cart.insertAfter(mainMenu) would be so much cleaner.