All optimising Javascript runtimes use "shapes" (SpiderMonkey term) or "hidden classes" so that instead of objects being treated as the dictionaries or hashmaps they can instead be treated like fixed regular structs. This makes property lookups much more efficient when you have many objects using the same shape. But notably, simply having the same properties does not ensure that the hidden shape definition will be the same - adding properties to an object in a different order will result in different shapes. This article by Mathias Bynens is a great introduction to the topic.

Beyond the trivial things like not needlessly setting properties in a random order, what principles should I be following to write code that will use shapes in a highly performant way?

• Is it important to ensure that all entries in an array have the same shape?
• Is delete a performance killer compared to setting a property to null?
• Is setting lots of properties one by one in a class constructor worse than setting many properties at once in an object literal? If so, how should classes ideally be used?
• Are there any other general principles for shapes that don't just boil down to being careful when adding/deleting properties?

It may be that the performance hit of using shapes inoptimally is not really so severe; rather shapes are just something that it helps to develop a sixth sense for, to develop in such a way that you use regular object definitions as much as possible. But if there are some general guidelines it would be great to learn them.

All optimising Javascript runtimes use "shapes" (SpiderMonkey term) or "hidden classes" so that instead of objects being treated as the dictionaries or hashmaps they can instead be treated like fixed regular structs. This makes property lookups much more efficient when you have many objects using the same shape. But notably, simply having the same properties does not ensure that the hidden shape definition will be the same - adding properties to an object in a different order will result in different shapes. This article by Mathias Bynens is a great introduction to the topic.

Beyond the trivial things like not needlessly setting properties in a random order, what principles should I be following to write code that will use shapes in a highly performant way?

• Is it important to ensure that all entries in an array have the same shape?
• Is delete a performance killer compared to setting a property to null? And therefore that Typescript's optional properties should be avoided in hot code?
• Is setting lots of properties one by one in a class constructor worse than setting many properties at once in an object literal? If so, how should classes ideally be used?
• Are there any other general principles for shapes that don't just boil down to being careful when adding/deleting properties?

It may be that the performance hit of using shapes inoptimally is not really so severe; rather shapes are just something that it helps to develop a sixth sense for, to develop in such a way that you use regular object definitions as much as possible. But if there are some general guidelines it would be great to learn them.

All optimising Javascript runtimes use "shapes" (SpiderMonkey term) or "hidden classes" so that instead of objects being treated as the dictionaries or hashmaps they can instead be treated like fixed regular structs. This makes property lookups much more efficient when you have many objects using the same shape. But notably, simply having the same properties does not ensure that the hidden shape definition will be the same - adding properties to an object in a different order will result in different shapes. This article by Mathias Bynens is a great introduction to the topic.

Are there any static analysis tools for Javascript or Typescript that would warn when inoptimal shapes would be used, such as adding properties in the multiple orders, adding or deleting properties to only some objects in an array, or long chains of property additions which mean changing the shape of an object many times?

I haven't ever heard of anything like an automated tool for this, and it may be that the performance hit of using shapes inoptimally wouldn't be worth the effort of devising such a tool; rather shapes are just something that it helps to develop a sixth sense for, to develop in such a way that you use regular object definitions as much as possible. But if there is such a tool already it would be great to know about.

All optimising Javascript runtimes use "shapes" (SpiderMonkey term) or "hidden classes" so that instead of objects being treated as the dictionaries or hashmaps they can instead be treated like fixed regular structs. This makes property lookups much more efficient when you have many objects using the same shape. But notably, simply having the same properties does not ensure that the hidden shape definition will be the same - adding properties to an object in a different order will result in different shapes. This article by Mathias Bynens is a great introduction to the topic.

Beyond the trivial things like not needlessly setting properties in a random order, what principles should I be following to write code that will use shapes in a highly performant way?

• Is it important to ensure that all entries in an array have the same shape?
• Is delete a performance killer compared to setting a property to null?
• Is setting lots of properties one by one in a class constructor worse than setting many properties at once in an object literal? If so, how should classes ideally be used?
• Are there any other general principles for shapes that don't just boil down to being careful when adding/deleting properties?

It may be that the performance hit of using shapes inoptimally is not really so severe; rather shapes are just something that it helps to develop a sixth sense for, to develop in such a way that you use regular object definitions as much as possible. But if there are some general guidelines it would be great to learn them.