An interesting question was asked recently in LinkedIn's JavaScript group:

Does JavaScript need to be renamed?

The question really got me thinking.

There's no doubt there are problems with JavaScript's branding:

1. The official specification for the language is actually called ECMAScript – a somewhat clumsy bit of branding on the part of the standards organisation that oversees the language's specification, Ecma International.

2. Correctly, "JavaScript" refers to a subset of ECMAScript specified by Mozilla, but the word is used interchangeably to refer to multiple different ECMAScript supersets, depending on context.

3. JavaScript is a trademark of Oracle Corporation, which doesn't fit comfortably with the language's position as a central component of the web platform, which is meant to be built entirely from open technologies and standards.

4. There isn't even an official logo for JavaScript, let alone a cute mascot like Go's gopher or PHP's elephant.

An unofficial, community-made logo for JavaScript. Source: https://github.com/voodootikigod/logo.js

5. And famously, JavaScript is unrelated to Java. This has confused the hell out of non-technical managers and recruiters for decades.

But for me, the big problem with the name JavaScript is its fuzzy scope. If a computer program is documented as having been written in JavaScript, that does not tell me everything I need to know to run the program. I do not know:

• The minimum version of ECMAScript with which the program is compatible, or at least what JavaScript engines or runtime environments the program supports.
• What host APIs – language extensions added by the runtime environment – the program depends on. Is the program intended to run "client-side" (in a web browser), "server-side" (in the Node.js runtime environment), or is it universal?

The confusion is demonstrated by the difficulty of consuming third party libraries. Browse GitHub for open source JavaScript packages that solve a particular problem, and for each solution you must dig deep into the README or the package.json file to discover if that particular JavaScript package is compatible with your own JavaScript application.

(The problem is made worse by the current period of transition between module systems: from community-derived conventions such as CommonJS, AMD and UMD, towards ECMAScript's standard module notation.)

Rebranding JavaScript might help to clear up all this confusion.

A New Name for JavaScript

If we did rebrand JavaScript, what would we call it?

JavaScript has already had lots of names. Brendan Eich – who designed and implemented the first version of the language – had wanted to call it Mocha, but the marketing boffins at Netscape called it LiveScript when it was first shipped in an early beta of the Navigator 2.0 browser, before settling on the name JavaScript for the final public release at the end of 1995.

Alternative implementations of the language were called JScript (Microsoft's version for its Internet Explorer browser) and ActionScript (Adobe's version). And various dialects of JavaScript that have enjoyed their time in the sun over the years include CoffeeScript and TypeScript.

I think Eich was right all along. Mocha is a great name. In the software space, this name conflicts only with the Mocha test framework for Node.js and a legacy decompiler for Java.

But my personal preference is to rename JavaScript to, simply, JS.

Most people refer to JavaScript by its acronym, anyway. It matches the official file extension. And we could turn that ubiquitous black-on-yellow community logo into the official emblem and not have to remake all our merchandise.

Over time, the origins of the JS name would be largely forgotten, in the same way most PHP developers couldn't tell you what PHP stands for.

Flavours and Versions

What would be better still is to come up with a standard convention to refer to the extended APIs made available to JS programs by particular runtime environments for the purpose of communication with the host system.

For example, if today's ECMAScript becomes JS, then something like WebJS could become the official name for the JS superset that is supported in web browsers, as specified by the World Wide Web Consortium.

And perhaps there could be a ServerJS standard that specifies additional APIs that are expected to be provided by server-side JavaScript runtimes such as Node.js.

Finally, ECMAScript's yearly release cycle and versioning convention is hugely convenient, and this should be extended to all flavours of the newly rebranded JS. Thus, WebJS 2020 would refer to a snapshot of ECMAScript plus all the web APIs that are standardised as of the year 2020.

What do you think? Comment on Reddit, please.

Update 2019-11-10: The JS Party podcast devoted episode 101 to this idea.