Code That Learns as It Runs: Understanding JIT Compilation in JavaScript

When you run JavaScript, it doesn’t immediately try to be perfect.

It tries to be fast.

Not in execution—but in starting.

Your code begins running almost instantly.

No long compilation step.

No waiting.

And yet, somehow, after a while… it gets faster.

The same code.

The same logic.

But something has changed.

The Tension Inside Every Engine

There’s a quiet conflict happening behind the scenes.

On one side:

Start as quickly as possible.

On the other:

Run as efficiently as possible.

These goals don’t naturally align.

If you optimize everything upfront, you slow down startup.

If you don’t optimize at all, repeated code stays inefficient.

So the question becomes:

When is the right moment to optimize?

Not Before. Not After. During.

This is where JIT—Just-In-Time compilation—steps in.

Not as a separate phase.

But as a strategy.

Instead of deciding everything before execution…

the engine waits.

It begins by running your code in a simple way.

Then it watches.

The First Pass: Just Run It

At the beginning, your code is interpreted.

Line by line.

No deep assumptions.

This keeps things flexible.

Because at this stage, the engine doesn’t yet know what matters.

It doesn’t know which parts of your code will run once—

and which will run thousands of times.

So it doesn’t overcommit.

The Shift: Watching for Patterns

As your program runs, patterns start to emerge.

Some functions are called repeatedly.

Some paths are taken over and over again.

These are the “hot” parts of your code.

And the engine notices.

Not immediately.

But over time.

The Optimization: Making It Faster

Once something proves itself important, the engine changes its strategy.

It compiles that specific part into optimized machine code.

Now, instead of interpreting it every time…

it runs in a much faster form.

The code hasn’t changed.

But the way it runs has.

The Risk of Assumptions

But optimization comes with a cost.

To make code faster, the engine has to assume things.

For example:

That a function always receives numbers.

That a variable keeps the same type.

These assumptions make optimization possible.

But they also make it fragile.

When Reality Breaks the Pattern

If your code suddenly behaves differently—

those assumptions break.

process(1)
process("hello")
process(true)

Now the function is no longer predictable.

The engine can’t rely on a single optimized path.

So it does something interesting.

It steps back.

It discards the optimized version.

And returns to a safer, slower one.

This is called deoptimization.

A System That Adapts

This is what makes JIT powerful.

It doesn’t commit too early.

It doesn’t stay rigid.

It observes.

It adapts.

It optimizes what matters—

and lets go when reality changes.

A Different Way to Think About Execution

It’s easy to imagine JavaScript execution as something linear.

Code goes in.

Results come out.

But JIT reveals something deeper.

Execution is not fixed.

It evolves.

The engine is not just running your code.

It’s learning from it.

A Final Thought

JIT compilation doesn’t make your code faster by default.

It makes your code capable of becoming faster.

But only if your patterns are consistent.

Only if your behavior is predictable.

Because in the end, performance in JavaScript isn’t just about what you write.

It’s about how your code behaves over time—

and how well the engine can learn from it.