HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
airbnb
javascript
JavaScript2012–2026
airbnb / javascript

javascript

JavaScript Style Guide

79Distinct people
82Mentions
2Explicit recommenders
148KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

JavaScript Style Guide

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

Ah, eslint-config-airbnb. My favorite airbnb config issues: https://github.com/airbnb/javascript/issues/1271 https://github.com/airbnb/javascript/issues/1122 I literally spent…

rs186 used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 6:01:08 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year82 dated mentions

Observed mentions: 2012-11-05 18:18:38 UTC to 2026-01-07 11:44:34 UTC.

051015202012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20122013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 4 mentions; 4 submissions, 0 comments2014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 7 mentions; 3 submissions, 4 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 21 mentions; 7 submissions, 14 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 10 mentions; 2 submissions, 8 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 12 mentions; 2 submissions, 10 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 4 mentions; 2 submissions, 2 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 4 mentions; 3 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC110
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC440
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC734
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC21714
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC1028
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC12210
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC422
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC404
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC202
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC110
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC312
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC202
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC431
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC413
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC303

From the project README

An excerpt from the repository, fetched Nov 12, 2026.

Read the project’s introduction
Airbnb JavaScript Style Guide() { A mostly reasonable approach to JavaScript Note: this guide assumes you are using Babel, and requires that you use babel-preset-airbnb or the equivalent. It also assumes you are installing shims/polyfills in your app, with airbnb-browser-shims or the equivalent. This guide is available in other languages too. See Translation Other Style Guides ES5 (Deprecated) React CSS-in-JavaScript CSS & Sass Ruby Table of Contents Types References Objects Arrays Destructuring Strings Functions Arrow Functions Classes & Constructors Modules Iterators and Generators Properties Variables Hoisting Comparison Operators & Equality Blocks Control Statements Comments Whitespace Commas Semicolons Type Casting & Coercion Naming Conventions Accessors Events jQuery ECMAScript 5 Compatibility ECMAScript 6+ (ES 2015+) Styles Standard Library Testing Performance Resources In the Wild Translation The JavaScript Style Guide Guide Chat With Us About JavaScript Contributors License Amendments Types 1.1 Primitives: When you access a primitive type you work directly on its value. string number boolean null undefined symbol bigint const foo = 1; let bar = foo; bar = 9; console.log(foo, bar); // => 1, 9 Symbols and BigInts cannot be faithfully polyfilled, so they should not be used when targeting browsers/environments that don’t support them natively. 1.2 Complex: When you access a complex type you work on a reference to its value. object array function const foo = [1, 2]; const bar = foo; bar[0] = 9; console.log(foo[0], bar[0]); // => 9, 9 ⬆ back to top References 2.1 Use const for all of your references; avoid using var. eslint: prefer-const, no-const-assign Why? This ensures that you can’t reassign your references, which can lead to bugs and difficult to comprehend code. // bad var a = 1; var b = 2; // good const a = 1; const b = 2; 2.2 If you must reassign references, use let instead of var. eslint: no-var Why? let is block-scoped rather than function-scoped like var. // bad var count = 1; if (true) { count += 1; } // good, use the let. let count = 1; if (true) { count += 1; } 2.3 Note that both let and const are block-scoped, whereas var is function-scoped. // const and let only exist in the blocks they are defined in. { let a = 1; const b = 1; var c = 1; } console.log(a); // ReferenceError console.log(b); // ReferenceError console.log(c); // Prints 1 In the above code, you can see that referencing a and b will produce a ReferenceError, while c contains the number. This is because a and b are block scoped, while c is scoped to the containing function. ⬆ back to top Objects 3.1 Use the literal syntax for object creation. eslint: no-new-object // bad const item = new Object(); // good const item = {}; 3.2 Use computed property names when creating objects with dynamic property names. Why? They allow you to define all the properties of an object in one place. function getKey(k) { return `a key named ${k}`; } // bad const obj = { id: 5, name: 'San Francisco', }; obj[getKey('enabled')] = true; // good const obj = { id: 5, name: 'San Francisco', [getKey('enabled')]: true, }; 3.3 Use object method shorthand. eslint: object-shorthand // bad const atom = { value: 1, addValue: function (value) { return atom.value + value; }, }; // good const atom = { value: 1, addValue(value) { return atom.value + value; }, }; 3.4 Use property value shorthand. eslint: object-shorthand Why? It is shorter and descriptive. const lukeSkywalker = 'Luke Skywalker'; // bad const obj = { lukeSkywalker: lukeSkywalker, }; // good const obj = { lukeSkywalker, }; 3.5 Group your shorthand properties at the beginning of your object declaration. Why? It’s easier to tell which properties are using the shorthand. const anakinSkywalker = 'Anakin Skywalker'; const lukeSkywalker = 'Luke Skywalker'; // bad const obj = { episodeOne: 1, twoJediWalkIntoACantina: 2, lukeSkywalker, episodeThree: 3, mayTheFourth: 4, anakinSkywalker, }; // good const obj = { lukeSkywalker, anakinSkywalker, episodeOne: 1, twoJediWalkIntoACantina: 2, episodeThree: 3, mayTheFourth: 4, }; 3.6 Only quote properties that are invalid identifiers. eslint: quote-props Why? In general we consider it subjectively easier to read. It improves syntax highlighting, and is also more easily optimized by many JS engines. // bad const bad = { 'foo': 3, 'bar': 4, 'data-blah': 5, }; // good const good = { foo: 3, bar: 4, 'data-blah': 5, }; 3.7 Do not call Object.prototype methods directly, such as hasOwnProperty, propertyIsEnumerable, and isPrototypeOf. eslint: no-prototype-builtins Why? These methods may be shadowed by properties on the object in question - consider { hasOwnProperty: false } - or, the object may be a null object (Object.create(null)). In modern browsers that support ES2022, or with a polyfill such as https://npmjs.com/object.hasown, Object.hasOwn can also be used as an alternative to Object.prototype.hasOwnProperty.call. // bad console.log(object.hasOwnProperty(key)); // good console.log(Object.prototype.hasOwnProperty.call(object, key)); // better const has = Object.prototype.hasOwnProperty; // cache the lookup once, in module scope. console.log(has.call(object, key)); // best console.log(Object.hasOwn(object, key)); // only supported in browsers that support ES2022 /* or */ import has from 'has'; // https://www.npmjs.com/package/has console.log(has(object, key)); /* or */ console.log(Object.hasOwn(object, key)); // https://www.npmjs.com/package/object.hasown 3.8 Prefer the object spread syntax over Object.assign to shallow-copy objects. Use the object rest parameter syntax to get a new object with certain properties omitted. eslint: prefer-object-spread // very bad const original = { a: 1, b: 2 }; const copy = Object.assign(original, { c: 3 }); // this mutates `
Read the full README on GitHub

What Hacker News says

12 sources
Well, the most widely used style guide [0] and Facebook and many others including myself disagree. I'd rather see default exports everywhere so I only ever have to import one thing from your file. None of the points made in the article are even valid. 1) You don't get better DX because you simply cannot use the same symbol name everywhere all the time anyway because names clash. 2) With point 1 gone, point 2 is wiped out as well. 3) This is patently false. [0] https://github.com/airbnb/javascript#modules--prefer-default...
In Why we have banned default exports in JavaScript
Not books per se, but you are probably interested in frontend specific stuff, as you mentioned Angular and Vue. (Not directly inner workings, but somewhat linked): Coding Style: As a quick reference and to learn about some bad patterns (and how to avoid them), I can recommend the airbnb style guide [1]. They also link to eslint rules, which always have a reasoning why a rule is considered, e.g. the no new object rule [2]. A really interesting thing in the code style corner is prettier, which auto-formats source code pretty [3]. References: The Mozilla Developer Reference Manual, e.g. for String.match [4]. It also has explanations for browser APIs. To check if you already can use a certain browser feature, I recommend caniuse [5] Now, as you also mentioned your an "old Java Programmer". I think it's quite interesting what goes on the JavaS
Read the rest
cript space and which features are ~~stolen~~ borrowed from which language. Good search queries to understand the language and it's features (especially the new ones) would be - Javascript Classes vs Prototype - Javascript Decorators - Javascript Arrow Functions (Lambda) - Node.JS Streams - Reactive Extensions - Flow vs. TypeScript Well I hope that some of that info is usable for you, if you have any detail questions, please just comment :) [1]: https://github.com/airbnb/javascript [2]: http://eslint.org/docs/rules/no-new-object.html [3]: https://github.com/prettier/prettier [4]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [5]: https://caniuse.com/
In What's the best book to read about JavaScript?
Sometimes writing a custom rule makes sense, but it should be an exception and not the rule. Otherwise, you risk creating a sub-dialect only your team knows. That becomes a problem both for new hires, which have to take more time to ramp up, and for current dev switching jobs as they'll have a hard time abandoning what they learned. That's why I like sticking as close as possible to AirBnB's guide[0], not because it's better than anything else, it's just that most developper seem to agree on it and it's familiar to most dev. [0]: https://github.com/airbnb/javascript
In Writing custom ESLint rules for your picky developers
One of the Airbnb style guide authors here. The point about quotes comes up often. The important part for us is consistency at Airbnb. We use eslint to enforce and maintain the consistency. Would it be more consistent to treat strings the same everywhere? For some projects sure. We diverge from the community a bit in the sense that we treat JSX as not JS and we aim to be consistent about that. If your project treats JSX and JS the same then yes, we've certainly seen folks do this. As always, please do what works best for your team or project [1]. Forks encouraged. I will say an added benefit of including a style guide in a project for large teams that may get lost jumping straight into prettier, has been helping our engineers become stronger javascript programmers in the process of learning our style guide. That's largely anecdotal eviden
Read the rest
ce from my time at Airbnb and of course your mileage my vary. Personally, I support the Prettier mission 100%. Easier consistency is huge. Removing barriers to contributing to open source projects is huge. PR reviews focused on what the code is doing vs painful style nits is huge. It's been great to see this come from the community and I look forward to seeing where the community takes it. Congrats to all of the contributors on the 1.0! [1] https://github.com/airbnb/javascript/issues/102
In Prettier 1.0
Prettier goes such a long way to enforcing standards on a language and ecosystem which otherwise has none or few. What standards do exist are frequently arbitrary, or enforced by legacy code at random companies. For example, the Airbnb JS style guide [1] recommends single quotes in JS, but double quotes for JSX properties. Why the difference? Why not stick with double quotes everywhere, as they are required in JSX blocks? Answer: legacy code at Airbnb [2] I'm hoping to see similar efforts on project file/folder structure at some point. How often do two node projects created by different engineering teams end up with the same folder/file structure? There's nearly no strong community convention, unlike many other languages/frameworks. Rails, for example, famously touts that any engineer can walk onto another Rails project and have a r
Read the rest
easonable suspicion of where to find a particular piece of code. 1: https://github.com/airbnb/javascript 2: https://twitter.com/hshoff/status/784205839347232768
In Prettier 1.0
If you want a prebuilt eslint config, and you don't like the really popular ones (eg, airbnb[0]) because they default to requiring semicolons, then this is definitely the most popular of the ones that require you to omit semicolons. Beyond that, there are no advantages. It's just a decent eslint config that requires you to omit semicolons wherever possible. If that's important to you, use it. If it's not important, or you'd rather not omit semicolons, or if you do want to omit semicolons but you're happy making a one line change to the airbnb preset, then there's nothing to set this apart from more, if you'll pardon the expression, "standard" options. :) [0]: https://github.com/airbnb/javascript
In StandardJS just turned 10.0.0

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.