DEV Community: Byte Corner

You Deleted the Array Element. Except You Didn't.

Byte Corner — Mon, 05 Oct 2026 19:22:16 +0000

The Array Still Has Three Elements

In Javascript, delete looks like a natural way to remove something from an array.

You have an element at index 1. You delete it. Surely the array becomes shorter.

Not quite.

delete removes the property at that index. The array itself stays the same length, leaving a hole behind.

🔴 The Problem

Consider this:

const users = ["Alice", "Bob", "Charlie"];

delete users[1];

console.log(users);
console.log(users.length);

You might expect:

["Alice", "Charlie"]
2

Instead, the array still has a length of 3:

["Alice", empty, "Charlie"]
3

The important part is that index 1 is now missing.

You can prove it:

console.log(1 in users); // false
console.log(users.length); // 3

The array did not shift "Charlie" from index 2 to index 1.

You removed the property at index 1 and left a hole where it used to be.

🟢 The Solution

If you mean "remove this element and shift everything after it," use splice():

const users = ["Alice", "Bob", "Charlie"];

users.splice(1, 1);

console.log(users);
console.log(users.length);

Now the result is what you probably expected:

["Alice", "Charlie"]
2

splice() actually changes the array by removing the element and moving the later elements down.

If you do not want to mutate the original array, modern JavaScript also gives you toSpliced():

const users = ["Alice", "Bob", "Charlie"];

const remaining = users.toSpliced(1, 1);

Now users stays unchanged, while remaining contains the shorter array.

⚡ The Part That Bites

The really interesting part is that a hole is not the same as undefined.

Compare these:

const a = ["Alice", undefined, "Charlie"];

const b = ["Alice", "Bob", "Charlie"];
delete b[1];

Reading index 1 gives undefined in both cases:

console.log(a[1]); // undefined
console.log(b[1]); // undefined

But the index exists in a and does not exist in b:

console.log(1 in a); // true
console.log(1 in b); // false

You can see the same difference with Object.keys():

console.log(Object.keys(a)); // ["0", "1", "2"]
console.log(Object.keys(b)); // ["0", "2"]

That difference can also show up when you iterate.

For example, forEach() skips the hole entirely:

b.forEach((value) => {
  console.log(value);
});

This prints only:

Alice
Charlie

There is no callback for the missing index.

That is where a seemingly harmless delete can become a debugging headache. The array can still have the same length, but code iterating over it may no longer see every index you think is there.

🧠 The Takeaway

Arrays are objects with numeric properties and a length property.

So when you write:

delete users[1];

you are deleting a property. You are not asking JavaScript to remove an element and close the gap.

Think of it like this:

delete      -> remove the property at that index
splice      -> remove the element and shift the array

And if you need an immutable version:

toSpliced   -> create a new array without the element

The dangerous part is not that delete fails.

It does exactly what JavaScript asked it to do.

The problem is that what JavaScript means by "delete this array element" is probably not what you meant.

An Optional Property Isn't the Same as undefined

Byte Corner — Mon, 05 Oct 2026 17:20:58 +0000

`undefined` Is Not the Same as Not Being There

An optional property looks a lot like a property whose value can be undefined.

But they are not quite the same thing.

That difference becomes important when you care about whether a property exists at all.

🔴 The Problem

Consider these two objects:

const a = {};

const b = {
  value: undefined,
};

At a glance, they can look equivalent.

Reading value gives you undefined in both cases:

console.log(a.value);
console.log(b.value);

Both print:

undefined

But the objects are different.

One does not have a value property.

The other does.

You can see that with:

console.log("value" in a);
console.log("value" in b);

The result is:

false
true

That distinction is easy to miss because normal property access hides it.

🟢 The TypeScript Part

Now look at this type:

type Config = {
  value?: string;
};

The ? means the property may be absent.

So this is valid:

const config: Config = {};

And this is also valid:

const config: Config = {
  value: "hello",
};

Depending on your TypeScript configuration, this can also be valid:

const config: Config = {
  value: undefined,
};

But those last two objects still represent different runtime states.

