277 JavaScript Frontend Developer Interview Questions & Answers

A closure lets a function keep access to variables from the scope where that function was created. For example, createCounter can create a private count and return a function that changes it. The count stays available between calls even after createCounter has returned. Each call to createCounter creates separate state, so two counters do not share the same count. This is useful for small pieces of private frontend state, such as state used by an event handler.

A closure lets a function remember information from the place where it was created. This is useful when one part of a program needs to keep a value between calls without exposing that value directly to other code. A counter is a simple example. You give it a starting number, and each later call increases the remembered number. If you create two counters, each one remembers its own number. This pattern can help keep small pieces of page behavior separate, private, and easier to control.

1. Should the counter return the new value after each call?
2. Should I show that two counters keep separate state?
3. Would you like a frontend example using an event handler?

In JavaScript, a closure happens when a function keeps access to variables from the lexical scope where that function was created. Lexical scope means that which variables a function can use is determined by where the function is written in the source code.

For example, createCounter creates a local variable named count. It then returns another function. That returned function reads count, increases it, and returns the new value. After createCounter returns, its normal execution has finished. However, the returned function still refers to count. Because that variable is still reachable through the returned function, JavaScript keeps the required lexical environment available.

If createCounter is called twice, each call creates a separate count binding. Each returned function closes over the count from its own call. Calling the first counter does not change the second counter.

This is useful when a small function needs private state. A frontend event handler can capture information that it needs between events without putting that information in a global variable. Outside code cannot directly access the local count variable through the counter function.

Closures are not always the best choice for shared application state. If many unrelated parts of an application need to read or update the same state, a more explicit state design can be clearer. Closures also keep captured values reachable while something reachable still refers to the closure. Capturing large objects unnecessarily can therefore keep more memory in use than needed. When the closure and its captured environment are no longer reachable, that memory can become eligible for garbage collection.

The example calls createCounter with a starting value. Each call creates its own count binding and returns a function that captures that binding. Calling counterA increases only the count created for counterA. Calling counterB changes a different count created for counterB. The output shows that the captured state remains available after createCounter returns and that the two closures keep independent state.

A common mistake is saying that a closure copies the captured variable. In this example, the returned function keeps access to the count binding created by its own call to createCounter. Another mistake is thinking all counters share one count. Each call to createCounter creates a separate count binding. It is also incorrect to say that count disappears as soon as the outer function returns. The required lexical environment remains reachable through the closure. Finally, capturing large objects without a need can keep those objects reachable longer than expected.

Start with the practical idea that a closure lets a function remember variables from where it was created. Then show createCounter, explain why count remains available after createCounter returns, and prove that two counters have separate state. Finish with one frontend use and one memory consideration.

Scope tells JavaScript where a binding can be found and used. JavaScript uses lexical scope, so it looks in the current scope first and then in surrounding scopes. Common kinds are global, module, function, and block scope. let and const follow block scope, while var follows function scope inside a function. Closures can keep access to bindings from outer scopes even after an outer function has returned.

Scope is about where a name is available in a program. Imagine putting labels inside boxes. A label inside one box may be visible only there, while a label outside may also be visible inside smaller boxes. JavaScript uses the way the code is written to decide which name is found. This matters because two places can use the same name without referring to the same value. Understanding these boundaries helps developers avoid reading or changing the wrong value and makes larger programs easier to understand.

1. Would you like me to show the difference between var, let, and const with an example?
2. Should I also explain how closures keep access to outer bindings?

Scope is the region of a JavaScript program where a binding can be found and used. A binding connects a name, such as count, with a value.

JavaScript has several important kinds of scope. Code running as a classic script can use global scope. An ES module has its own module scope, so its top level declarations do not automatically become properties of the global object. A function creates function scope. A block, such as an if body or loop body, creates block scope for let, const, class, and some other declarations.

JavaScript uses lexical scope. This means scope relationships are determined by where code is written. When JavaScript needs a name, it checks the current scope first. If the binding is not there, it checks each surrounding lexical scope until it finds the binding or reaches the outer end. If no binding exists, reading that name normally causes a ReferenceError.

An inner scope can declare a name that is also declared outside. The inner binding then hides the outer binding while code is inside that scope. This is called shadowing.

var behaves differently from let and const. Inside a function, var belongs to the containing function rather than to an ordinary block. let and const belong to their containing block. let and const also cannot be accessed before their declarations have been initialized.

Closures are closely connected to lexical scope. A function keeps access to the lexical environment where it was created. An inner function can therefore keep using an outer binding after the outer function returns. This is useful for callbacks and private state, but retained bindings can also keep referenced data in memory for as long as the closure remains reachable.

