Explain Codes LogoExplain Codes Logo

Create an empty object in JavaScript with {} or new Object()?

javascript
object-literals
object-constructors
javascript-best-practices
Anton ShumikhinbyAnton Shumikhin·Feb 3, 2025
TLDR

Choose {} over new Object() for crafting empty objects, thanks to its simplicity and slight performance edge.

Example:

let theForce = {}; // Just like the force, less is more.
  • {}: More Starfleet, less Star Wars (concise, fast, resource-friendly).
  • new Object(): Same power but avoid unless you're opting for a more "epic" journey.

Understanding creation of JavaScript objects: {} vs new Object()

JavaScript provides two routes for declaring objects, let's understand why you might favor {} (object literal) over new Object() (object constructor).

Object Literals vs. Object Constructors: The Showdown

{} is a no-nonsense approach to object creation; it's concise, leads to clean code, and skilfully avoids the potential sinkholes that new Object() may bring along. Here is a breakdown of the difference:

  • {}: It's like getting a brand new, empty canvas. Clean, uncluttered, ready to be painted upon.
  • new Object(): Picture a canvas with fine print instructions. Perfectly fine, but can be confusing even to seasoned da Vincis.

Array Literals vs. Array Constructors: Who Wins?

Likewise, [] (array literal) offers a swift way to create an empty array while new Array() (array constructor) can lead to unexpected operations. For instance, new Array(100) does not conjure an array with 100 items, but rather an array with 100 undefined slots. Handy for pre-sized arrays, but easy to trip over:

  • []: Like getting a new wardrobe <del>for Narnia</del> with empty hangers, ready to be filled.
  • new Array(100): Like getting a 100-slot shoe rack and promptly forgetting where you kept the shoes!

Performance, Maintenance and, Well, Sanity

The performance difference between literals and constructors is barely perceivable, but the impact on readability and maintainability stands out like a neon sign. Concise and clear code makes the reader happy and keeps the code gremlins at bay.

  • {} and []: in most scenarios, choosing literal syntax keeps your code predictable, reduces keystrokes, and avoids unnecessary complexities.

Niche scenarios for constructors, because we love being inclusive!

While object and array literals are generally recommended, there exist cases where constructors have a chance to shine. Let's shed some light on those scenarios:

Round 1: new Object() on the stage

  • Creating objects with a different prototype chain? Use Object.create(proto).
  • Dynamically creating properties based on certain conditions? new Object() is here to save the day.

Round 2: new Array() grabs the mic

  • Planning to create a pre-sized array? Use new Array(length).
  • Working with array-like objects and want to use fancy array methods? Array.from() will make your life easier.

The right tool (syntax) for the right job

{ }

  • The default go-to for an empty object.
  • Creating JSON-like structures? {} won't let you down!
  • Perfect for crafting inline objects for function arguments and returns.

new Object()

  • Rare and specific cases, but usually avoided, to keep the code epoch relevant!

[ ]

  • Your friendly, neighborhood empty array.
  • Ideal for quick manipulation with array methods.
  • Helps filling with data using loops or array methods.

new Array()

  • Predefining array lengths (pre-sized empty buffers).

Trudging through the nitty-gritty of JavaScript Objects

Sometimes, your JavaScript journey might take you into the less-travelled paths. Here are some subtleties and edge cases for your travel kit:

  • {} can have more going on than just an empty object. They might include pre-populated data.
  • new Object() might trick you into creating unexpected types based on the arguments passed. Like new Object(42) resulting in a Number wrapper object rather than an object, kind of like expecting a donut but ending up with just the hole!
  • Object constructors might have performance overhead as they handle various internal operations, though largely insignificant with modern JavaScript engines.

Moral of the story, take the road most traveled, i.e., stick to literals unless there's a specific reason to opt for constructors.