Forem: Farhad Hossain

Mouse Events in JavaScript: Why Your UI Flickers (and How to Fix It Properly)

Farhad Hossain — Tue, 13 Jan 2026 06:52:15 +0000

Hover interactions feel simple—until they quietly break your UI.

Recently, while building a data table, I ran into a strange issue. Each row had an “Actions” column that appears when you hover over the row. It worked fine most of the time, but sometimes—especially when moving the mouse slowly or crossing row borders—the UI flickered. In some cases, two rows even showed actions at once.

At first glance, it looked like a CSS or rendering bug.

It wasn’t.
It was a mouse event model problem.
That experience led me to a deeper realization:
Not all mouse events represent user intent. Some represent DOM mechanics—and confusing the two leads to fragile UI.

Let’s unpack that.

The Two Families of Mouse Hover Events

JavaScript gives us two sets of hover events:

Event	Bubbles	Fires when
`mouseover`	Yes	Mouse enters an element or any of its children
`mouseout`	Yes	Mouse leaves an element or any of its children
`mouseenter`	No	Mouse enters the element itself
`mouseleave`	No	Mouse leaves the element itself

This difference seems subtle, but it’s one of the most important distinctions in UI engineering.

Why `mouseover` Is Dangerous for UI State

Consider this table row:

<tr>  
  <td>Name</td>  
  <td class="actions">  
    <button>Edit</button>  
    <button>Delete</button>  
  </td>  
</tr>

From a user’s perspective, they are still “hovering the row” when they move between the buttons.

But from the browser’s perspective, something very different is happening:

<tr> → <td> → <button>

Each move fires new mouseover and mouseout events as the cursor travels through child elements.

That means:

Moving from one button to another fires mouseout on the first
Which bubbles up
And can look like the mouse “left the row”

Your UI hears:
“The row is no longer hovered.”
The user never left.
This mismatch between DOM movement and human intent is the root cause of flicker.

How My Table Broke

In my case:

Each table row showed action buttons on hover
Borders existed between rows
When the mouse crossed that 1px border, it briefly exited one row before entering the next

This triggered:

mouseout → hide actions
mouseover → show actions again

Sometimes the timing was fast enough that:

Two rows appeared active
Or the UI flickered

Nothing was “wrong” with the layout.
The event model was simply lying about what the user was doing.

Why `mouseenter` Solves This

mouseenter and mouseleave behave very differently.

They do not bubble.

They only fire when the pointer actually enters or leaves the element itself—not its children.

So this movement:
<tr> → <td> → <button>

Triggers:
mouseenter(tr)

Once.

No false exits.
No flicker.
No state confusion.

This makes them ideal for:

Table rows
Dropdown menus
Tooltips
Hover cards
Any UI that should remain active while the cursor is inside

In other words:
mouseenter represents user intent

mouseover represents DOM traversal

When You Should Use Each

Use `mouseenter` / `mouseleave` when:

You are toggling UI state based on hover
Child elements should not interrupt the hover
Stability matters

Examples:

Row actions
Navigation menus
Profile cards
Tooltips

Use `mouseover` / `mouseout` when:

You actually care about which child was entered.
Examples:

Image maps
Per-icon tooltips
Custom hover effects on individual elements

Here, bubbling is useful.

React Makes This More Subtle

In React, onMouseOver and onMouseOut are wrapped in a synthetic event system. That adds another layer of propagation and re-rendering, which can amplify flicker and race conditions.

This is why tables, dropdowns, and hover-driven UIs are often harder to get right than they look.

A Practical Rule of Thumb

If you are using mouseover to control UI visibility, you are probably building something fragile.

Most hover-based UI should be built with:

mouseenter
mouseleave

Because users don’t hover DOM nodes.
They hover things.

Final Thoughts

That small flicker in my table wasn’t a bug—it was a reminder of how deep the browser’s event model really is.

The best UI engineers don’t just write logic that works.

They write logic that matches how humans actually interact with the screen.

And sometimes, the difference between a glitchy UI and a rock-solid one is just a single event name.

How JavaScript Engines Optimize Objects, Arrays, and Maps (A V8 Performance Guide)

Farhad Hossain — Tue, 23 Dec 2025 11:53:21 +0000

Understanding how V8 optimizes data structures to avoid silent performance slowdowns

At some point, every JavaScript application hits a wall.

Nothing crashes. No errors appear.

Yet things start to feel… slower. Lists take longer to render. Forms feel sluggish. Loops that once seemed trivial begin to matter. Your code still works, but performance quietly degrades as your application grows.

More often than not, the issue isn’t your business logic—it’s how the JavaScript engine (specifically V8, used by Chrome and Node.js) reacts to the way your data is structured.

This guide isn’t about premature micro-optimization. It’s about understanding why some data patterns scale smoothly while others silently disable the engine’s best optimizations.

1. How JavaScript Objects Are Optimized in V8 (Hidden Classes Explained)

JavaScript objects look like flexible key-value bags. Internally, V8 treats them very differently.