Scope is different from object property lookup and from this. A property is found through an object and possibly its prototype chain. The value of this follows function call rules, while an arrow function gets this from its surrounding context. Neither behavior is lexical variable lookup.

The example starts with an outer message binding. A nested block declares another message binding, so the inner binding shadows the outer one only inside that block. The example also shows that var declared inside an if block is still available throughout its containing function, while let is limited to the block. Finally, makeCounter returns a function that forms a closure and keeps access to the count binding created by makeCounter.

A common mistake is thinking var has block scope like let and const. Another is assuming an inner declaration changes an outer binding when it actually shadows it. Developers may also confuse lexical scope with object property lookup or with the value of this. Another mistake is believing a closure copies an outer value once. A closure keeps access to the relevant outer binding, so later changes to that binding can be observed. It is also incorrect to assume every top level declaration becomes a property of the browser global object, especially inside ES modules.

Start by saying that scope controls where a binding can be found. Then explain lexical lookup from the current scope through surrounding scopes. Name global, module, function, and block scope. Finish with shadowing, the var versus let and const difference, and the connection between lexical scope and closures.

JavaScript decides which binding a function reads from where that function was defined, not from where it is called. It first checks the function's own environment, then moves outward through the environments around its definition. If a nearer environment has the same variable name, that binding shadows the outer one. This makes variable lookup predictable even when the function is called from another scope.

JavaScript remembers the surroundings where each function was created. Those surroundings decide which names the function can read later. Calling the function from another place does not give it access to the caller's local names. If several surrounding places contain the same name, the closest matching name to the function's definition is used. This matters when functions are inside other functions or blocks. Understanding this rule helps you predict which value a function will print and prevents mistakes when the same variable name appears in several nested places.

1. Should I show the difference between where a function is defined and where it is called?
2. Should I include a block with another binding using the same variable name?

Lexical scope means JavaScript decides a function's surrounding environments from the place where the function is defined.

Suppose the top level has label with the value global. An outer function creates another label with the value outer. Inside a block, another label has the value block.

A function defined at the top level reads the top level label, even if we call it from inside the outer function or the block. Its lexical environment was fixed when the function was created, so local bindings belonging only to the caller are not added to its lookup path.

A function defined directly inside the outer function reads the outer label. If we call that function from inside the block, it still reads outer. The block is only the call location. It is not one of the lexical environments surrounding that function's definition.

A function defined inside the block reads the block label. That binding shadows the outer and top level bindings because it is the nearest matching binding in the function's scope chain.

For an identifier read, JavaScript starts with the current lexical environment and follows outer lexical environments until it finds a matching binding. If no matching binding exists anywhere in that chain, reading the undeclared identifier throws a ReferenceError.

This behavior also enables closures. A function can keep access to a binding from the environment where it was created after execution has left that environment. In production code, lexical scope is useful and predictable, but excessive shadowing can make code harder to understand.

The example uses a top level label, an outer function binding also named label, and a block binding with the same name. readGlobal is defined at the top level, so it reads global even when called inside the block. readOuter is defined inside outer, outside the nested block, so it reads outer even when called from the block. readBlock is defined inside the block and then stored in escapedBlockReader. When it is called after execution leaves the block, it still reads block because the closure keeps access to the lexical environment where it was created.

A common mistake is thinking a function reads local variables from the place where it is called. JavaScript does not use the caller's local lexical environment for that lookup. Another mistake is assuming an outer function can read a variable declared only inside a nested block. It cannot. Candidates also sometimes forget that the nearest binding with the same name shadows bindings farther out. Finally, lexical scope should not be confused with this, because ordinary function calls use different rules to determine this.

Start with the main rule: a function reads surrounding bindings based on where it was defined. Then trace the lookup from the function's own environment outward. Use the three label values to show shadowing, and call the functions from inside the block to prove that the call location does not change lexical scope.

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 bound function remembers leading arguments and normally uses its bound this value. The bound arguments come first, before arguments supplied later. If I call the bound function with new, JavaScript ignores the bound receiver and creates a fresh this for construction. The bound arguments still apply. Construction is forwarded to the original target, so in the normal case the new instance inherits from the target prototype. A bound function also gets an adjusted length and name, and it normally has no own prototype property.

A bound function is a new function that remembers another function, a value for this, and any arguments supplied to bind. During a normal call, JavaScript uses the remembered this value and puts the remembered arguments before later arguments. Construction works differently. If the bound function is called with new, JavaScript creates a fresh value for this and ignores the remembered receiver. The remembered arguments still come first. Construction is forwarded to the original function. JavaScript also gives the bound function its own reported argument count and name, but normally no own prototype property.

