How does JavaScript VM implements Object property access? Is it Hashtable?

V8 doesn't implement Object properties access as hashtable, it actually implement it in a better way (performance wise)

So how does it work? "V8 does not use dynamic lookup to access properties. Instead, V8 dynamically creates hidden classes behind the scenes" - that make the access to properties almost as fast as accessing properties of C++ objects.

Why? because in fixed class each property can be found on a specific fixed offset location..

So in general accessing property of an object in V8 is faster than Hashtable..

I'm not sure how it works on other VMs

More info can be found here: https://v8.dev/blog/fast-properties

You can also read more regarding Hashtable in JS here:(my blog) http://simplenotions.wordpress.com/2011/07/05/javascript-hashtable/

"I guess most of the browser implement it the same, if not why not? is there any requirement how to implement it in the ECMAScript specs?"

I am no expert, but I can't think of any reason why a language spec would detail exactly how its features must be implemented internally. Such a constraint would have absolutely no purpose, since it does not impact the functioning of the language in any way other than performance.

In fact, this is absolutely correct, and is in fact the implementation-independence of the ECMA-262 spec is specifically described in section 8.6.2 of the spec:

"The descriptions in these tables indicate their behaviour for native ECMAScript objects, unless stated otherwise in this document for particular kinds of native ECMAScript objects. Host objects may support these internal properties with any implementation-dependent behaviour as long as it is consistent with the specific host object restrictions stated in this document"

"Host objects may implement these internal methods in any manner unless specified otherwise;"

The word "hash" appears nowhere in the entire ECMA-262 specification.

(original, continued)

The implementations of JavaScript in, say, Internet Explorer 6.0 and Google Chrome's V8 have almost nothing in common, but (more or less) both conform to the same spec.

If you want to know how a specific JavaScript interpreter does something, you should research that engine specifically.

Hashtables are an efficient way to create cross references. They are not the only way. Some engines may optimize the storage for small sets (for which the overhead of a hashtable may be less efficient) for example.

At the end of the day, all you need to know is, they work. There may be faster ways to create lookup tables of large sets, using ajax, or even in memory. For example see the interesting discussion on this post from John Reseig's blog about using a trie data structure.

But that's neither here nor there. Your choice of whether to use this, or native JS objects, should not be driven by information about how JS implements objects. It should be driven only by performance comparison: how does each method scale. This is information you will get by doing performance tests, not by just knowing something about the JS engine implementation.