Strategy Guide For JavaScript Cheat Sheet

What This Is and Why You Probably Need It

A Strategy Guide For JavaScript Cheat Sheet isn't some magical document that will make you a better programmer overnight. It's a compact reference that organizes the most common patterns, gotchas, and syntax traps into something you can actually look up when you're three hours into debugging a closure issue. I've been maintaining one for about eight years now, and the version I use has probably gone through forty or fifty iterations. The ones that survive are the ones that saved me time when I was already frustrated and didn't need another lecture. The thing most people get wrong about JavaScript cheat sheets is that they try to include everything. That's not a cheat sheet. That's a textbook. A cheat sheet should fit on one or two pages when printed. It should answer the questions you actually have while you're writing code, not the questions you had when you were learning the language for the first time.

Strategy Guide For JavaScript Cheat Sheet

Here's how I built mine, and why each section ended up where it is. The first thing I did was stop looking at existing cheat sheets and start looking at my own commit history. I scrolled back through maybe two hundred commits on projects from the last five years and noted every time I opened a documentation tab to check syntax or behavior. Those are the entries that belong on a cheat sheet. Everything else is noise. The sections that showed up most often were: array methods (specifically the difference between map, filter, and reduce when chaining), Promise patterns and rejection handling, destructuring edge cases, the exact behavior of this in arrow functions versus regular functions, let vs const scoping rules, and async/await error handling. Those six topics accounted for maybe seventy percent of my lookup time. I put them on the front page. One thing I learned the hard way: the spread operator and Array.from() do not create deep copies. I spent about four hours once debugging a React component where state mutations were causing unexpected re-renders, and the root cause was assuming {...state} would copy nested objects. It doesn't. It does a shallow copy. The workaround was writing a small helper that used structured cloning when the browser supports it, or a recursive merge for older environments. That single note now lives on my cheat sheet under a heading that says "Spread operators are shallow. Period." No explanation needed after that.

Another counter-intuitive thing that beginners miss: typeof null === 'object' isn't a bug in your code. It's a documented quirk in the spec. It goes all the way back to the original JavaScript implementation in 1995. Your cheat sheet should just note it and move on. Same with NaN !== NaN. These aren't tricks to test people on. They're things that will bite you in production if you're writing validation logic and assume equality works the way you expect. The this binding rules are probably the most important section on any JavaScript cheat sheet, and also the one most people handle poorly. Here's the actual rule set in order of precedence: new binding wins, then explicit binding (call, apply, bind), then implicit binding (obj.method()), then default binding. Arrow functions don't participate in any of this. They capture this from the enclosing scope at definition time. If you're inside a class method and your arrow function's this looks wrong, the problem is almost certainly that you defined it in a context where this wasn't what you thought it was. On the async side, the thing that catches people most often is forgetting that async functions always return a Promise, even if you don't explicitly return anything. An empty async function returns Promise {undefined}. If you're building middleware or a chain of validators and one of them is accidentally marked async when it doesn't need to be, you'll end up with Promises wrapping values everywhere and your error handling will break in weird ways. I keep a small note on my sheet: "If you don't use await, don't mark the function async."

For the actual format of the document, I use a two-column layout with the method name on the left and the typical use case plus a one-line example on the right. Anything longer than a single line of example code is too verbose for this kind of reference. The goal is to glance and remember, not to read and learn. If you're reading the cheat sheet to learn something new, you're using it wrong. Go look at MDN for that. The biggest limitation of any cheat sheet is that it becomes stale. JavaScript adds new features every year. Object.hasOwn(), Array.prototype.toSorted(), Promise.any() — these all exist now but most printed cheat sheets don't include them because by the time they go to print, half the content is outdated. My personal sheet lives as a Markdown file in my dotfiles repo and I update it every time I hit a lookup wall. I also keep a separate "deprecated" section for things like document.write, with statements, and let block scoping edge cases that newer developers sometimes encounter in legacy codebases and get confused about. If you want something you can download and print, I'd recommend starting with the MDN JavaScript Reference as a base and stripping it down to your actual lookup patterns over the first two weeks of working with it. The resulting document will be smaller and more useful than anything someone else compiled based on what they thought you'd need. There's no shortcut around knowing what you actually look up. The people who skip that step end up with a fifty-page document they never open.

I host my current version in a public GitHub repo if you want to clone it and adapt it. It's not polished. It has some notes in all caps that are basically just reminders to myself. But it's been through enough real-world debugging sessions to know what actually matters when you're trying to ship code instead of re-reading documentation.