1. Should I show both a normal call and a constructor call with the same bound function?
2. Do you want me to cover length, name, instanceof, and the missing own prototype property?

Suppose Person receives role and name. If I run Person.bind(savedReceiver, "Engineer"), JavaScript creates a bound function. It remembers savedReceiver and the leading argument "Engineer".

For a normal call such as BoundPerson("Maya"), the original Person function receives "Engineer" first and "Maya" second. Its this value is savedReceiver. Trying to call that bound function with another receiver through call or apply does not replace the original bound receiver.

Construction is different. With new BoundPerson("Leo"), JavaScript forwards construction to Person. The saved receiver is ignored because construction needs a fresh this. The saved argument remains, so Person receives "Engineer" and "Leo". In this example, Person does not return a replacement object, so the result inherits from Person.prototype. It is an instance of Person. It also passes instanceof BoundPerson because the bound function delegates that check to its target.

A bound function normally has no own prototype property. Therefore BoundPerson.prototype is undefined, even though new BoundPerson() works when Person itself can be constructed. This also means a bound function cannot normally be used directly as the parent in a class declaration.

Its length is generally the target length reduced by the number of bound arguments, with zero as the lower limit. Its name is formed from the target name with "bound " in front. Each call to bind creates a new function object, so repeated binding creates extra allocations and can cause callback identity problems.

The example binds Person to savedReceiver and also binds the first argument, "Engineer". A normal call uses savedReceiver as this and places the bound argument before the later argument. A constructor call with new ignores savedReceiver, creates a fresh instance, and still places "Engineer" before "Leo". Because Person does not return a replacement object, the created result inherits from Person.prototype. The example also shows that both instanceof Person and instanceof BoundPerson succeed, that length is reduced, that name gains the "bound " prefix, and that the bound function has no own prototype property.

A common mistake is thinking the bound receiver is always used. It is ignored when the bound function is constructed with new. Another mistake is thinking bound arguments disappear during construction. They still come first. Some candidates expect BoundPerson.prototype to equal Person.prototype, but the bound function normally has no own prototype property. Another mistake is assuming the constructor result must always inherit from the target prototype. A constructor can explicitly return another object, and that object can become the result instead. Candidates also sometimes call bind again and expect the second receiver to replace the first one. Rebinding cannot replace the original bound this, although it can add more bound arguments.

Start with the contrast between a normal call and a call with new. Say that bound arguments stay in both cases, while the bound receiver is ignored during construction. Then explain the target prototype relationship, the constructor return edge case, instanceof, length, name, and the missing own prototype property.

Spread and rest both use three dots, but they do opposite jobs. Spread expands values from an array or object into another place. Rest collects several values into one array or object. I use spread for tasks such as copying an array, merging plain objects, or passing array values as function arguments. I use rest for collecting function arguments or remaining values during destructuring. One important point is that object spread creates only a shallow copy, so nested objects are still shared.

Spread and rest use the same three dots, but the job changes based on where the dots appear. Spread opens a group of values so they can be placed somewhere else. Rest does the opposite. It gathers several values and keeps them together. This matters when copying lists, combining simple objects, sending several values into a function, receiving many function inputs, or taking some values while keeping the remaining ones. A key detail is that copying an object this way does not make new copies of objects stored inside it.

1. Would you like examples for both arrays and plain objects?
2. Should I also explain what happens when the data contains nested objects?

Spread syntax expands values. For an array, [...numbers] creates a new array and places each value from numbers into it. This is useful when you want a new outer array without changing the original array.

Spread also works with plain objects. {...user, active: true} copies the own enumerable properties from user into a new object and then sets active. If the same property appears more than once, the later value wins.

Spread can also pass values from an iterable as separate function arguments. For example, Math.max(...scores) passes each score as its own argument.

Rest syntax collects values instead of expanding them. In a function parameter such as function sum(...values), the remaining arguments are collected into a real array named values. A rest parameter must be the last parameter.

Rest also works in destructuring. With const [first, ...others] = numbers, first receives the first value and others becomes a new array containing the remaining values. With object destructuring, rest collects the remaining own enumerable properties into a new object.

The main limitation is shallow copying. If an object contains another object, spread copies the reference to that nested object. Changing the nested object through the copy can therefore also be visible through the original. Spread is convenient for normal frontend state updates and data transformation, but it is not a deep cloning tool.

The example shows the opposite roles clearly. Array spread copies array elements into a new array. Object spread merges plain objects into a new object, with later properties replacing earlier properties that use the same key. Function call spread expands array values into separate arguments. A rest parameter collects separate arguments into one array. Array destructuring rest collects the remaining array values. The nested object example shows the shallow copy limitation because both outer objects still refer to the same nested object.

