277 JavaScript Frontend Developer Interview Questions & Answers

JavaScript uses a default parameter when the argument is omitted or its value is explicitly undefined. It does not use the default for null, an empty string, zero, or false. The default expression is evaluated when the function is called and only when that parameter needs the default. A later default parameter can also reference an earlier parameter because parameters are initialized from left to right.

A default parameter gives a function a value to use when the caller does not provide that argument. JavaScript also uses the default when the caller explicitly provides undefined. Other supplied values stay unchanged. For example, null stays null, and an empty string stays an empty string. The default value is worked out when the function is called, not once when the function is created. This makes default parameters useful when a function has a normal value that most callers should not need to provide.

1. Should I explain how null and an empty string differ from undefined?
2. Should I also show how an earlier parameter can be used by a later default expression?

With formatPrice(amount, currency = 'USD'), calling formatPrice(20) makes currency equal to USD because the second argument is omitted. Calling formatPrice(20, undefined) gives the same result because an explicit undefined also activates the default.

Calling formatPrice(20, null) is different. JavaScript keeps null, so the default expression does not run. Calling formatPrice(20, '') also keeps the empty string. The rule is specific: only an omitted argument or a value of undefined activates the parameter default.

A default expression is evaluated during the function call when that parameter needs a default. It is not calculated once when the function is defined. This matters if the expression calls another function, reads changing state, or creates a new object. The expression can therefore produce a new result on each call that needs it.

Parameters are initialized from left to right. A later default expression can use an earlier parameter. For example, function createLabel(amount, text = String(amount)) can use amount while creating the default value for text. The reverse is not safe. Trying to read a later parameter before that later parameter has been initialized causes a ReferenceError.

Default parameters are useful for optional settings with a sensible normal value. In production code, do not rely on them when null, an empty string, zero, or false should also mean missing. Handle those cases explicitly inside the function.

The example uses formatPrice(amount, currency = 'USD'). Omitting the second argument and passing undefined both make currency use USD. Passing null keeps null. Passing an empty string keeps the empty string. The second function shows initialization order by letting a later default expression read an earlier parameter. Default expressions are evaluated during each function call only when the corresponding parameter receives no argument or receives undefined.

A common mistake is thinking every falsy value activates a default parameter. That is incorrect. Null, an empty string, zero, and false are preserved. Another mistake is thinking the default expression is calculated when the function is defined. It is evaluated during a function call when that parameter needs the default. Candidates may also forget that parameters are initialized from left to right. A later default can use an earlier parameter, but trying to read a later parameter before it has been initialized causes a ReferenceError.

State the main rule first: an omitted argument and undefined use the default, while null and other supplied values do not. Then compare the four formatPrice calls. Finish by explaining that default expressions run during the call and that a later default expression can reference an earlier parameter.

I use arrow functions mainly for callbacks and other cases where I want this to come from the surrounding scope. I use regular functions when the caller should determine this or when I need an arguments object or constructor behavior. Arrow functions do not create their own this or arguments binding, cannot be called with new, and do not have a prototype property for constructing instances. Their concise expression body can make a simple callback easier to read without changing the result.

The practical difference is about how each kind of function gets information and how it can be called. One kind can receive its object context from the call itself. The other keeps the context from the place where it was created. This matters when a function is used as an object method, passed as a callback, or used to create an object. The shorter form is often convenient for small callbacks, but it cannot replace the regular form in every case. Choosing the right form prevents unexpected values and invalid constructor calls.

1. Should the object method use the object as its this value?
2. Should the callback keep this from its surrounding function?
3. Does the function need to support calls with new?

A regular function gets its this value from how it is called. For example, if obj.show() calls a regular function stored as show, this normally refers to obj. An arrow function does not create its own this binding. It reads this from the surrounding lexical scope. Because of that, an arrow is usually a poor choice for an object method when the method needs this to refer to the object receiving the call.

