JavaScript Mistakes That Will Bite You in Production
I've spent years watching developers make the same stupid errors, often repeatedly. The language has enough gotchas that you can shoot yourself in the foot without thinking about it. Here's the practical breakdown of what trips people up and how to stop doing it. 1. Loose equality (==) instead of strict equality (===) This is the most common mistake I see, even from people who claim to know JavaScript well. The == operator does type coercion, which means "1" == 1 is true, [] == false is true, and null == undefined is true. None of these are particularly intuitive.
I had a production bug where a price field was being compared with == and the API was returning the price as a string like "49.99". The comparison failed silently in half the cases because sometimes the value came through as a number, sometimes as a string. Switching to === caught the issue immediately. The fix wasn't just changing the operator, though. I had to also add an explicit type conversion at the source, because treating prices as numbers from the API was the real problem. Your linter should have a rule for this. ESLint's eqeqeq rule will flag every instance. Configure it to enforce strict equality. 2. Mutating state directly in React setState in React doesn't merge deeply. If you have an object with nested properties and you mutate one directly, React won't re-render because the reference hasn't changed. The same issue happens with Redux reducers if you modify the state object instead of returning a new one.
I once spent four hours debugging a component that refused to update after a form submission. The reducer was doing something like state.users[userId].name = newName inside the case block instead of spreading the new values into a fresh object. The fix was replacing the mutation with proper immutable updates using the spread operator. State should always be treated as read-only. Create new copies instead. 3. Async/await without error handling Forgetting to wrap async calls in try/catch blocks is dangerous. Unhandled promise rejections can crash your entire application in Node.js and cause silent failures in browsers. Even worse, they're easy to miss during testing because they don't throw synchronously.
The pattern I use everywhere now is wrapping async operations in try/catch and logging the error properly. In browser apps, I also added a global unhandledrejection listener that reports to our monitoring service. This caught a case where an authentication token refresh was failing silently for three days before anyone noticed. The token was expiring, the retry logic wasn't in place, and the error was being swallowed somewhere in the call chain. 4. Using index as a React key When you map over an array and use the array index as the key prop, React's reconciliation process can produce unexpected results. The problem becomes obvious when the list can be reordered, filtered, or have items removed. The keys no longer match the actual data, and components can render with stale props.
I saw a checklist app where deleting an item would cause the wrong input field to clear. The keys were indices, so after a deletion, the remaining items shifted and their keys no longer corresponded to the right data. Using a stable unique identifier from the data itself fixed it completely. If your data doesn't have a unique ID, generate one server-side. UUID v4 or a database auto-increment are both fine. 5. Not understanding JavaScript's scoping rules JavaScript has function scope with var and block scope with let and const. This distinction matters more than people think. A variable declared with var inside a loop is hoisted to the function level, which causes closure-related bugs.
The classic example is setting up event listeners in a loop with var. All the handlers end up referencing the same final value of the loop variable. I ran into this when building a tab interface where clicking any tab opened the wrong panel. Switching to let for the loop variable fixed it because each iteration got its own binding. Also, prefer const by default and use let only when you need to reassign. It removes an entire class of accidental mutations. 6. Assuming typeof null is "object" typeof null returns "object". This is a known bug in JavaScript that has been around since the language was created. It's not a feature and it's not going to be fixed because it would break too much existing code. You need to account for it.
Before checking the type of a value, check for null explicitly. Something like value !== null && typeof value === "object". This comes up most often when you're writing utility functions that handle multiple data types. A single unchecked typeof call will misidentify null values and crash downstream code that expects an actual object. 7. Misusing the this keyword this in JavaScript is determined by how a function is called, not where it's defined. Arrow functions don't have their own this binding, which means they inherit it from the surrounding scope. Regular functions get their this from the call site. This difference breaks code when you pass a regular function as a callback.
I had a class method that used setInternalTimeout in the constructor and it stopped working after a refactor. The method was being passed as a callback to setTimeout, and by that point this was no longer pointing to the class instance. The fix was either converting the method to an arrow function or binding it explicitly in the constructor. I chose arrow functions because they're cleaner and the binding is implicit. If you're using class fields, this approach works consistently across modern environments. 8. Ignoring floating point precision 0.1 + 0.2 does not equal 0.3 in JavaScript. It equals 0.30000000000000004. This is because JavaScript uses IEEE 754 double-precision floating point numbers, and some decimal fractions cannot be represented exactly in binary. Financial calculations are especially vulnerable.
For anything involving money, convert to cents and work with integers. Use libraries like decimal.js or big.js for precision arithmetic. I learned this the hard way when a checkout total was off by a penny on about one in every hundred transactions. The discrepancy came from accumulating floating point errors across multiple line items. Switching to integer-based cents resolved it entirely. 9. Not debouncing or throttling event handlers Event handlers like scroll, resize, and input can fire dozens or hundreds of times per second. Running expensive operations inside these handlers without limiting the frequency will make your application feel sluggish. The difference between a smooth page and a jerky one often comes down to whether you're debouncing or throttling correctly.
I once built a search feature that sent an API request on every keystroke. The server was getting hammered and the user experience was terrible because results were flashing in and out faster than anyone could read them. Adding a debounce with a 300-millisecond delay reduced the request count dramatically and made the interface feel responsive. Throttling is better for events like scroll where you want periodic execution rather than waiting for a pause. 10. Forgetting that Array methods mutate by default Some array methods like splice, sort, and reverse modify the original array and return a reference to it. Other methods like map, filter, and slice return new arrays. Mixing these up leads to subtle bugs where data gets mutated unexpectedly.
The sort method is particularly dangerous because it sorts in place and returns the same array reference. If you're sorting data that's being used elsewhere, you'll mutate the original. Always create a copy first with the spread operator or slice before sorting. Same goes for reverse. These methods are convenient but they change the source data without any warning in the return value.
Get the Full Details
