Originally Posted by felgall
with is perfectly valid. your post seems to portray strict mode as some sort of desirable and common feature, which it shouldn't be. sure, if you turn the ES5 features off it doesn't work, but what kind of point is that? Simply un-disable the strict mode, or dispatch the call to a non-strict function.
I don't think any machines (yet) only implement strict. Even in useragents where ES5 strict is further along in development than the full (how could it not be), the full feature set still works.
ES5's Strict, formerly known as ES3CP, is simply a subset of the full spec. It's a less-capable implementation, one for which it's easier to write an interpreter. While they may be re-branding it as some sort of "noob-resistant" option, it's literally the exactly same thing as compact profile is ES3.
to wit, check out the ES3CP spec
A conforming implementation of ES-CP SHALL support the global built-in object, but is NOT REQUIRED
to support the global eval() method (ES3 section 184.108.40.206).
A conforming implementation is NOT REQUIRED to support the with statement (ES3 section 12.10). If
with is not supported, use of a with statement results in a syntax error.
Is it a mere co-incidence that the two major diffs from ES5 to ES5s, and indeed the two you brought up, are the absence of with and eval, the exact same missing pieces in ES3CP? i think not.
according to the ES5 spec
on page 4:
4.2.2 The Strict Variant of ECMAScript
The ECMAScript Language recognises the possibility that some users of the language may wish to restrict
their usage of some features available in the language. They might do so in the interests of security, to avoid
what they consider to be error-prone features, to get enhanced error checking, or for other reasons of their
choosing. In support of this possibility, ECMAScript defines a strict variant of the language. The strict variant
of the language excludes some specific syntactic and semantic features of the regular ECMAScript language
and modifies the detailed semantics of some features.
i will say that the raw execution speed often goes down using with because there is more to be done inside a with than under normal circumstances. It can also make code faster, if it jumps over a few slot in the lexical name lookup chain. With is not always a performance hit and it can make perceived performance much higher.
one example of this is in game programming, where framerate is critical. The code you posted:
var d = document.getElementById('something').style;
d.backgroundColor = '#ccc';
d.color = '#f00';
is problematic for using in a work loop because on each execution, it creates an object reference, d
, that will need to be garbage collected.
garbage collection results in a user-noticeable pause as the stack needs to be frozen while it runs.
using with(), one can avoid the garbage-producing sides effects of namespace caching while having more readable code.