This same behavior is useful for callbacks. An arrow callback can keep the this value of its surrounding function without bind or a saved variable.

A regular function also receives its own arguments object when it is called. An arrow function does not create an arguments binding. If an enclosing regular function has arguments, the arrow can read that outer binding. In modern code, rest parameters such as (...args) are usually clearer when an arrow needs a list of supplied values.

Arrow functions are never constructable, so calling one with new throws a TypeError. They also do not have their own prototype property. An ordinary function declaration or function expression is normally constructable and has a prototype property. However, not every non arrow function is constructable. For example, method definitions in object literals and classes cannot be called with new and do not have a prototype property for construction.

For a simple expression, an arrow can return the expression without writing return. For example, x => x * 2 returns the calculated value. This changes the syntax, not the result of the calculation. It is useful when the shorter form is easier to read.

The example uses one object to show how this differs, one regular outer function to show an arrow callback keeping the surrounding this value, and constructor checks to show constructability and prototype behavior. The regular object method receives the object as this because it is called through that object. The arrow method does not get a new this binding from the method call. The regular function receives its own arguments object, while the arrow callback uses a rest parameter. An ordinary function declaration can be called with new and has a prototype property. The arrow constructor attempt throws a TypeError and the arrow has no own prototype property.

A common mistake is thinking an arrow function is only shorter syntax for a regular function. Another mistake is using an arrow as an object method and expecting this to refer to the object that made the call. Developers may also expect an arrow to create its own arguments object, even though it can only read an outer arguments binding if one exists. Another mistake is calling an arrow with new or expecting it to have its own prototype property. It is also incorrect to assume every regular looking function is constructable, because object and class method definitions cannot be called with new.

Start with lexical this because it is the most important practical difference. Then mention arguments, new, and prototype. Also point out that ordinary function declarations can be constructors, while object and class method definitions are not constructable. Finish by explaining that concise arrow bodies are mainly a readability choice.

The iterator protocol is the standard rule JavaScript uses to read values one at a time. An iterable provides a Symbol.iterator method that returns an iterator. The iterator has a next method that returns an object with value and done. Features such as for...of, spread, and array destructuring call these methods automatically. An iterator can also provide return so it can clean up resources when a consumer stops early.

The main idea is that an object can provide its items one at a time instead of creating every item first. Each request gives the next item or says that there are no more items. This lets common language features read the same object in a predictable way. We can build an object that produces the numbers 1, 2, and 3. We should also understand what happens when reading reaches the end and what may happen when the reader stops before all three values have been read.

1. Should I show a custom object that produces a fixed sequence of values?
2. Should I also demonstrate cleanup when a loop stops early?

An object is iterable when it has a method stored at Symbol.iterator. JavaScript calls that method to get an iterator. The iterator must have a next method.

Each call to next returns an object. While a value is available, it can return { value: 1, done: false }. When the sequence has finished, it can return { done: true }. The value property is optional when done is true.

In this example, Symbol.iterator creates fresh iteration state by starting a counter at 1. This matters because separate consumers should normally be able to iterate independently. The next method returns 1, then 2, then 3, and then reports completion.

A for...of loop gets the iterator and repeatedly calls next until done becomes true. Spread also consumes the iterator until completion and puts the produced values into a new array. Array destructuring requests only the values it needs. If destructuring stops before the iterator is finished, JavaScript closes the iterator and calls its return method when that method exists and is callable.

A break from for...of also closes an unfinished iterator. This lets an optional return method perform cleanup. Normal completion does not call return just because iteration reached done.

Custom iterables are useful when an object naturally represents a sequence. They can produce values only when requested, so a complete result array does not have to exist first. However, spread still creates a new array containing every produced value. The iterator protocol here is synchronous. Asynchronous sequences use the async iterator protocol instead.

