It probably wouldn't be a bad idea for us to make a full pass on
updating the resources section, but I noticed the podcasts portion was
missing JS Air.
There has been some confusion around which language features should be
used and which should not be used yet. We have a pretty clear-cut rule
at Airbnb about this, which is do not use any TC39 proposals that have
not reached stage 3.
I considered putting this at the very top of the document, but I spotted
this section that seemed to fit.
Addresses #1057
I plan to add some information to this section that applies to ES6 and
everything following ES6. Since we already list this as ES6+ in the
table of contents, I figured it would be a good idea to make this match.
I preserved the anchor to avoid breaking links for folks.
We have been writing CSS in JavaScript and have developed a set of best
practices around this type of thing. I thought it would be nice to
publish this document alongside our other JavaScript style guide
documents.
This eslint rule does not enforce this style guide rule. I believe that
referencing it here will cause people to believe that this is enforced
via linting when it is not. As far as I know, there is no rule that
currently enforces this, but it would be nice to add one.
Broken and concatenated long strings are painful to work with and
produce less readable and searchable code. I think we should reverse
this rule.
Unfortunately, the max-len rule currently does not allow for this, but
there is currently a proposal to add an option to ESLint's max-len rule
that would allow for strings to be ignored.
https://github.com/eslint/eslint/issues/5805
There have also been discussions around performance of string
concatenation (https://github.com/airbnb/javascript/issues/40), but I
don't think that is very relevant here so I removed the links to them.
There has been some confusion around whether we should use single quotes
or template literals. To help avoid this confusion, I am adding a "bad"
example to the single quotes guideline. This rule is already enforced by
the quotes linter rule.
Generally, we want code to clearly express developer intention. Using
template literals communicates that you intend to use some of the
features that template literals offer (e.g. interpolation).
Fixes#992
In 53b4173b we removed the ES5 guide which contains a lot of guidelines
that are no longer very relevant for us. Similarly, some folks have
raised the relevance of these rules about reserved words, given that we
are now living in an age where ES3 support has mostly waned and
transpilers such as Babel are widely adopted and pave over these issues.
This seems like a good opportunity to simplify.
Fixes#61
