Avoid new Number(), new String(), new Boolean() in JavaScript

Why You Should Avoid Using new Number(), new String(), and new Boolean() in JavaScript In JavaScript, there is an important distinction between primitive values and object wrappers. Consider the following example: let a = 3; // primitive number let b = new Number(3); // Number object console.log(a == b); // true (type coercion) console.log(a === b); // false (different types) This inconsistency occurs because new Number(), new String(), and new Boolean() create objects, not primitive values. Although they appear similar, they can cause subtle and hard-to-detect bugs in equality checks and logical comparisons. Common Issues Confusing equality checks (== vs ===) Unintended behavior in conditionals or truthy/falsey evaluations Inconsistent data handling across the codebase Recommended Best Practices Always use literals or function calls for primitive values: // Correct usage let x = 3; let y = "Hello"; let z = true; // Safe conversions Number("3"); // → 3 (primitive) String(123); // → "123" Boolean(0); // → false Use constructors like Date, Array, Object, and Function only when you intend to create objects. For Working with Dates Instead of relying solely on the Date object, consider modern and reliable alternatives: Intl.DateTimeFormat for formatting Temporal API (in modern JavaScript runtimes) for date and time arithmetic Key Takeaway If you encounter new Number(), new String(), or new Boolean() in your codebase, it is often a sign of a potential bug. Use literals for primitives, and reserve constructors for actual objects. #JavaScript #WebDevelopment #SoftwareEngineering #ProgrammingBestPractices #CleanCode #FrontendDevelopment #NodeJS #TypeScript #Developers

To view or add a comment, sign in

Explore content categories