The example creates an iterable object whose Symbol.iterator method creates fresh state for each consumer. The iterator keeps a current number. next returns 1, 2, and 3 with done set to false, then returns done set to true. The optional return method records that early cleanup happened and returns done set to true. Spread demonstrates normal full consumption. The for...of loop demonstrates early termination with break, which closes the unfinished iterator and calls its return method.

A common mistake is returning an object from Symbol.iterator that does not provide the required next method. Another mistake is returning raw values from next instead of result objects containing value and done. Developers may also keep one shared position on the iterable itself, which can make separate consumers interfere with each other. Another misunderstanding is assuming return runs after every successful iteration. It is used during iterator closing when consumption stops before normal completion, not simply because next eventually returned done.

Start with the contract: Symbol.iterator returns an iterator, and next returns an object with value and done. Then explain one concrete sequence such as 1, 2, and 3. Finally mention that for...of, spread, and destructuring consume the protocol automatically, and that return can support cleanup when consumption stops early.

JavaScript first tries Symbol.toPrimitive when an object must become a primitive. It passes a hint such as default, number, or string. If that method is absent, ordinary conversion tries valueOf before toString for a number hint, and toString before valueOf for a string hint. The plus operator normally starts with a default hint, while relational comparison uses a number hint. After primitive conversion, the operator continues with the primitive values it received.

JavaScript sometimes needs a simple value from an object before it can perform an operation. For example, an object may appear beside text, beside a number, or inside a comparison. JavaScript then asks the object for a simpler value. The object can control what value it gives back. The exact method that runs depends on the kind of conversion JavaScript needs. This is why the same object can behave differently in different expressions. Understanding the order helps you predict results and avoid surprising behavior in real code.

1. Should I explain both Symbol.toPrimitive and the valueOf and toString fallback behavior?
2. Would you like me to trace the exact calls for plus and relational comparison?

JavaScript uses the abstract ToPrimitive operation when an object must become a primitive value.

First, JavaScript looks for object[Symbol.toPrimitive]. If that property exists and is callable, JavaScript calls it with a hint. The hint is "default", "number", or "string". The method must return a primitive value. If it returns an object, JavaScript throws a TypeError.

If Symbol.toPrimitive is absent, JavaScript uses ordinary conversion. With a number hint, it tries valueOf first and then toString. With a string hint, it tries toString first and then valueOf. JavaScript stops as soon as one of those methods returns a primitive.

For most ordinary objects, a default hint is handled like a number hint during this fallback. Some built in objects can have special default behavior, so it is safer to describe the default hint separately from the number hint.

The plus operator asks object operands for primitives using the default hint. After that conversion, if either primitive is a string, plus performs string concatenation. Otherwise it performs numeric addition after numeric conversion. So an expression such as object + " items" does not request a string hint merely because the other operand is a string.

A relational comparison such as object < 20 requests primitive conversion with a number hint before comparing the resulting values.

Explicit String(object) requests string oriented primitive conversion. Explicit Number(object) requests number oriented primitive conversion.

In production code, custom coercion should be used carefully. Symbol.toPrimitive is useful when a value object intentionally needs controlled conversion behavior. Explicit conversion is often easier to read because another developer can see the intended type directly.

The example uses one observable object so every conversion method records when it runs. While Symbol.toPrimitive exists, JavaScript calls it before valueOf or toString. String(probe) passes the string hint. probe + 5 passes the default hint because plus requests default primitive conversion. probe < 20 passes the number hint. The example then removes Symbol.toPrimitive to expose ordinary fallback behavior. Number(probe) uses the number hint, so valueOf runs first. String(probe) uses the string hint, so toString runs first. Finally, probe + " items" uses the default hint. For this ordinary object, fallback treats that default like a number hint, so valueOf returns 10 and the final operation produces the string "10 items".

