Is it safe to rename document variable in javascript

Question

I noticed that Google Closure Compiler did not rename document to something like d to reduce space.

I cannot think of a case where this would break the code (ie where document points to something else down the road). Actually the same goes for window.

Is there a reason for protecting document this way?

== EDIT ==

By renaming it I was thinking reassigning it. Example below.

var d=document;
var obj1=d.getElementById("obj1");
var obj2=d.getElementById("obj2");
... // with enough uses of document so it makes to reassign it size-wise.

possible duplicate of [What advantages does using (function(window, document, undefined) { ... })(window, document) confer?](http://stackoverflow.com/questions/5020479/what-advantages-does-using-functionwindow-document-undefined-windo) — Bergi, Aug 27 '13 at 09:40
@Bergi This is a closure-compiler specific issue (that is likely to be resolved in the future), I don't see how this is a duplicate. — Benjamin Gruenbaum, Aug 27 '13 at 09:47
@BenjaminGruenbaum: It answers the question "*What is the reason for protecting `document`?*" (though it might use a different way). But you're right, I didn't notice the GCC-specific part of the question. — Bergi, Aug 27 '13 at 09:50
The reason closure compiler protects `document` is _not_ the same as wrapping the code with an IIFE. The questions are similar in that they both discuss "protecting" document but other than that they're different. — Benjamin Gruenbaum, Aug 27 '13 at 09:52

score 3 · Answer 1 · answered Aug 27 '13 at 13:07

Closure-compiler does not perform this "optimization" by default for the simple reason that it produces LARGER source when used with gzip. You can enable this optimization by turning on the AliasExternals pass using either the Java API or a custom build.

See https://code.google.com/p/closure-compiler/source/browse/src/com/google/javascript/jscomp/AliasExternals.java#38

score 1 · Accepted Answer · edited Jun 20 '20 at 09:12

What happens?

ProblemFactory's guess is correct.

This is a //TODO in the closure compiler source code. If we didn't preserve document and window and instead ran them over with d for example, at the moment the closure compiler does not know if it's overriding a global from another file. Like the comments say this will be resolved in the future at which point.

Enough words, show me the source!

If we check the closure compiler source code inside VariableReferenceCheck.java we can find the following:

 private class ReferenceCheckingBehavior implements Behavior {

    @Override
    public void afterExitScope(NodeTraversal t, ReferenceMap referenceMap) {
      // TODO(bashir) In hot-swap version this means that for global scope we
      // only go through all global variables accessed in the modified file not
      // all global variables. This should be fixed.

      // Check all vars after finishing a scope
      for (Iterator<Var> it = t.getScope().getVars(); it.hasNext();) {
        Var v = it.next();
        checkVar(v, referenceMap.getReferences(v).references);
      }
    }

If we check the hot-swap algorithm itself we can see that:

// Note we use the global scope to prevent wrong "undefined-var errors" on
// variables that are defined in other JS files.

So, we can see that this is just the closure compiler not understanding the code of globals across multiple files well enough to make that replacement. You can always do the replacement yourself :)

Thank you very much for the detailed answer! I believe it is not 100% consistent with the fact that Closure Compiler does add global variable to the namespace no matter whether the code did or not in the first place (cf. http://stackoverflow.com/questions/18449503/why-does-google-closure-compiler-adds-variable-to-the-global-namespace-when-the). — Mad Echet, Aug 27 '13 at 12:20
Actually this not correct. Closure-compiler doesn't do this optimization because it creates BIGGER source files when compressed with gzip. — Chad Killingsworth, Aug 27 '13 at 13:04
@ChadKillingsworth That sounds better, I tried deleting this answer but I get a "You cannot delete this accepted answer. MadEchet - consider accepting the other answer. — Benjamin Gruenbaum, Aug 27 '13 at 18:13

IProblemFactory · Answer 3 · 2013-08-27T09:34:01.800

0

I think document is standardized, always-global variable. To use the same way d it has to be global also, thus global namespace will have another "junk" variable.

It could be dangerous for not aware developers (which wont be aware of that thus it is not standard variable).

edited Aug 27 '13 at 09:34

answered Aug 27 '13 at 09:28

IProblemFactory

9,551
8
50
66

Closure Compiler introduces other (short) global names if you compile it with `ADVANCED_OPTIMIZATIONS` – copy Aug 27 '13 at 10:45
When using ADVANCED_OPTIMIZATIONS, Closure-compiler assumes it controls the entire global namespace and so can (and does) introduce several new variable names. See https://code.google.com/p/closure-compiler/wiki/FAQ#When_using_Advanced_Optimizations,_Closure_Compiler_adds_new_var – Chad Killingsworth Aug 27 '13 at 13:09

Is it safe to rename document variable in javascript

3 Answers3

What happens?

Enough words, show me the source!