I think the better take away might be: avoid changing the structure of 'hot' objects at runtime.

JS engines will zero-in on these 'hot' objects and attempt to optimize access to it, a task which will be helped if object doesn't change in structure over its life-time. 'delete' will trigger such a structure change.

By structure in context of JS, one should think inferrable structure like always setting .a to a Number then .b to a String after instantiating an object.

Agreed. But I'd worry about something like this once I notice I want to improve performance. In the book Beautiful Code one of the authors urged programmers to write beautiful code first then optimize when needed later. It's easier to optimize beautiful code than it is to beautify optimized code. Using delete is a very readable statement of intent.

Certainly delete can be useful, but nulling a property has almost the same effect (apart from hasOwnProperty still returning true) - if you're looking at optimising at the level this article is talking about avoiding delete might well be sensible.

This could also be horrible advice, because now you're mixing types which will make your code a little bit more complex, and you'll iterate over this null and have to deal with it. If you have an object property set to null you'll iterate over it, if you delete it you wont. As for the performance improvements, let's see the jsperf.

https://gist.github.com/4018282

Edit: I found a jsperf: http://jsperf.com/delete-vs-undefined-vs-null/6

Delete is a little slower, but setting null can be too, and setting undefined is the fastest for me in stable chrome.

@btipling

"Burn this article in a fire" :)

Looking back through my article I agree that stating delete should outright never be used didn't make sense. It's of course used in numerous JavaScript libraries and has a purpose in the language. I've updated the text to reflect my suggestion that it should be instead, avoided where possible. This advice stands as it's more difficult for V8 to optimize objects you're changing the structure of.

For others commenting on this thread, I've also taken account of some of your suggestions and tried to update the article to be as accurate as possible. Thanks for the input!

I completely agree.

The author mentions that programmers use delete for dereferencing. What?? That is completely opposite from what 'delete' means and should never be done, ever. Use 'delete' to remove keys from a map, not as a stupid GC hack. Also, 'null != undefined'. They have different meanings. null will show up in a for .. in loop, whereas a 'deleted' member is actually gone.

99% of performance problems are due to wrong code, not inefficient VMs. Write better code and you'll get faster programs. For those problems in the 1%, profile and fix.

I don't know, those are awfully significant performance differences. On mine, the last is 357 times faster than the first - might be a test flaw, but yikes.

That said, this (and many others) is probably not a concern for most (even most JS heavy) sites, since most simply don't compute enough to impact the page as much as, say, reducing reflows.