A common mistake is saying that plus asks an object for a string whenever the other operand is a string. It does not. Plus first requests primitive conversion with the default hint, then decides whether to concatenate after it has primitive values. Another mistake is saying valueOf always runs before toString. A number hint tries valueOf first, while a string hint tries toString first. Candidates also sometimes forget that Symbol.toPrimitive has priority over both fallback methods. Another important mistake is returning an object from Symbol.toPrimitive. That method must return a primitive, or JavaScript throws a TypeError.

Start with Symbol.toPrimitive because it has first priority. Then state the fallback orders clearly. A number hint tries valueOf and then toString. A string hint tries toString and then valueOf. Next, explain that plus uses the default hint and relational comparison uses the number hint. Finish with one observable example so the interviewer can see that you understand the exact call sequence.

A normal method does not permanently remember its object as this. If I pass panel.open directly to an event listener, the browser later calls that function as the listener, so this comes from that callback invocation and is not the panel object. I can use an arrow wrapper that calls panel.open() or use panel.open.bind(panel). If I use bind, I keep the returned function so I can pass that exact same reference to removeEventListener.

Passing a method by itself means we give another part of the program the function, but not the object that normally calls it. Later, the event system calls that function in its own way. Because of this, the method may see a different object when it tries to use this. Two common fixes are to put the method call inside an arrow function or to create a bound function that always uses the intended object. A bound function should be saved because removing an event listener requires the same function value that was originally added.

1. Should I compare direct method passing, an arrow wrapper, and bind using a browser event listener?
2. Should I also explain how to correctly remove the bound listener?

The key rule is that a normal JavaScript function gets its this value from the way it is called. Lexical scope does not preserve this for a normal function. The place where the function was written does not permanently attach a this value to it.

Suppose panel.open() reads this.name. When we call panel.open(), the call has panel before the dot, so this is panel.

If we instead pass panel.open to addEventListener, we pass only the function value. When the browser later invokes a normal event listener, it calls the listener with the event current target as this. In this example, that is the button, not panel.

An arrow wrapper such as () => panel.open() fixes the problem because the wrapper explicitly performs panel.open(). That method call makes panel the receiver. Arrow functions have lexical this, meaning they do not create their own dynamic this, but this example does not depend on the wrapper's this. It works because the wrapper calls open through panel.

Another option is panel.open.bind(panel). bind creates a new function whose this value is fixed to panel when that function runs.

The important production detail is function identity. Every call to bind creates a different function object. Calling removeEventListener with a newly created bound function will therefore not remove the original listener. Store the bound function and reuse the same reference. The same rule applies to an arrow wrapper if that listener must later be removed.

The example creates one panel object and three buttons. The direct listener receives panel.open by itself, so the browser invokes that normal listener with the button as this. The arrow listener explicitly calls panel.open(), so the method receives panel as this. The bound listener uses a function created once with panel.open.bind(panel), which fixes this to panel. The bound function is stored and the exact same reference is later passed to removeEventListener. A new call to bind would create a different function and would not remove the original listener.

A common mistake is thinking that panel.open remembers panel because the method was defined on that object. A normal function does not work that way. Another mistake is saying that lexical scope preserves the this value of a normal method. Lexical scope preserves normal variable bindings, while a normal function's this depends on how the function is invoked. Another common bug is adding panel.open.bind(panel) and later trying to remove it with another panel.open.bind(panel). Those are different function objects, so the listener remains registered. Inline arrow wrappers have the same reference problem when cleanup is required.

Start with the call site rule: a normal function gets this from how it is called. Then compare panel.open, () => panel.open(), and panel.open.bind(panel). Finish by mentioning that bind creates a new function, so the same stored reference must be used for listener removal.

A copy is shallow when only the outer object is new while nested objects still refer to the same objects as the original. Object spread and Object.assign make shallow copies. structuredClone is a browser API that creates independent nested values for supported data and preserves relationships such as two properties pointing to the same cloned child. A JSON round trip can create independent plain data, but it changes or loses some JavaScript types and cannot handle cycles.

