I'm still unclear on the relevant details, though. If this is just a hint - no semantic effect - then JS engines already speculate and assume you won't modify class prototypes after load. Such speculation is what JS engines put a lot of work into.
Maybe the hint would justify more aggressive speculation, I suppose?
Or, if this is more than a hint - if it has semantic effects, like "use strict" does - then this would be very different than "use asm".
I guess when more info comes out this will become clearer.
I'm guessing that it implicitly implies Object.seal() on all prototypes.
Any legal program that uses 'stricter' and depends on sealed prototypes would be a legal program on a VM that ignores stricter, except in the case of bugs where code was modifying prototypes when it shouldn't, but those would presumably be caught during testing on VMs which did use it.
Presumably, "use stricter" on a codebase that contained attempted prototype modifications would generate errors instead of silent failures.
I don't know the full reasoning behind this, but it might be more about startup time than runtime speed. If you assume early-bound classes, snapshotting becomes a lot easier, you can ahead-of-time trivially compile hidden classes without having to discover them after the fact, and without having to put in code to revert the assumptions later.
Seems like this would be a startup and memory win mobile web, especially if you can easily snapshot a previously loaded app.
Maybe the hint would justify more aggressive speculation, I suppose?
Or, if this is more than a hint - if it has semantic effects, like "use strict" does - then this would be very different than "use asm".
I guess when more info comes out this will become clearer.