The first has a value.

The second has a property whose value is undefined.

That difference matters when the presence of the property itself has meaning.

⚡ The Part That Usually Bites

Imagine an API where omitting a property means:

"Don't change this setting."

while explicitly passing undefined has a different meaning.

Or imagine code that checks whether a property was supplied:

if ("value" in config) {
  // the caller supplied the property
}

Now these two values are no longer interchangeable:

const a: Config = {};

const b: Config = {
  value: undefined,
};

The type might make them look similar.

The runtime object does not.

This becomes especially interesting when objects are passed between functions, merged together, serialized, or used as configuration.

🧠 The TypeScript Detail

There is a compiler option specifically related to this distinction:

{
  "compilerOptions": {
    "exactOptionalPropertyTypes": true
  }
}

With this enabled, an optional property means the property can be omitted.

It does not automatically mean you can explicitly assign undefined.

So:

type Config = {
  value?: string;
};

allows:

const a: Config = {};

and:

const b: Config = {
  value: "hello",
};

But this becomes an error:

const c: Config = {
  value: undefined,
};

If you actually want to allow the property to exist with undefined, say so:

type Config = {
  value?: string | undefined;
};

Now the type describes both possibilities:

property is absent
        OR
property exists with undefined
        OR
property exists with a string

That is a much more precise description of the object.

🧩 When Could This Be Useful?

This distinction is especially useful for configuration and update objects.

Consider:

type UserUpdate = {
  name?: string;
  email?: string;
};

An update function might interpret an omitted property as:

"Leave the existing value alone."

while a present property could mean:

"Change this field."

That makes property presence part of the API's meaning.

The same idea appears when dealing with object merging:

const defaults = {
  color: "orange",
};

const options = {
  color: undefined,
};

const result = {
  ...defaults,
  ...options,
};

The property was not missing.

It was explicitly present.

So the resulting object contains:

{
  color: undefined;
}

That can be very different from simply not providing color at all.

🧠 The Takeaway

An optional property is about presence.

undefined is about value.

Those two concepts often produce the same result when you simply read the property:

object.value;

But they can represent different states.

Once your application cares about whether something was omitted or explicitly provided, that difference stops being a TypeScript technicality.

It becomes part of the API design.

value?: string

does not simply mean:

"value can be undefined"

It starts with:

"this property may not exist"

And sometimes, that is exactly the distinction your code needs.

What Makes Something Worth Understanding?

Byte Corner — Mon, 05 Oct 2026 14:52:28 +0000

The Question That Matters

Some things are useful because they solve a problem.

Others are worth understanding even when you are not going to use them tomorrow.

That sounds obvious, but it is easy to forget when learning software development. We tend to measure everything by usefulness. Will this help me write better code? Will I use it at work? Is this worth remembering?

Sometimes the answer is simply: it is interesting.

And I think that is a perfectly good reason.

Not everything needs an immediate use case

Take something like CSS margin collapsing.

You can go years without deliberately using it. You might even work around it without knowing exactly what is happening.

But once you understand it, a strange behavior stops being strange.

That matters.

Understanding something gives you a better model of how the thing works. You do not need to use that knowledge every day for it to be valuable.

The same applies to things like how JavaScript evaluates expressions, how a browser calculates layout, or why a particular TypeScript type behaves the way it does.

You might not need the answer today.

But the next time you encounter the problem, you already have a place to start.

More importantly, you start recognizing similar problems.

A weird layout issue might not look exactly like the one you saw before. A TypeScript error might happen in a completely different part of the application. A JavaScript behavior might appear in an API you have never used.

The details change.

The mental model stays.

Useful is not the same as valuable

There is a difference between learning something because you need it and learning something because it makes the system make more sense.

The first gets you moving.

The second changes how you see things.

That distinction is important because software is full of behavior that is technically easy to ignore.

You can memorize that something happens.

You can also understand why it happens.

The second one tends to stick.

Think about debugging.

You can memorize a fix for a particular problem. Add this property. Move this code. Await this promise. Add this check. Restart the development server.