A shallow copy gives you a new outer container, but some values inside it still belong to the original data. If a nested list or child object changes through one copy, the other can see that change too. A deep copy creates separate nested values, so later changes do not affect the original. The choice matters when data contains dates, maps, repeated references, cycles, or functions, because each copying method handles these values differently. The key question is whether nested values keep sharing the same underlying objects or become independent copies.

1. Should the copied value support cycles and shared references?
2. Do Date and Map values need to keep their original types?
3. Should functions be copied, rejected, or kept by reference?

Object spread and Object.assign copy the source object's own enumerable properties into a new outer object. Primitive values are copied directly. For an object valued property, the copied value is a reference to the same nested object. That is why the result is shallow.

Suppose the source contains a nested array, a Date, a Map, and one child object referenced by both left and right. After using object spread or Object.assign, the outer object has a new identity, but the nested array, Date, Map, and shared child still have the same identities as in the source. left and right still point to the same child.

In evergreen browsers, structuredClone is a browser API that uses the structured clone algorithm. It creates new nested objects, arrays, Date values, and Map values for supported data. A Date remains a Date. A Map remains a Map. If left and right originally reference the same child, both properties in the clone reference the same new cloned child. The clone does not share that child with the original. Cyclic references are also preserved. Ordinary functions are not supported, so structuredClone throws a DataCloneError when it reaches one.

A JSON round trip using JSON.stringify followed by JSON.parse can create separate nested plain data, but it is not a general deep clone. Date values become strings. Map values normally become empty plain objects unless custom conversion is provided. Repeated references lose their shared identity because each occurrence is serialized separately. Cycles make JSON.stringify throw a TypeError. Function valued object properties are omitted during serialization.

In production, object spread or Object.assign is useful when only the outer level needs to change and nested sharing is intentional. structuredClone is useful when supported nested data must be independent. A deep clone can take more time and memory because it must visit and allocate nested values.

The example creates one source object containing a nested array, a Date, a Map, and one shared child referenced by two properties. Spread and Object.assign create new outer objects but keep the original nested identities. structuredClone creates independent supported nested values while preserving the fact that left and right refer to one shared child inside the clone. The JSON round trip creates separate plain data, converts the Date to a string, turns the Map into an empty plain object with normal serialization, and does not preserve the shared child identity. Separate checks show that structuredClone supports cycles but rejects ordinary functions, while JSON serialization rejects cycles and omits function valued object properties.

A common mistake is thinking that a new outer object means every nested value is also new. Another is calling object spread or Object.assign a deep copy. Some developers also use a JSON round trip as a universal clone and forget that Date, Map, shared identity, cycles, undefined values, and functions do not behave like ordinary JSON data. Another mistake is assuming structuredClone is part of the ECMAScript language or that it can clone every JavaScript value. In browsers it is a Web API, and ordinary functions are not supported.

Start by comparing identity. Say that spread and Object.assign create a new outer object but reuse nested object references. Then explain that the browser structuredClone API creates new supported nested values and preserves internal relationships. Finish by explaining why a JSON round trip is only suitable for simple JSON shaped data.

The new operator creates a fresh object, chooses its prototype from the constructor, calls the constructor with that new object as this, and then decides what value to return. If the constructor returns an object or function, that value replaces the fresh object. If it returns nothing or returns a primitive value, JavaScript returns the fresh object. The target must also be constructable. For example, an arrow function cannot be used with new.

The main idea is that new creates an object by following a fixed set of steps. JavaScript prepares a fresh object and connects it to an object used for shared behavior. It then runs the constructor while making the fresh object the current object. What the constructor returns can change the final result. Returning no value keeps the fresh object. Returning a simple value also keeps it. Returning another object replaces it. JavaScript also requires the value after new to support object construction. If it does not, JavaScript reports an error instead of creating an instance.

1. Should I explain both constructor functions and classes?
2. Would you like me to show the return value rule with a small code example?

