BigInt and the Cost of Not Breaking the Web

At some point while working with numbers in JavaScript, you run into a strange limitation.

9007199254740991 + 1 // 9007199254740992
9007199254740991 + 2 // 9007199254740992 ❌

Two different calculations produce the same result. That’s usually the moment you realize something is off.

The issue isn’t a bug in your code. It’s a limitation in how JavaScript represents numbers.

And instead of fixing that limitation, JavaScript introduced something new: BigInt.

Understanding why tells you a lot about how JavaScript evolves.

The Hidden Limitation of number

All regular numbers in JavaScript are floating-point values.

That means they are designed to handle a wide range of values, including decimals, but they sacrifice precision when numbers get very large.

There is a boundary called:

Number.MAX_SAFE_INTEGER

Beyond this point, JavaScript can no longer reliably represent integers.

So the language gives you flexibility, but not absolute precision.

BigInt: A Different Numeric World

BigInt was introduced to solve this exact problem.

const value = 9007199254740991n

The n at the end tells JavaScript:

“This is not a regular number. This is a BigInt.”

Now calculations behave as expected:

9007199254740991n + 2n // 9007199254740993n

No rounding. No precision loss.

BigInt represents integers exactly, no matter how large they become.

Why Not Just Fix number?

This is where things get interesting.

If JavaScript numbers have a flaw, why not just fix them?

Because JavaScript is not an isolated system.

It runs:

• in every browser
• on billions of devices
• across decades of existing code

Changing how number works would break an enormous amount of software.

Even subtle changes could introduce silent bugs:

if (calculate() === expected) {
  // logic depends on exact numeric behavior
}

If numeric precision changes, this condition might start behaving differently without any visible error.

That’s far more dangerous than a known limitation.

So JavaScript follows a rule that shapes almost every design decision:

Don’t break the web.

Adding Instead of Changing

Instead of modifying number, JavaScript introduced a new type:

bigint

This approach preserves existing behavior while giving developers a new tool.

Old code continues to work exactly the same.

New code can opt into precise integer arithmetic when needed.

It’s not about making the system perfect. It’s about evolving it safely.

Why BigInt Feels Strict

BigInt comes with rules that might feel restrictive at first.

You cannot mix it with regular numbers:

10n + 5 // ❌ error

You must be explicit:

10n + BigInt(5) // ✅

This isn’t a limitation by accident.

It’s a deliberate design choice to prevent subtle bugs caused by mixing two different numeric systems.

JavaScript is forcing you to be aware of which “world” you are working in.

Integer Math vs Decimal Math

BigInt only supports integers.

So operations behave differently:

5n / 2n // 2n

The result is truncated because fractions do not exist in the BigInt world.

This might feel surprising, but it’s consistent.

BigInt is not trying to replace number. It’s solving a different problem.

A useful way to think about it is:

Number handles flexible math, including decimals.

BigInt handles precise integer math, without approximation.

Where BigInt Actually Matters

BigInt becomes important in situations where precision is critical.

Large IDs in databases or distributed systems often exceed the safe integer limit.

Financial systems sometimes represent money as integers (like cents) to avoid floating-point errors.

Cryptographic algorithms rely on exact integer arithmetic.

Blockchain systems work with extremely large numeric values.

In these contexts, losing precision is not acceptable.

Where BigInt Doesn’t Fit

For everyday frontend work, BigInt is often unnecessary.

UI values like width, opacity, or percentages require decimals.

Most browser APIs and math utilities expect regular numbers.

BigInt also introduces friction when working with JSON or external APIs.

So it’s not a universal replacement. It’s a specialized tool.

A Language That Can’t Forget Its Past

BigInt is not just a feature. It’s a reflection of how JavaScript evolves.

JavaScript cannot easily remove or change old behavior, even if that behavior is imperfect.

Instead, it grows by adding new layers alongside the old ones.

You see this pattern everywhere:

• let and const alongside var
• class on top of prototypes
• BigInt next to number

The language becomes a collection of decisions made over time, each shaped by the need to stay compatible with what already exists.

A Better Way to See BigInt

It’s tempting to think of BigInt as a “better number”.

But it’s more accurate to think of it as a different numeric system.

One prioritizes flexibility and performance.

The other prioritizes precision and correctness.

And JavaScript doesn’t force you to choose one globally.

It asks you to choose intentionally, based on the problem you’re solving.

In the end, BigInt is less about fixing a flaw and more about respecting a constraint.

The constraint is that the web cannot be broken.

And everything in JavaScript, including its quirks, exists within that boundary.