Sometimes that is all you need.

But if you understand the reason behind the fix, the next problem becomes easier.

You are no longer searching for the same solution. You are looking for the same kind of problem.

That is a much more useful thing to carry around.

Understanding gives you better questions

There is another benefit that is easy to miss.

Once you understand how something works, you start asking better questions.

Before you understand CSS layout, the question might be:

Why is this element doing this? Why is this property doing that?

After you understand the layout model, the question becomes:

Which constraint is causing this result?

That is a completely different debugging process.

The same thing happens with asynchronous JavaScript.

Instead of asking:

Why did this happen after that?

You start asking:

When was this callback scheduled, and what state did it capture?

Or with TypeScript:

Why does TypeScript hate this?

becomes:

Where did the type information disappear?

Those questions are more specific.

They give you somewhere to look.

Understanding does not just give you answers. It changes the questions you ask when you do not have an answer.

You do not have to remember everything

This is also why I do not think learning something requires memorizing every detail.

There is a difference between knowing something by heart and understanding it well enough to find your way back to it.

You will forget syntax.

You will forget exact APIs.

You will forget edge cases.

That is normal.

What tends to survive is the model.

You remember that CSS has different ways of calculating sizes. You remember that promises have their own scheduling behavior. You remember that TypeScript is tracking information that may disappear at certain boundaries.

The next time you need the details, you can look them up.

But you know what you are looking for.

That is often enough.

The rabbit hole is sometimes the point

This is one of the reasons I like digging into seemingly small technical details.

A question starts simple.

Why did this element move?

Why did this promise resolve to that value?

Why does this type behave differently here?

Why did this request still change the UI even though it failed?

The answer is often not immediately useful.

But following the answer usually reveals something about the system that was hidden before.

And sometimes that is enough.

A small question can lead somewhere much bigger.

You start with one strange behavior and end up understanding part of the larger algorithm.

You start with one confusing error and end up understanding how information is lost or preserved.

You start with one bug and end up understanding why the order of events in your application is not always the order the code appears in.

The original problem might never happen again.

The understanding still stays with you.

Curiosity is a useful engineering skill

There is a temptation to treat curiosity as something separate from practical engineering.

It is not.

Curiosity is often what makes you stop when something feels slightly wrong.

You could accept that the code works.

Instead, you ask why.

You could copy the fix from a search result.

Instead, you try to understand what the fix is actually changing.

You could move on after finding the answer.

Instead, you follow the next question.

That does not mean every rabbit hole is worth following.

Some are not.

You can spend an afternoon learning something that will never matter to your work. That is fine too, sometimes. But there is a difference between curiosity and collecting trivia.

The useful kind of curiosity changes your mental model.

You come out of the rabbit hole seeing something differently than you did before.

So, is it worth understanding?

I think a good question is not only:

"Will I use this?"

It is also:

"Will understanding this change how I think about the thing?"

If the answer is yes, it probably belongs in the rabbit hole.

Maybe it will help you debug something six months from now.

Maybe it will make a confusing API suddenly make sense.

Maybe it will help you recognize a bug before you write it.

Or maybe you will never use the knowledge directly.

You will just understand a little more about how the thing works.

That is enough of a reason.

Not everything you learn has to pay for itself immediately.

Sometimes understanding is the useful part.

There Is No Such Thing as an Edge Case. Or is there?

Byte Corner — Fri, 02 Oct 2026 11:42:45 +0000

There Is No Such Thing as an Edge Case. Or is there?

"That's just an edge case."

You've probably heard it after someone finds a weird input, an unexpected state, or a combination of events nobody thought would happen.

Sometimes that's a perfectly reasonable description.

Sometimes it's how a bug gets dismissed.

The interesting question is not whether something is unusual.

It's whether your software needs to handle it.

🔴 The Problem

Imagine you're building a system that accepts a username.

You expect something like:

matej
alex
sarah

Then someone enters:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Is that an edge case?

Probably.

Now imagine someone enters:

admin

That's also a normal-looking username.