For new Constructor(arg), JavaScript first checks that the target can be used as a constructor. If it is not constructable, new throws a TypeError.

For a constructable target, JavaScript creates a fresh ordinary object. Its prototype is normally taken from Constructor.prototype. If that property is an object, the fresh object uses it as its prototype. If that property is not an object, JavaScript uses the appropriate default intrinsic prototype instead.

Next, JavaScript runs the constructor with the fresh object as this. The arguments in the new expression are passed to the constructor. For example, this.name = name adds a name property to the fresh object.

JavaScript then applies the constructor return rule. If the constructor finishes without an explicit return value, the fresh object is returned. If it explicitly returns a primitive value such as a number, string, boolean, symbol, bigint, null, or undefined, that value does not replace the fresh object. If it returns an object or function, that returned value becomes the result instead.

So a constructor that sets this.name and returns nothing produces the fresh instance. A constructor that returns 42 still produces the fresh instance. A constructor that returns { replacement: true } produces that replacement object instead.

This behavior matters in production when working with classes, constructor functions, prototype methods, inheritance, libraries, and older frontend code. The construction itself has no useful single asymptotic complexity because the constructor can perform arbitrary work. The main allocation is the new object, unless the constructor returns another object instead.

The example uses three constructable functions. ReturnsNothing stores a name on this and has no explicit return value, so new returns the fresh instance. ReturnsPrimitive stores a name and returns the number 42. JavaScript ignores that primitive result and still returns the fresh instance. ReturnsObject stores a name and then returns another object, so that returned object replaces the fresh instance. The example also uses an arrow function to show that a nonconstructable target causes new to throw a TypeError.

A common mistake is saying that new always returns whatever the constructor returns. That is false because primitive return values are ignored. Another mistake is forgetting that the fresh object's prototype normally comes from the constructor's prototype property. Candidates may also assume that every function can be used with new. Arrow functions are callable but not constructable. Another mistake is assuming that changes made through this must appear in the final result even when the constructor explicitly returns another object. It is also incorrect to treat null as an object return for this rule. Returning null does not replace the fresh instance.

Explain the behavior in order: verify the target is constructable, create the object, choose its prototype, call the constructor with that object as this, then apply the return rule. Give the three requested cases next: no return value, primitive return value, and object return value. Finish by mentioning that a nonconstructable target causes a TypeError.

Static fields and static initialization blocks run when JavaScript evaluates the class definition, not when an instance is created. They run once for that class evaluation and in the order they appear. The base class is already evaluated before the subclass static elements run. Static methods are inherited, and this inside a static method depends on which constructor receives the call. Creating objects with new does not run static initialization again.

Static values belong to the class itself instead of each object created from the class. JavaScript creates these values while it creates the class. It processes them from top to bottom. A child class is created after its parent class is available. The child can also access class level values and functions from its parent. Creating a normal object later does not repeat this class setup. This matters when a program needs shared settings, counters, registration information, or setup work that should happen once when a class definition is evaluated.

1. Should I explain both a base class and a subclass?
2. Should I include how this behaves inside an inherited static method?

A static field initializer runs while JavaScript evaluates the class definition. A static initialization block also runs during that class evaluation. Static fields and static blocks are processed in source order, so a later static element can observe values or changes produced by an earlier static element.

For a base class, its static elements finish while that class is being evaluated. When JavaScript evaluates a subclass, the base class constructor already exists. JavaScript then processes the subclass static elements in their own source order. This gives a clear sequence: base class setup first, then subclass setup.

Static properties and static methods can be inherited through the relationship between constructor objects. If Base defines a static method named record, Child can call Child.record(). Inside that call, this is Child because Child is the receiver of the call. If Base.record() is called, this is Base.

Inside a static field initializer or static block, this refers to the class constructor currently being initialized. This makes it possible to compute class level values or record initialization work.