A common mistake is thinking spread and rest are different operators. They use the same three dot syntax, and the surrounding syntax decides whether values are expanded or collected. Another mistake is assuming object spread performs a deep copy. It copies the outer object, but nested objects keep the same references. Candidates also sometimes place a rest parameter before another parameter, but a rest parameter must be last. Another mistake is expecting object spread to merge nested objects recursively. If two objects contain the same property, the later property replaces the earlier value rather than deeply combining it.

Start with the simplest contrast: spread expands and rest collects. Then show one short example of each. Mention array copying, object merging, function call spread, function parameter rest, and destructuring rest. Finish by stating that object spread creates only a shallow copy. That final point shows practical JavaScript understanding.

Template literals use backticks instead of normal quotes. I can place an expression inside ${} and JavaScript converts its result into text at that position. I can also put a real line break inside the literal, so multiline text is easy to read. If I need an actual backtick inside the text, I escape it with a backslash. A tagged template is different because JavaScript passes the template parts and expression values to a tag function instead of directly producing the normal string.

Template literals make it easier to build text that contains changing values or several lines. For example, a page can show a person's name and the number of items in one readable message. JavaScript places each requested value into the correct position. A line break written inside the text also stays as a line break in the result. This is useful for messages, labels, generated content, and other text where joining many small pieces would be harder to read. A special form can also send the text pieces and values to another function for custom handling.

1. Should the example preserve the line break exactly as written in the source?
2. Do you want me to explain tagged templates conceptually without implementing a tag?

A normal template literal is written between backticks. Expression interpolation uses ${expression}. JavaScript evaluates the expression, converts its result to a string for the substitution, and inserts that text at the expression position.

For example, if name is "Maya" and itemCount is 3, the template can produce two lines. The first line contains the name. The second line contains the item count. A real newline between those lines in the source becomes a newline in the resulting string.