But if your system gives special privileges to admin because of an assumption hidden somewhere else, you've got a very different problem.

Neither input looks particularly strange.

The important difference is the assumption your system makes about it.

That's where "edge cases" get interesting.

🟢 The Solution

Instead of thinking:

"How likely is this to happen?"

try asking:

"What does the system need to do if this happens?"

Those are different questions.

A user entering 500 characters might be extremely rare.

But if the application accepts user input, someone eventually will.

A network request taking 10 seconds might be unusual.

But if your application depends on a network request, your code still needs a behavior for it.

A list containing zero items might seem like an edge case.

But if an empty list is a perfectly valid result, it's not really an edge case at all.

It's just another valid state.

const users = await getUsers();

if (users.length === 0) {
  showEmptyState();
}

The empty state isn't "special handling" if an empty result is part of the system's normal contract.

It's the contract.

⚡ The "Why"

The phrase "edge case" can make something sound like it belongs outside the main problem.

But software doesn't care how unusual a situation sounds.

It cares whether the situation is inside or outside the behavior you've decided to support.

Consider:

function divide(total, count) {
  return total / count;
}

Someone might say:

"What if count is zero? That's an edge case."

But if count can actually be zero, then the function has a decision to make.

Should it:

if (count === 0) {
  return 0;
}

throw?

if (count === 0) {
  throw new Error("count must be greater than zero");
}

or produce some other defined result?

The interesting part isn't which decision you make.

The interesting part is that not making a decision is also a decision.

The bug usually appears when the code has an assumption but nobody realized it was an assumption.

🧩 The Boundary Moves

Here's the uncomfortable part.

What counts as an edge case can change.

A system might originally have:

1–10 items

and treat 100 items as unusual.

Then the product grows.

Now customers regularly import 500 items.

The input didn't change.

The system's expectations did.

What used to be an edge case is now normal traffic.

That's why good software isn't built by trying to predict every bizarre thing that could ever happen.

It's built by making important assumptions explicit.

Instead of:

const firstUser = users[0];

renderUser(firstUser);

you might decide that an empty collection is valid:

if (users.length === 0) {
  renderEmptyState();
  return;
}

renderUser(users[0]);

Now the behavior is deliberate.

The code isn't merely hoping the assumption stays true.

🧠 The Takeaway

There isn't a universal list of edge cases.

An edge case is usually a situation that sits near the boundary of what your system expects to handle.

And those boundaries depend on the system.

So when someone says:

"That's just an edge case."

the useful follow-up isn't:

"How likely is it?"

Ask:

"Is this a state our software is supposed to handle?"

If the answer is yes, it isn't outside the problem.

It's part of the problem.

And if the answer is no, that's worth making explicit too.

Because an edge case isn't necessarily something rare.

Sometimes it's simply an assumption that hasn't been turned into a decision yet.

`async` Is Built on an Idea You Can See in `yield`

Byte Corner — Fri, 02 Oct 2026 11:42:35 +0000

async Is Built on an Idea You Can See in `yield`

yield and await aren't the same thing.

A generator isn't an async function, and an async function isn't a generator.

But there is an idea hiding underneath both of them that is easy to miss:

execution can stop here and continue later.

Once you see that, async/await starts looking a lot less magical.

🔴 The Problem

Consider a generator:

function* work() {
  console.log("A");

  yield;

  console.log("B");
}

Create it:

const task = work();

Nothing has run yet.

Now call next():

task.next();
// A

The generator runs until it reaches yield.

Then it stops.

It hasn't finished. It hasn't returned.

It's suspended.

Call next() again:

task.next();
// B

Execution continues exactly where it stopped.

That's unusual if you're used to ordinary functions.

Normally, you think of a function like this:

start → run → finish

A generator gives you:

start → run → suspend → resume → finish

And that middle part is the interesting bit.

If you want to see the whole thing together:

function* work() {
  console.log("A");

  yield;

  console.log("B");
}

const task = work();

task.next(); // A
task.next(); // B

The first next() runs until yield.

The second next() resumes the generator and continues after yield.