Creating an instance with new Child() does not evaluate the class definition again. Instance construction runs the constructor and initializes instance fields, but it does not rerun static fields or static blocks. Static initialization runs again only when JavaScript evaluates a separate class definition again.

A practical limitation is shared mutable state. If a static field contains an object or array and a subclass inherits access to it, both classes may refer to the same object unless the subclass defines its own static value. Production code should control such mutations carefully.

The example records the order in which static elements run. Base first creates its log, then its name label, then its computed name, and then its static block records that Base initialization happened. Child is evaluated afterward. Its static field and static block then run. Child inherits the Base static method named record. Calling Child.record uses Child as this, while calling Base.record uses Base as this. Because Child inherits the same log array and does not define its own log, changes made through Child are visible through Base.log as well. Constructing Base or Child instances afterward does not add static initialization entries because static elements are not part of instance construction.

A common mistake is saying static initialization runs when the first object is created. It actually runs when the class definition is evaluated. Another mistake is assuming every new instance reruns a static block. It does not. Candidates also sometimes think an inherited static method always uses the base class as this. The receiver matters, so Child.record() uses Child as this. Another mistake is forgetting that an inherited static object can still be the same object owned by the base class. Mutating that object through the subclass can therefore affect what the base class sees.

Start by saying that static fields and static blocks run during class evaluation, not during new. Then explain source order, base class before subclass, and the receiver rule for this in static methods. Use one small execution log to show the behavior clearly.

===, Object.is, and SameValueZero are almost the same, but NaN and signed zero show their differences. === says NaN is not equal to itself and treats positive zero and negative zero as equal. Object.is says NaN equals itself and distinguishes positive zero from negative zero. SameValueZero says NaN equals itself but treats both zero signs as equal. Set and Array.prototype.includes use SameValueZero. For objects, all three compare identity, so two separate objects with the same contents are not equal.

JavaScript has several rules for deciding whether two values should count as the same. Most ordinary values give the same result with all three rules, but two unusual number cases behave differently. One case is NaN, which represents a numeric result that is not a normal number. The other case is zero, because JavaScript can preserve a positive sign or a negative sign on zero. Objects are also important because JavaScript checks whether two values refer to the same object, rather than checking whether their contents merely look the same.

1. Would you like me to compare the important cases with a small code example?
2. Should I also explain how Set and Array.prototype.includes use SameValueZero?

Start with the practical rule. Use === for normal strict comparisons. Use Object.is when the exact behavior of NaN or signed zero matters. Remember that Set and Array.prototype.includes use SameValueZero.

For ordinary primitive values, all three relations usually agree. For example, the primitive strings "hello" and "hello" compare as equal with ===, Object.is, and SameValueZero.

The first important case is NaN. NaN === NaN is false. Object.is(NaN, NaN) is true. SameValueZero also treats NaN as equal to itself. This is why [NaN].includes(NaN) returns true. A Set also treats repeated NaN values as the same entry.

The second important case is signed zero. JavaScript has positive zero and negative zero. Strict equality treats them as equal, so 0 === -0 is true. SameValueZero also treats them as equal. Object.is is different because Object.is(0, -0) is false. This makes Object.is useful when the sign of zero must be preserved as part of the comparison.

For objects, all three relations compare object identity. Two separately created objects are not equal even when their properties contain the same values. A reference compared with itself is equal.

These comparisons do not copy or allocate the compared values. The important production concern is choosing the equality behavior that matches the operation. In most application logic, === is the normal choice. For collection membership with Set or includes, understand that SameValueZero makes NaN searchable and combines both zero signs.

The example compares the same important values under the three equality behaviors. It shows that ordinary primitive strings agree under all three rules. It shows that NaN differs under strict equality, while signed zero differs under Object.is. It also shows that two separate objects are different, while the same object reference is equal. Set and Array.prototype.includes demonstrate SameValueZero because JavaScript does not provide SameValueZero as a standalone comparison function.