A backtick normally closes the template literal. To include a literal backtick in its text, write it as \` so JavaScript treats it as content instead of the closing delimiter.

Template literals are useful when a frontend message combines fixed text with dynamic values or needs readable multiline text. They still create strings, so large repeated string construction can allocate new string data. They also do not make interpolated values safe for HTML. User supplied text should be inserted with safe DOM APIs when it is rendered on a page.

A tagged template changes the evaluation process. A tag function receives the fixed string parts and the evaluated expression values. The tag decides what value to return. A normal template literal directly produces the combined string. Tagged templates are useful when custom processing is needed, but they are unnecessary for ordinary interpolation.

The example stores a user name and item count, then creates one normal template literal. It interpolates both values and keeps a real newline between the two message lines. It also escapes a backtick so that character becomes part of the final string. The example then prints the result. A tagged template is only explained because the question does not require implementing a tag.

A common mistake is using normal single or double quotes and expecting ${} to interpolate a value. Another mistake is forgetting that an unescaped backtick closes the template literal. Developers may also expect indentation inside a multiline template to disappear, but spaces and line breaks written inside the template become part of the string. Another mistake is assuming a tagged template is only another spelling for interpolation. A tag receives the template parts and values and can return something other than the normal combined string. Interpolating user input also does not automatically make HTML output safe.

Start by saying that backticks enable both ${} interpolation and literal line breaks. Then show one small two line example. Mention how to escape a backtick, and finish by explaining that a normal template produces the combined string while a tagged template gives the parts and values to a tag function.

Destructuring lets me take values from arrays or objects and assign them to variables in one statement. Array destructuring uses position, while object destructuring uses property names. I can also rename object properties, provide defaults for undefined values, collect remaining values with rest syntax, and use a default empty object when a nested object may be missing.

Destructuring is a short way to take useful pieces from a group of values and give those pieces clear names. For a list, the first name receives the first value, the second name receives the second value, and so on. For a named group, each name looks for a matching property. You can also choose a different local name, provide a fallback when a value is missing, gather the remaining values, and avoid an error when a deeper group does not exist. This keeps common data reading code shorter and easier to follow.

1. Should the example show both a present address and a missing address case?
2. Should the remaining user properties be collected into another object?

Array destructuring reads values by position. With const [x, y, ...remainingCoordinates] = coordinates, x receives the first array element, y receives the second, and the rest syntax creates a new array containing any remaining elements.

Object destructuring reads properties by property name. With const { name, role: jobRole = "Guest", ...otherUserData } = user, JavaScript reads name, reads role into a local variable named jobRole, uses "Guest" only when role is undefined, and creates a new object containing the remaining own enumerable properties that were not already selected.

Nested destructuring can fail if the value being unpacked is undefined or null. A safe pattern is const { address: { city = "Unknown" } = {} } = user. If address is undefined, JavaScript uses the empty object for the nested pattern, so reading city is safe. This default does not help if address is explicitly null.

Destructuring does not deep copy nested objects. If an extracted value is an object, the new variable still contains a reference to that same object. Rest collection creates a new outer array or object, but nested objects remain shared references.

Rest collection also has a cost. JavaScript must create a new array or object and copy the remaining values or properties into it. The work and extra memory grow with the amount collected. Simple destructuring without rest does not create a copy of the whole source collection.

In production frontend code, destructuring is useful for component data, function results, configuration objects, and validated server data. It works best when the expected shape is clear. Avoid deeply nested patterns when they make code difficult to read or when incoming data has not been validated.

The example uses one coordinate array and one user object. The coordinate array demonstrates positional destructuring and rest collection. The user object demonstrates property name matching, renaming, a default value, object rest collection, and nested destructuring. A second user value has no address property and shows how = {} makes the missing nested object safe. The fallback for the nested object applies when address is undefined. It does not protect against an explicit null address. The rest variables create new outer collections, while nested object values remain shared references.

A common mistake is thinking array destructuring uses property names. It uses position. Another mistake is thinking an object default runs for every false like value. A destructuring default runs only when the extracted value is undefined. Developers also sometimes expect = {} to protect nested destructuring from null, but it does not. Another mistake is assuming object or array rest creates a deep copy. The new outer collection is separate, but nested object references are still shared.

Explain the rule in this order: arrays use position, objects use property names, renaming changes only the local variable name, defaults apply to undefined, rest collects what remains, and a default empty object can protect a nested pattern when the nested property is missing.

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.

A browser event is an object that reports something that happened in the browser, such as a click, keyboard input, a document lifecycle change, or completion reported by a browser API. JavaScript can register a listener and receive the event object when the event is dispatched. For DOM events, the browser can process the event through capture, target, and bubble phases. Bubbling also makes event delegation possible, where one parent listener can handle events from many child elements.

A browser event is an object that tells JavaScript that something happened. A person may click a button, press a key, or use a form. The browser can also report page lifecycle changes, and some browser APIs report completed work with events. JavaScript can listen for an event and run a function when it happens. The event object gives useful information about what happened and where it started. This lets a page react when something occurs instead of repeatedly checking whether something has changed.

1. Should I focus mainly on DOM events and event propagation?
2. Would you like me to include event delegation in the example?

A browser event is an object that describes something that happened. For a DOM event, the object referenced by event.target is where the event was dispatched. JavaScript can register a listener with addEventListener so a function runs when that event reaches the listener.

A DOM event can travel through three phases when propagation applies. During capture, it travels through ancestors toward the target. At the target phase, listeners on the target can run. If the event bubbles, it then travels back through ancestors during the bubble phase. Most listeners registered with addEventListener use the bubble behavior unless capture is requested.

The event object contains information about the event. event.target identifies the original target. event.currentTarget identifies the object whose listener is currently running. These values can be different when a child event reaches a parent listener.

Some events have a default browser action. For example, clicking a normal link usually starts navigation. Calling preventDefault prevents that action when the event is cancelable. Calling stopPropagation prevents the event from continuing to later objects in its propagation path. Calling stopImmediatePropagation also prevents later listeners on the same object from running. These methods do not mean the same thing as preventDefault.

Event delegation uses propagation, usually bubbling. Instead of adding a listener to every child, a parent can have one listener and inspect event.target to identify the child involved. This is useful for lists whose items can change over time. It can reduce listener registrations, but the handler must carefully validate the target.

The example creates one container with two links and registers one click listener on the container. A click on either link bubbles to the container. The listener checks that the original target is an Element, uses closest to find the relevant link, confirms that the link belongs to the container, and calls preventDefault so the browser does not perform normal link navigation. It then displays the selected link text. One parent listener therefore handles both links and demonstrates event delegation.

A common mistake is thinking event.target and event.currentTarget always refer to the same object. They can differ when an event reaches a listener on an ancestor. Another mistake is assuming preventDefault stops propagation. It only prevents a default browser action when the event is cancelable. Developers also sometimes use stopPropagation without a clear need, which can prevent other listeners from receiving the event. With delegation, another mistake is assuming every event bubbles or failing to verify that the discovered child actually belongs to the intended container.

Start by defining an event as an object that reports something that happened. Then explain the target and listener, describe capture, target, and bubble in that order, and clearly separate preventDefault from propagation control. Finish with a small event delegation example because it shows why bubbling is useful in real frontend code.