Pros and Cons of "dictionary mode"
Delete makes things slower, yes, but it would be even slower if V8 would try to keep the object in fast mode even when you are changing its shape all the time. Objects must have a fixed set of properties so that they can be statically loaded at fixed offsets (just like fields of C++ or Java objects). If you delete and add properties randomly (I.E. changing the shape of the object), this static loading at fixed offsets cannot be done.
So it's basically a very sensitive heuristic: if you call delete even once, V8 assumes you are going to be changing the object's shape even in the future and gives up on it - even if in reality you are only going to call delete just once and have the shape be unchanged after that.
The benefit is that doing a hash table lookup is much faster than re-calculating the hidden class (and re-compiling all functions based on the old hidden class) every time the shape is changed.
It is to my knowledge that with Javascript when you delete an entry on a object, at least with chrome it puts the object into "dictionary mode" or "slow mode"
That isn't a JavaScript thing; that's an implementation characteristic of the V8 engine inside Chrome. This thread on the V8 users's list discusses this:
[ZenWolf] ...Does using the JavaScript "delete" keyword to delete a property from an object effect (sic) how v8 will optimize the object? ...
[Sven Panne] ...Deleting a property results in going to "slow mode", i.e. using a dictionary for the object's properties. So as a general rule of thumb, using 'delete' makes thing slower...
You can see this effect in this JSPerf. Note how browsers that use V8 (Chrome, Opera 20) are slower with the delete than without it. Firefox's latest SpiderMonkey is blindingly fast either way, IE10 and 11 are slightly impacted. (Interestingly, the engine Opera used for 10.5 through 12 [I think it was], Carakan, was even more impacted by the delete than V8.)
If you're writing code to be used in web browsers, optimizing for a specific engine tends to be a waste of time unless you're facing a specific, real-world performance problem on that engine. (And if you are, once you've dealt with that, make sure those changes don't mess up the other engines!)
If you were writing for NodeJS, SilkJS, etc., then of course optimizing for V8 is fine (although the normal rules of premature optimization still apply), as those are built specifically with V8.
Also is there any semantics around this mode?
No. The semantics of JavaScript are defined by the specification, which doesn't dictate how objects are implemented provided their behavior matches the semantics of the spec; the spec doesn't address performance basically at all. V8 implements objects by generating dynamic classes on-the-fly and compiling them to machine code, but falling back to "slow" (dictionary) mode when you remove properties from them. (If you add properties, the much more common operation as Sven Panne said in the quote above, it dynamically creates a derived class, which doesn't slow things down.) But other engines are free to implement them as hash maps, or linked lists of properties, or anything else.
this article has some answers about how google's v8 handles object properties
the article confirms that there are such things as slow and fast properties
my guess is that if your property names change frequently the "Map" is a better way to go.
https://v8.dev/blog/fast-properties