🟢 The Idea

yield makes suspension easy to see.

The generator essentially says:

"I'm stopping here. You can have control for a while. I'll continue later."

The caller decides when that happens:

const task = work();

task.next(); // runs until yield

// do something else

task.next(); // continue after yield

Nothing about this requires the generator to block JavaScript.

The generator's execution is paused while the rest of the program can continue.

That idea turns out to be extremely useful for asynchronous programming.

🔵 Promises Change Who Controls the Resume

Promises give us another way to express "continue later."

Without async/await, you might write:

doSomething().then((result) => {
  use(result);
});

The interesting part isn't really .then().

It's what the code is saying:

start something
       ↓
   not ready yet
       ↓
   continue later
       ↓
    use(result)

The function doing the work doesn't need to sit around waiting for the result.

Instead, the continuation is registered and runs when the Promise settles.

This is conceptually similar to what we saw with yield, even though the mechanisms are completely different.

With a generator, you explicitly resume the computation:

task.next();

With a Promise, settlement allows the continuation to be scheduled.

Different machinery.

Same useful idea:

this computation can suspend while something else happens.

🟣 Then `await` Makes It Look Normal

Now look at the same kind of operation using async/await:

async function work() {
  const result = await doSomething();

  use(result);
}

This looks almost like ordinary synchronous code.

That's intentional.

But the function isn't actually blocking at await.

When JavaScript reaches:

const result = await doSomething();

the async function suspends.

JavaScript gets control back.

When the Promise eventually fulfills, the async function continues:

use(result);

You can think of the execution like this:

work()
  ↓
run
  ↓
await Promise
  ↓
suspend
  ↓
JavaScript continues elsewhere
  ↓
Promise fulfills
  ↓
resume work()
  ↓
use(result)

The await marks a point where this particular piece of execution may need to give up control temporarily.

The rest of JavaScript doesn't have to wait with it.

⚡ The "Why"

Here's where yield becomes useful for understanding await.

With a generator, we can see the suspension point directly:

function* generator() {
  doSomething();

  yield;

  continueWork();
}

yield explicitly tells the generator:

"Stop here. I'll continue later."

await creates a similar boundary inside an async function:

async function asyncFunction() {
  const result = await doSomething();

  continueWork(result);
}

The interesting part isn't that await is asynchronous.

The interesting part is what happens to the function itself.

When execution reaches await, that invocation of asyncFunction cannot continue yet. Its continuation is put aside until the awaited Promise settles.

JavaScript is free to do other work in the meantime.

Then the async function resumes and continues with:

continueWork(result);

So you can put the two side by side:

generator

doSomething()
     ↓
   yield
     ↓
  suspend
     ↓
  next()
     ↓
continueWork()

async function

doSomething()
     ↓
  await
     ↓
  suspend
     ↓
Promise settles
     ↓
continueWork()

The mechanisms aren't the same.

A generator is explicitly resumed with next().

An async function resumes through the Promise machinery.

But both give us the same useful idea:

a computation can suspend at a specific point and continue later from that point.

That's the connection between yield and await.

🧩 The Important Difference

It's tempting to say "await is basically yield."

That's not quite right.

Generators are manually resumable:

const generator = work();

generator.next();
generator.next();

The caller controls when the generator moves forward.

An async function works differently.

When it reaches:

await promise;

the function's continuation is tied to the Promise.

And an async function always returns a Promise:

async function work() {
  return 42;
}

work().then((value) => {
  console.log(value);
});

So await isn't simply a nicer version of yield.

The mechanisms and semantics are different.

The shared idea is what matters.

🧠 The Mental Model

If you remember only one thing, make it this:

yield
  ↓
"Pause this computation.
 Resume me when the caller decides."

await
  ↓
"Pause this computation.
 Resume me when this Promise is ready."

Both let a computation give control back instead of insisting on finishing immediately.

yield makes that behavior visible.

await hides it behind syntax that looks sequential.

That's part of why async/await feels so natural.

It lets you write:

const user = await getUser();
const posts = await getPosts(user.id);