To make property access fast, V8 groups objects by their shape using hidden classes (called Maps internally).

A hidden class represents:

Which properties an object has
The order in which those properties were added

When many objects share the same shape, V8 can optimize property access aggressively.

Why Object Shape Consistency Improves Performance

Consider these two objects:

const a = {};
a.name = "John";
a.age = 32;

const b = {};
b.age = 35;
b.name = "Michel";

Inline Caching: Why Stable Object Shapes Matter

Hidden classes enable inline caching. When V8 repeatedly sees a property access like user.name, it can cache:

The object’s hidden class
The exact memory offset of name

As long as the shape stays the same, V8 can skip property lookups entirely.

Once shapes diverge:

Inline caches become polymorphic
Then megamorphic
Eventually deoptimized

Object shape stability matters far more than most developers realize.

Best Practices for Creating Fast JavaScript Objects

Use Classes or Constructors for Repeated Objects

class User {
  constructor(name, age, role) {
    this.name = name;
    this.age = age;
    this.role = role;
  }
}

const users = [
  new User("Farhad", 32, "developer"),
  new User("Sarah", 28, "designer"),
];

All instances share the same shape, enabling fast and predictable property access. Ideal for lists, models, and frequently created objects.

Plain Object Literals Are Fine for One-Off Data

const formData = {
  name: "Farhad",
  age: 32,
  role: "developer",
};

For configs, API payloads, or one-time objects, shape reuse doesn’t matter.

Avoid Dynamic Property Addition

const user = {};
for (const key of keys) {
  user[key] = getValue(key);
}

Each new key can change the object’s shape, forcing V8 to create new hidden classes.

Better approach:

const user = { 
  name: undefined, 
  age: undefined, 
  role: undefined, 
  email: undefined 
};

for (const key of keys) {
  if (key in user) {
    user[key] = getValue(key);
  }
}

Flexibility without sacrificing performance.

2. How JavaScript Arrays Work Internally (Packed vs Sparse Arrays)

Arrays are extremely fast—until you accidentally make them slow.

Think of a fast array like a tight row of identical boxes on a shelf. As long as none are missing and all are the same type, V8 moves through them efficiently. Once gaps or mixed types appear, performance drops.

JavaScript Array Element Kinds

V8 tracks element kinds to decide how arrays are stored:

SMI_ELEMENTS — small integers (fastest)
DOUBLE_ELEMENTS — floating-point numbers (less faster)
ELEMENTS — mixed or object values (slower)

Once an array transitions to a slower kind, it never upgrades back.

Common Mistakes That Hurt Performance

Sparse Arrays (Holes)

const arr = new Array(3);
arr[0] = 1;
arr[1] = 2;
arr[2] = 3;

Even though all elements exist, the initial holes force V8 into a slower representation.

Mixed Types

const nums = [1, 2, 3];
nums.push(4.5);
nums.push("5"); // permanent downgrade

Deleting Elements

delete arr[5]; // creates holes

Prefer:

arr.splice(5, 1);

When to Use Typed Arrays

For numeric workloads:

const data = new Float64Array(1024);

Typed arrays:

Use fixed element types
Avoid hidden class overhead
Offer predictable memory layouts

Ideal for math-heavy or binary data processing.

Why JavaScript Objects Become Slow with Dynamic Keys

Heavy object mutation—adding and removing properties dynamically—forces V8 into dictionary mode (hash-table storage).

Hidden class transitions cost CPU
Inline caching stops working
Property access becomes hash-based

This is exactly why Map exists.

3. Map vs Object in JavaScript: Performance Differences

const store = {};
store[userId] = data;

This works for small, fixed datasets. For growing or unpredictable key sets, it becomes inefficient. Maps are hash tables by design.

Operation	Object (Stable)	Object (Dynamic)	Map
Read	O(1) (IC)	O(1) (Hash)	O(1)
Write	Cheap	Expensive	Cheap
Delete	Expensive	Expensive	Cheap
Size	O(n)	O(n)	O(1)

When to Use:

Object → fixed structure, read-heavy data
Array → ordered, dense collections
Map → dynamic keys, frequent mutations

When You Can Safely Ignore These Optimizations

You don’t need to worry about object or array optimizations when:

The code is not on a hot path
The dataset is small
Objects are created once
Readability would suffer

Rule of thumb: profile first, optimize second.

How to Choose the Right JavaScript Data Structure for Performance

Most JavaScript performance problems don’t come from “slow code.” They come from misaligned data structures.

Objects with stable shapes
Arrays that stay dense and homogeneous
Dynamic data living in Maps

V8 can do what it does best when the engine can predict your data patterns. You don’t need to memorize engine internals—just structure your data intentionally.

Conclusion

JavaScript performance isn’t about clever tricks—it’s about predictable, intentional data structures.

Keep objects consistent, arrays dense, and dynamic data in Maps. Profile hot paths and write code that’s easy to reason about.

When your structures are stable, speed comes naturally—and V8 does the heavy lifting for you.