I am not experienced in Javascript, just starting to understand how to think it should be used, so my opinion should not carry the same weight as that of someone who is experienced in the specific language. I would be interested in responses to my idea.
I have been experimenting with a style of defining class-like objects that depends on the Javascript with statement. I submit that this is a legitimate use.
Each class-like object in this style functions as a factory for objects to satisfy some purpose.
This style does not make use of the this keyword in instance methods.
This style conceives that each object generated out of one of these class-like objects is to have a public aspect and a private aspect. A Javascript object represents each of these aspects. Holders of references to the object actually only refer to the public aspect. The methods, however, know both aspects and I implement this with closures.
I do not pretend that this style is applicable to cases where we care much about runtime time or memory performance. I deliberately sacrifice quite a bit of each of those to programming efficiency. I expect to find plenty of cases where I want to program something quickly and with little chance of error, and where the demands at runtime will not be critical.
Since I have been trying code in a browser rather than node.js, a practical consideration of the development environment for me is that syntax errors in a large source file can be hard to pin down and correct. I counter this problem by adding code in small increments. Therefore, I want the class-like objects to be able to accept an instance method definition at a time, rather than requiring that all method definitions appear in one source file.
I declare a class-like object initially without any instance methods defined in it, and I place the class-like object in whatever namespace I am programming in.
Then I call the class-like object repeatedly at a method in it called "init" and each time, I pass an initializer, a function to be called during the initialization of an instance.
Eventually when I start using the class-like object as a factory for its instances, whenever I ask it for a new instance, it creates the public and private aspects for the instance, links the private aspect to the public one, then calls all the initializers that have been defined, passing to them the private aspect of the new instance.
In my style, every public attribute is a method. All variables whose values will not be functions should live on the private side.
One thing an initializer can do is establish a variable on the private side.
Another thing an initializer can do is to add a method either on the public or the private side.
Order matters for executing the initializers -- the class-like object is required to execute them in the same order in which they are defined. Consequently, each initializer can count on the public and private aspects of the instance having the attributes that were established by the earlier initializers. For the programmer, this creates in effect a pair of lexical scopes, since the initializers are not established by conditional or dynamic code of any kind; they are established as the source files are executed by the browser right after it reads and parses them.
Now in some languages, specifically the Ruby language and the Self language, you can write a naked identifier and have it interpreted as a method call on the current object. So in Ruby, "foo" can mean "self.foo" and in Self, "foo" can mean "self foo" (the syntax of method call differs between these languages, but up to the level of detail at which I am speaking of the semantics now, "self.foo" in Ruby and "self foo" in Self are the same). This abbreviation out of existence of "self" is particularly convenient for calling private methods and instance variables. The Javascript language does not provide this convenience.
In contexts inside an instance method where I want to use an attribute of the private or public side for its value (note, not on the left-hand side of an assignment), I like the convenience of referring to the attribute by just its name and not having to write "vars." or "self." to the left of it to locate it (I use "vars" for the private aspect and "self" for the public aspect). For this reason, I wrap each initializer in a Javascript with statement. This seems legitimate to me, because in my style, the population of the targeted object is lexically established. To see the attributes, the programmer needs only to look at the initializers provided earlier in the source files to the same class-like object (which is itself identified by name in the source code, so for software-engineering purposes we can regard it as a lexical entity, even though none of the Javascript parsers detect this).