render(user, posts);

as though the function simply runs from top to bottom.

But underneath that simple-looking code are suspension points.

The function can stop.

The rest of JavaScript can keep moving.

Then the function can pick up where it left off.

And once you've seen that idea in yield, await doesn't look quite so magical anymore.

Different mechanisms.

Same surprisingly useful idea:

a computation can suspend now and continue later.

Get item index and item count in CSS

Byte Corner — Fri, 02 Oct 2026 11:42:23 +0000

sibling-index() and sibling-count()

For years, CSS had no way of knowing which position an element had among its siblings, or how many siblings there were. Now it does. With sibling-index() and sibling-count() you can finally get the item index and item count directly in CSS.

sibling-index() returns the element's position among its siblings, starting at 1.
sibling-count() returns the total number of siblings, including the element itself.

How we used to do it

Before these functions existed, the only option was to number everything by hand. You had to put the total count on the parent and an index on every child, using inline custom properties.

HTML

<div class="parent" style="--n: 4;">
  <div class="child" style="--i: 1;"></div>
  <div class="child" style="--i: 2;"></div>
  <div class="child" style="--i: 3;"></div>
  <div class="child" style="--i: 4;"></div>
</div>

CSS

.parent {
  display: flex;
  gap: 1em;
  max-inline-size: 40rem;
  margin-inline: auto;
  .child {
    aspect-ratio: 1;
    flex: 1;
    background: hsl(calc(360 / var(--n) * var(--i)) 100% 50%);
  }
}

This works, but it is tedious. Every item needs its own --i, and the moment you add or remove an item, you have to update --n and renumber the rest.

The new way

With sibling-index() and sibling-count(), all of that manual work disappears. The HTML is just plain markup, and the CSS figures out the rest on its own.

Here is the same example again: a unique background color for every item, based on its index.

HTML

<div class="parent">
  <div class="child"></div>
  <div class="child"></div>
  <div class="child"></div>
  <div class="child"></div>
</div>

CSS

.parent {
  display: flex;
  gap: 1em;
  max-inline-size: 40rem;
  margin-inline: auto;
  .child {
    aspect-ratio: 1;
    flex: 1;
    background: hsl(calc(360 / sibling-count() * sibling-index()) 100% 50%);
  }
}

The hue is 360 / count * index, so the colors are spread evenly around the color wheel. Add a fifth child and every hue adjusts automatically.

Using them as custom properties

You can also store the functions in custom properties, which keeps your code shorter if you use them in many places.

CSS

:root {
  --n: sibling-count();
  --i: sibling-index();
}

.parent {
  display: flex;
  gap: 1em;
  max-inline-size: 40rem;
  margin-inline: auto;
  .child {
    aspect-ratio: 1;
    flex: 1;
    background: hsl(calc(360 / var(--n) * var(--i)) 100% 50%);
  }
}

Where are they counted?

You might expect --n and --i to be calculated on :root, since that is where they are defined. They are not. sibling-index() and sibling-count() count the items where the variable is used, not where it is defined.

In this example the variables are defined on :root, but they are used on .child. So they count each .child item, not the root.

This is what makes it possible to define them once on :root and reuse them everywhere.

See it in action

The first example keeps things simple: each item gets a color based on its position in the group. Add or remove .child elements and both sibling-index() and sibling-count() update automatically.

In another example, the same idea can drive much more than colors. Here, the sibling position determines each box's angle, distance from the center, rotation, color, and animation delay.

Change the number of .box elements and the entire 3D arrangement adapts to it.

Why `finally` Runs Before `return` Takes Effect

Byte Corner — Fri, 02 Oct 2026 11:42:04 +0000

Why Your `finally` Runs After `return`

A return looks like the end of a function.

But put a finally after it:

function getValue() {
  try {
    return 42;
  } finally {
    console.log("cleanup");
  }
}

console.log(getValue());

The output is:

cleanup
42

The return happened.

The function just hadn't finished leaving yet.

🔴 The Problem

It's tempting to think of return as:

return
  ↓
