{"id":4854,"date":"2026-08-08T21:07:05","date_gmt":"2026-08-08T15:37:05","guid":{"rendered":"https:\/\/itsupportwale.com\/blog\/10-essential-javascript-best-practices-for-cleaner-code-2\/"},"modified":"2026-08-08T21:07:05","modified_gmt":"2026-08-08T15:37:05","slug":"10-essential-javascript-best-practices-for-cleaner-code-2","status":"publish","type":"post","link":"https:\/\/itsupportwale.com\/blog\/10-essential-javascript-best-practices-for-cleaner-code-2\/","title":{"rendered":"10 Essential JavaScript Best Practices for Cleaner Code"},"content":{"rendered":"

text
\n<— 2024-05-22 03:14:09.442 —>
\nFATAL ERROR: Reached heap limit Allocation failed – JavaScript heap out of memory
\n 1: 0x10505c668 node::Abort() [\/usr\/local\/bin\/node]
\n 2: 0x10505c7e8 node::OnFatalError(char const, char const<\/em>) [\/usr\/local\/bin\/node]
\n 3: 0x1051f49a4 v8::Utils::ApiCheck(bool, char const, char const<\/em>) [\/usr\/local\/bin\/node]
\n 4: 0x105898330 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate, char const<\/em>, bool) [\/usr\/local\/bin\/node]
\n 5: 0x105a563b8 v8::internal::Heap::FatalProcessOutOfMemory(char const) [\/usr\/local\/bin\/node]
\n 6: 0x105a538e0 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [\/usr\/local\/bin\/node]
\n 7: 0x105a6a1a4 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [\/usr\/local\/bin\/node]
\n 8: 0x105a679b0 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [\/usr\/local\/bin\/node]
\n 9: 0x105a59f64 v8::internal::Heap::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [\/usr\/local\/bin\/node]
\n10: 0x105a59fe4 v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [\/usr\/local\/bin\/node]
\n11: 0x105a2747c v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [\/usr\/local\/bin\/node]
\n12: 0x105de4694 v8::internal::Runtime_AllocateInYoungGeneration(int, v8::internal::Object<\/em>, v8::internal::Isolate<\/em>) [\/usr\/local\/bin\/node]
\n13: 0x10617635c Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit [\/usr\/local\/bin\/node]<\/p>\n

\n
## The 03:00 Call from Hell\n\nThe pager didn't just beep; it screamed. It\u2019s 3:14 AM. I\u2019m staring at a terminal window that looks like a crime scene. The log above is the digital equivalent of a massive coronary. Node.js v22.2.0, running V8 engine v12.4, just decided it couldn\u2019t breathe anymore. It reached the heap limit and simply gave up. \n\nI remember when we wrote in C. If you ran out of memory, it was because you were a moron who forgot to call `free()`. Now, we have "Garbage Collection." We have "Automatic Memory Management." We have a generation of developers who think memory is an infinite resource provided by the cloud, like some kind of celestial manna. They\u2019re wrong. Memory is a physical reality. It\u2019s silicon. It\u2019s voltage. And when you treat it like a bottomless pit of abstractions, the pit eventually swallows your production server.\n\nThe application in question is a bloated monstrosity built on Express 4.19.2. It\u2019s supposed to be a "microservice," but it has more dependencies than a Victorian monarch. Every time a request hits the endpoint, the system allocates objects like it\u2019s winning the lottery. Strings, closures, anonymous functions, promises\u2014each one a tiny weight on the scale. At 3:00 AM, the scale tipped.\n\n## The Autopsy of a Bloated Heap\n\nI pulled the heap dump. It\u2019s 1.4GB of pure, unadulterated failure. When you look at a heap dump from a modern Node.js app, you don\u2019t see data structures. You see a graveyard of "Hidden Classes" and "Shapes." V8 tries so hard to optimize this dynamic mess, but it can\u2019t save us from ourselves.\n\nIn V8 v12.4, the engine uses pointer tagging. It tries to squeeze small integers (Smis) into the pointer itself to save space. But everything else? Everything else is a `HeapObject`. And in this dump, I see millions of them. Not thousands. Millions. Most of them are strings. Why? Because some "architect" decided that every single log entry should be buffered in memory before being batched to a third-party provider that was currently experiencing 500ms of latency.\n\nThe garbage collector (GC) was working overtime. I can see the cycles in the metrics. Scavenge after scavenge in the Young Generation (New Space). Then, the Mark-Sweep-Compact cycles in the Old Space. The GC was burning 90% of the CPU just trying to find a single byte of free space. This is what happens when you ignore the fundamentals of how memory is actually laid out. You get fragmentation. You get "Stop-the-World" pauses that turn your "high-performance" event loop into a frozen glacier.\n\n```javascript\n\/\/ THE CRIME: A "middleware" written by someone who thinks RAM is free.\n\/\/ This was found in our Express 4.19.2 stack.\napp.use((req, res, next) => {\n    const requestData = {\n        headers: req.headers,\n        method: req.method,\n        url: req.url,\n        timestamp: Date.now(),\n        \/\/ The "Genius" Move: Capturing the entire request body in a closure\n        \/\/ for "potential" future logging that never happens.\n        context: () => {\n            return `Request to ${req.url} at ${new Date().toISOString()}`;\n        }\n    };\n\n    \/\/ Pushing to a global array for "batching"\n    global.requestTracker.push(requestData); \n\n    res.on('finish', () => {\n        \/\/ Theoretically, we clean up here. \n        \/\/ But wait... if the connection drops, does this always fire?\n        \/\/ Spoilers: No.\n        if (global.requestTracker.length > 10000) {\n            flushToAnalytics(global.requestTracker);\n            global.requestTracker = [];\n        }\n    });\n    next();\n});\n<\/code><\/pre>\n
The code above is a textbook example of why we can’t have nice things. It\u2019s a memory leak disguised as a feature. The context<\/code> function is a closure. It captures the req<\/code> object. Even if requestData<\/code> is small, it keeps the entire req<\/code> object\u2014and everything attached to it\u2014alive in memory until that closure is garbage collected. But the closure is inside an object, which is inside a global array. The GC can’t touch it. It\u2019s a hostage situation.<\/p>\n
\n
Table of Contents<\/p>\n