Name aliases in JavaScript

Readability

It can be reasonably argued that the code is more difficult to read and interpret.

Anyone familiar with JS will instantly know what document.querySelector does, but the same cannot be said for document[ querySelectorFN ]. One can remember, but recalling that information might require time. Worse, one might guess at the meaning of querySelectorFN, and miss where the original programmer thought it was oh-so-clever to change its value to querySelector or querySelectorAll, depending on some criteria. I wish this were a hypothetical.

Out-of-the-box syntax highlighting is lost, as evidenced by the differences in colouring between the first code block and the aliased variant. Other helpful features, like contextual information in code editors, may be impaired, too.

I cannot stress enough how important all of this can be.

High-level programming languages are designed for people. The code ought to be run in a machine, and do so efficiently, but this is not machine code. The lines of code are meant to be read, understood and manipulated by humans. Anyone conciously ignoring this purpose is misusing the technology.

Maintenance

The code will have to be maintained. Change the code and the usage count of any alias might change. There may be some new ones that ought to be introduced. Basically, we have just put upon ourselves the obligation to keep up the pro-minification strategy.

Again, all of this is done by humans. Even if you manage to automate it, the automation will have to be programmed and maintained by a person. This burden can be shifted, managed, and perhaps aliviated, but it is unavoidable.

Not memory use, possibly

It is a bit weird to mention here something that is (maybe) not a problem, but I find the reasoning to be quite interesting. Also, perhaps the chain of thought is wrong and exposing it might provide a chance to realise it and correct it.

There is an issue with closures in general that it is likely to occur but may not have a real impact.

Objects declared in a closure take up space in memory until they are no longer used. Usually, this means until the closure is inactive but, if it includes periodic or asynchronous code executions, it may be considered always active, for all intents and purposes.

Smart garbage collectors will manage to liberate the memory occupied by some variables and constants, if it can be determined that they are not going to be used. However, the more frequent the method or property is called, the more likely it will be used in an always-active part of the code. Since the number of occurences in the code is the basic criteria to create an alias, it stands to reason that that this strategy will be prone to create the aforementioned situation.

Granted, we are talking about relatively small strings and their memory consumption should be negligible, but this can only be evaluated on a case-by-case basis.

Not speed, probably

Again, I think it is interesting to know how to arrive at this conclusion.

Unlike the previous issue, we can evaluate the theoretical impact on speed a priori. To that effect, we can devise a simple test that will do the same operation a number of times, with and without using aliases.

( function( appendChildFN ) {
  
	const NUM_ELEMENTS = 1e6;

	const paragraphs1 = [];
	const paragraphs2 = [];
	for ( let p = NUM_ELEMENTS - 1; p >= 0; p = p - 1 ) {
		const value = Math.random();
		paragraphs1[ p ] = document.createElement( "p" );
		paragraphs1[ p ].innerHTML = value;
		paragraphs2[ p ] = document.createElement( "p" );
		paragraphs2[ p ].innerHTML = value;
	}

	const container = document.createElement( "div" );

	container.innerHTML = "";
	console.time( "alias" );
	for ( let p = NUM_ELEMENTS - 1; p >= 0; p = p - 1 ) {
		container[ appendChildFN ]( paragraphs1[ p ] );
	}
	console.timeEnd( "alias" );

	container.innerHTML = "";
	console.time( "standard" );
	for ( let p = NUM_ELEMENTS - 1; p >= 0; p = p - 1 ) {
		container.appendChild( paragraphs2[ p ] );
	}
	console.timeEnd( "standard" );
  
} )( "appendChild" );

It is far from perfect and comprehensive, but even changing the order, or what array of elements each variant uses, the results are always similar.

On Firefox 105:

alias: 78ms - timer finished
standard: 81ms - timer finished

On Chrome 105:

alias: 267.902099609375 ms
standard: 269.5029296875 ms

I will be the first to point out that this only shows that there is no significant impact in the test. Performace should be measured in production, or in as close as we can get to that environment, but in the absence of that possibility this might suffice.