function stops immediately

But with finally, there's another step.

When JavaScript reaches:

return 42;

it evaluates 42 and prepares to return it.

Before the function actually completes, JavaScript runs the finally
block.

So the flow is roughly:

return 42
    ↓
remember 42
    ↓
run finally
    ↓
finish returning 42

The important part is that the return value has already been determined.

finally just gets to run before the function actually exits.

🟢 The Solution

This is exactly what makes finally useful for cleanup.

Imagine something that needs to be closed regardless of what happens:

function readFile(file) {
  try {
    return file.read();
  } finally {
    file.close();
  }
}

file.read() can still determine the value returned to the caller.

But file.close() runs before the function actually leaves.

Without finally, you'd have to duplicate the cleanup:

function readFile(file) {
  try {
    const result = file.read();

    file.close();

    return result;
  } catch (error) {
    file.close();

    throw error;
  }
}

With finally, the cleanup has one place:

function readFile(file) {
  try {
    return file.read();
  } finally {
    file.close();
  }

Whether try returns, throws, or finishes normally, finally gets its
chance to run.

⚡ The Dangerous Part

finally isn't limited to cleanup.

It can actually change how the function finishes.

function getValue() {
  try {
    return 42;
  } finally {
    return 100;
  }
}

console.log(getValue());

The result is:

The original return 42 prepared the function to return 42.

Then finally executed another return.

That new return becomes the function's actual result.

The same thing can suppress an error:

function getValue() {
  try {
    throw new Error("Boom");
  } finally {
    return 42;
  }
}

console.log(getValue());

Instead of throwing, the function returns:

The return inside finally replaced the pending exception.

That's why returning from finally is usually a bad idea.

You're no longer just cleaning up.

You're changing the outcome.

🧠 The Takeaway

Don't think of:

return value;

as:

"I am completely done now."

Think of it as:

"I know how I want to finish."
        ↓
     finally
        ↓
"I actually leave now."

So this is perfectly reasonable:

try {
  return result;
} finally {
  cleanup();
}

But this deserves suspicion:

try {
  return result;
} finally {
  return somethingElse;
}

return decides the result.\
finally gets the last chance to change how the function exits.

DEV Community: Byte Corner

You Deleted the Array Element. Except You Didn't.

The Array Still Has Three Elements

🔴 The Problem

🟢 The Solution

⚡ The Part That Bites

🧠 The Takeaway

An Optional Property Isn't the Same as undefined

undefined Is Not the Same as Not Being There

🔴 The Problem

🟢 The TypeScript Part

⚡ The Part That Usually Bites

🧠 The TypeScript Detail

🧩 When Could This Be Useful?

🧠 The Takeaway

What Makes Something Worth Understanding?

The Question That Matters

Not everything needs an immediate use case

Useful is not the same as valuable

Understanding gives you better questions

You do not have to remember everything

The rabbit hole is sometimes the point

Curiosity is a useful engineering skill

So, is it worth understanding?

There Is No Such Thing as an Edge Case. Or is there?

There Is No Such Thing as an Edge Case. Or is there?

🔴 The Problem

🟢 The Solution

⚡ The "Why"

🧩 The Boundary Moves

🧠 The Takeaway

`async` Is Built on an Idea You Can See in `yield`

async Is Built on an Idea You Can See in yield

🔴 The Problem

🟢 The Idea

🔵 Promises Change Who Controls the Resume

🟣 Then await Makes It Look Normal

⚡ The "Why"

🧩 The Important Difference

🧠 The Mental Model

Get item index and item count in CSS

sibling-index() and sibling-count()

How we used to do it

The new way

Using them as custom properties

Where are they counted?

See it in action

Why `finally` Runs Before `return` Takes Effect

Why Your finally Runs After return

🔴 The Problem

🟢 The Solution

⚡ The Dangerous Part

🧠 The Takeaway

`undefined` Is Not the Same as Not Being There

async Is Built on an Idea You Can See in `yield`

🟣 Then `await` Makes It Look Normal

Why Your `finally` Runs After `return`