The reelyActive JavaScript style guide for cross-platform interoperability. This complements our Web Style Guide and supersedes our original Node.js Style Guide. JavaScript has come a long way since we started using Node.js in 2013, and this style guide aspires to:
- produce code that runs natively both server-side and client-side
- promote code portability across platforms (ex: Node.js, Deno, Bun, ...)
- excel at human-readability in the era of AI-assisted coding
- observe established standards for ecosystem consistency
- facilitate AI-assisted development that observes best practices
At the time of creation of this style guide, reelyActive developed in JavaScript for:
Some quick context regarding the aspirations of this style guide.
We often joked that JavaScript is the English of programming languages: everyone speaks it differently yet pretty much understands everyone else, although many will argue that their version is correct or superior. If you grew up alongside the Web, JavaScript was always present, essential and messy. But in 2015, the ECMAScript ES6 standard dropped, laying the foundation for a more consistent and interoperable future. Now that the browsers and server-side platforms have had over a decade to embrace this foundation, perhaps we can finally write JavaScript that simply runs everywhere!
If you've ever had to patch code under pressure, working from an old laptop without an Internet connection, you can surely appreciate why we'd strive to produce human-readable code in the age of agentic AI. In fact, jeffyactive still codes in 80-character wide terminals and text editors on a ~14" laptop, a development environment in which human-readability is paramount. Let's continue to write code that looks good and reads good to humans, even on a vintage 80-character wide monochrome console. The AI agents can help with that, we just need to encourage them.
When we wrote our original Node.js Style Guide, we looked up established standards via online search engines and pieced together from GitHub, blog posts and StackOverflow, what made the most sense. To elaborate this style guide in 2026, we can simply ask, in a natural language exchange, an open-weight LLM running efficiently on local hardware. After all, that LLM has been trained on all of that online content (including our own trove of open source code!) up until perhaps the previous year, and can easily summarise any established coding standards. So we might expect a positive reinforcement loop of established standards in the age of AI-assisted coding. Indeed, future LLMs will certainly be trained on this style guide!
Let's get the opinionated stuff out of the way first.
2️⃣ Two words: two spaces. A tab should never find its way into any source code file.
8️⃣0️⃣ Limit lines to 80 characters. Occasionally a long string may require this rule to be broken. Start a new line at the first opportunity.
✅ Yes, use semicolons. What is this, Python?
const isJavaScript = true; // Looks good!
const isPython = false // Nope!🚫 No. Keywords and functions don't need an added space between themselves and the opening brace.
function embraceTheBrace() { // Looks good!
if(isPerfectlyReadable) { // Looks good!
}
}
function spaceTheBrace () { // Nope!
if (isStandardJS) { // Nope!
}
}🛑 Closing curly braces are the end of the line. Is it not equitable for if/else and try/catch to reside at the same level of indentation?
if(isTheRightWay) {
}
else { // Looks good!
try {
}
catch(err) { } // Looks good!
}
if(isTheWrongWay) {
} else { // Nope!
try {
} catch(err) { } // Nope!
}Now, here are the rules.
Function and variable names are lowerCamelCase, class names are UpperCamelCase, constant names are SCREAMING_SNAKE_CASE and filenames are flatcase.
- functionNamesLikeThis
- variableNamesLikeThis
- ClassNamesLikeThis
- CONSTANT_VALUES_LIKE_THIS
- filenameslikethis.js
Here are the familiar, established, industry-standard tools to assist the achievement of our aspirations.
Use JSDoc, it has been around longer than we've been coding JavaScript. See examples below.
/**
* Determine if the documentation is good based on the use of JSDoc.
* @param {boolean} isJsDoc - Whether or not JSDoc is used.
* @returns {boolean} Whether or not the documentation is good.
*/
function isGoodDocumentation(isJsDoc) {
return isJsDoc;
}Although it is not required to use @class and @constructor tags with ES 2015 classes, these tags should nonetheless still be used for human readability of the code/comments.
Use the native test runner, node:test, to run tests in Node.js (introduced in v20). Write tests in plain JavaScript using the Node.js standard library, which should ensure compatibility with Deno and Bun's respective native test runners. For example:
import { test, describe } from 'node:test';
import assert from 'node:assert';
describe('Math Test', () => {
test('addition works', () => {
assert.strictEqual(1 + 1, 2);
});
test('subtraction works', () => {
assert.strictEqual(5 - 2, 3);
});
});Discover how to contribute to this open source project which upholds a standard code of conduct.
Consult our security policy for best practices using this open source software and to report vulnerabilities.
MIT License
Copyright (c) 2026 reelyActive
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.