The Evolution of Underscore Prefix Convention and Language-Level Private Fields in JavaScript

Introduction: Origins and Significance of Naming Conventions

Naming conventions have always played a crucial role in programming language design. As a dynamically-typed language, JavaScript historically lacked native access control mechanisms. Similar to Python, the JavaScript community developed the convention of using underscore prefixes to identify "private" members. While not enforced at the language level, this convention provides clear code organization in large-scale projects.

Practice and Limitations of Traditional Underscore Convention

Consider the following typical code example:

function AltTabPopup() {
    this._init();
}

AltTabPopup.prototype = {
    _init : function() {
        this._currentApp = 0;
        this._currentWindow = -1;
        this._thumbnailTimeoutId = 0;
        this._motionTimeoutId = 0;
    }
}

In this implementation, all properties and methods starting with underscore are treated as internal implementation details. However, this convention has fundamental limitations: any external code can still directly access these members. Developers must rely on documentation and team standards to maintain encapsulation.

Closure Encapsulation: Early JavaScript Solutions

Before ES6, JavaScript primarily achieved true encapsulation through closures:

function createCounter() {
    let count = 0; // Truly private variable
    
    return {
        increment: function() {
            count++;
            return count;
        },
        getCount: function() {
            return count;
        }
    };
}

While this pattern provides genuine data hiding, it suffers from verbose syntax and poor compatibility with prototype inheritance. With the introduction of class syntax, a more elegant solution for private members became necessary.

ECMAScript Private Fields Proposal: Language-Level Support

In 2019, the TC39 committee formally accepted the class private fields proposal. This proposal introduces the # prefix syntax:

class AltTabPopup {
    #currentApp = 0;
    #currentWindow = -1;
    
    constructor() {
        this.#init();
    }
    
    #init() {
        this.#currentApp = 0;
        this.#currentWindow = -1;
    }
    
    getCurrentApp() {
        return this.#currentApp;
    }
}

Fields and methods prefixed with # are enforced as private at the language level, with external access throwing syntax errors. This design maintains backward compatibility while providing genuine encapsulation capabilities.

Design Decisions and Technical Considerations

The proposal's choice of # over _ as the private identifier was primarily based on:

• Compatibility Protection: Extensive existing code uses _ prefix, requiring a new symbol to avoid breaking current projects
• Syntactic Clarity: # was previously unused in JavaScript identifiers, providing clear visual distinction
• Toolchain Support: Static analysis tools can accurately identify private members, enhancing developer experience

Browser Compatibility and Progressive Adoption Strategy

As of now, all major modern browsers support private field syntax. For projects requiring support for older browsers, syntax transpilation through tools like Babel provides a viable solution. In practical development, we recommend:

• Prioritize # syntax for true encapsulation in new projects
• Gradually migrate existing projects while maintaining _ convention as transition
• Library authors should clearly document API boundaries regardless of convention used

Conclusion: Balancing Convention and Enforcement

The evolution of JavaScript's encapsulation mechanisms reflects the language's maturation process. The underscore convention, as a community-driven standard, played a vital role during periods of limited native support. With the standardization of # private fields, developers now have language-level encapsulation tools. Understanding the appropriate contexts for each approach enables informed technical decisions across different projects.