Why JavaScript Uses camelCase and Python Uses snake_case

JavaScript Inherited Java's Conventions

JavaScript was created by Brendan Eich at Netscape in just ten days in May 1995. The language was originally called Mocha, then LiveScript, and was renamed JavaScript shortly before release — a marketing decision designed to capitalise on Java's growing popularity at the time.

The name was not the only thing borrowed from Java. JavaScript's entire naming convention — camelCase for variables and functions, PascalCase for classes and constructors — was lifted directly from Java's established style. Java itself had inherited this convention from C++ and Smalltalk programming traditions of the 1980s.

Java's original class library (the Java Development Kit, released in 1995) used camelCase methodically throughout: System.out.println(), String.toUpperCase(), ArrayList.isEmpty(). These became the reference standard. When JavaScript was built to look and feel familiar to Java developers, it adopted the same visual style.

The irony is that despite sharing a name and naming conventions, JavaScript and Java are fundamentally different languages with different type systems, execution models, and design goals. The aesthetic similarity was deliberate and strategic, not technical.

Python's Deliberate Choice

Python was created by Guido van Rossum in the late 1980s and first released in 1991. Van Rossum designed Python with readability as an explicit first principle — code should read "almost like pseudocode." The language's name came from Monty Python's Flying Circus, reflecting Van Rossum's preference for a language that felt playful and human.

Python's early standard library used a mix of conventions. Some modules used camelCase (os.path.isFile), some used snake_case (string.split), and some used all lowercase with no separators. This inconsistency bothered Van Rossum and other core developers.

In 2001, Guido van Rossum co-authored PEP 8 (Python Enhancement Proposal 8) — the official Python style guide. PEP 8 made an unambiguous choice: snake_case for all variable names, function names, method names, and module names. PascalCase for class names only.

The reasoning given in PEP 8 was readability: snake_case reads more like natural language. get_user_by_id is more obviously a sequence of three words than getUserById. Van Rossum believed that code was read far more often than it was written, and that visual clarity in reading was worth any minor inconvenience in writing.

The C Language Foundation

Both conventions ultimately trace to C, the language that directly or indirectly influenced virtually everything in modern computing. C's standard library — developed in the early 1970s by Dennis Ritchie and Brian Kernighan — used all-lowercase names with no separators: printf, malloc, strlen. This was partly a character-count convention from an era when terminal lines were short and every character was typed manually.

As languages built on C gained higher-level abstractions with longer, more descriptive names, separators became necessary to maintain readability. The two solutions were the underscore (preserving the all-lowercase Unix tradition) and capitalisation (the approach taken in the new C++ and Java communities). The two camps diverged and crystallised into the Python and JavaScript ecosystems respectively.

Ruby, Go, and the Outliers

Not every language follows the JavaScript/Python split cleanly:

• Ruby uses snake_case like Python, consistent with its "programmer happiness" philosophy and UNIX roots
• Go uses camelCase for internal identifiers, but uses capitalisation as the access modifier: an exported (public) symbol starts with a capital letter (GetUser), an unexported (private) one does not (getUser). Go's standard library is camelCase throughout.
• Rust uses snake_case for variables and functions (like Python), but PascalCase for types and structs (like Java). Rust's compiler will emit warnings if you violate these conventions.
• C# follows Java/JavaScript camelCase conventions, largely because it was designed by Microsoft to compete directly with Java.
• PHP is infamously inconsistent — its standard library functions use a mixture of camelCase (htmlspecialchars), snake_case (str_replace), and concatenated lowercase (array_key_exists), reflecting PHP's evolution by community rather than design.

Why It Matters for Full-Stack Development

The JavaScript/Python convention split has real practical consequences in full-stack web applications. A typical architecture might have:

• A Python backend (Django/FastAPI) with database models using snake_case: user_id, created_at, first_name
• A JavaScript/TypeScript frontend expecting camelCase: userId, createdAt, firstName
• A JSON API layer where the two conventions must be translated

This translation is one of the most common friction points in full-stack development. Solutions include serialisation libraries that automatically convert between cases, enforced API conventions (always snake_case in JSON, always camelCase in JS), or GraphQL schemas that normalise naming on both sides.

The deeper point is that naming conventions are not purely aesthetic. They encode ecosystem expectations, interoperability assumptions, and tool behaviour. Lint rules, auto-formatters (Prettier, Black, rustfmt), IDE autocomplete, and code review standards all depend on consistent naming. When JavaScript and Python collaborate in the same system, convention awareness is a real engineering concern.

Convert between naming cases →