A common mistake is saying that Object.is is simply a stricter version of ===. It is not. They specifically disagree for NaN and signed zero. Another mistake is assuming Array.prototype.includes uses ===. It uses SameValueZero, so [NaN].includes(NaN) is true. Developers also sometimes expect objects with identical properties to compare as equal. These equality relations compare object identity, so two separately created objects are different. Another mistake is assuming a Set can keep positive zero and negative zero as separate values. SameValueZero treats them as the same value.

State the two special number cases first. Say that Object.is treats NaN as equal to itself and distinguishes the two zero signs. Then say that SameValueZero also treats NaN as equal to itself but considers both zero signs equal. Finish by noting that Set and Array.prototype.includes use SameValueZero and that objects are compared by identity.

An inherited writable data property is usually shadowed when I assign the same property name on the child, because JavaScript creates an own property on the child. An inherited setter behaves differently. Assignment calls the setter and does not automatically create an own property with that name. If I delete a shadowing own property, normal lookup can see the inherited property again. I can use Object.hasOwn to confirm whether the property belongs directly to the child.

A child object can use values that come from another object above it. If the child gets its own value with the same name, that value can hide the older one. Removing the child value can make the older value visible again. There is one important special case. If the older object reacts when a value is assigned, the assignment can trigger that reaction instead of storing a new value on the child. We should check which object really owns each value after every change.

1. Should I show both a normal stored value and a property that reacts to assignment?
2. Should I verify ownership with Object.hasOwn after assignment and deletion?

Suppose proto has a writable data property named score with value 10. A child object inherits from proto. Reading child.score first returns 10 because child has no own score, so property lookup continues to proto.

When we run child.score = 20, JavaScript finds the inherited data property and sees that it is writable. The assignment creates an own score property on child with value 20. That own property now shadows the inherited score. The original proto.score is still 10. Object.hasOwn(child, "score") returns true.

Now consider an inherited accessor named status that has a setter. When we assign child.status = "ready", JavaScript calls the inherited setter with child as this. Assignment does not automatically create an own status property. In this example, the setter stores the received value in child.savedStatus. Object.hasOwn(child, "status") therefore remains false.

If we delete child.score, only the own score property is removed. The prototype property is not deleted. Reading child.score again continues through the prototype chain, finds proto.score, and returns 10. Object.hasOwn(child, "score") now returns false.

This behavior matters when objects inherit shared defaults or shared behavior. Shadowing is useful when one object needs its own value. An inherited setter can validate, transform, or redirect an assignment. A key limitation is that an inherited data property that is not writable blocks normal assignment to that name. Another important point is that delete only removes a configurable own property from the object where delete is used. Prototype based designs can save repeated definitions, but they can also make ownership less obvious, so production code should use clear conventions and ownership checks when that distinction matters.

The example creates proto with two inherited properties. score is a writable data property. status is an accessor with a setter and getter. child inherits from proto. Assigning child.score creates an own score property that shadows proto.score. Assigning child.status calls the inherited setter with child as this. The setter stores the value in child.savedStatus, so child does not gain an own status property. Deleting child.score removes the own shadowing property, so reading child.score finds the inherited value 10 again. Object.hasOwn verifies whether score and status belong directly to child.

A common mistake is assuming every assignment creates an own property. An inherited setter can receive the assignment instead. Another mistake is thinking that shadowing changes the prototype property. It does not. The own property only hides it during lookup. Developers may also expect delete child.score to delete proto.score, but delete only targets an own property on child. Another mistake is using the in operator as an ownership check because in reports both own and inherited properties. Object.hasOwn checks direct ownership. It is also incorrect to assume normal assignment can shadow an inherited data property that is not writable.

Explain the two assignment cases separately. First show a writable inherited data property that becomes shadowed by an own property. Then show an inherited setter that receives the assignment without automatically creating that property on the child. Finish by deleting the shadowing property and using Object.hasOwn to prove that the inherited value is visible again.