DEV Community: Vijay Thopate

🧠 JavaScript Hoisting

Vijay Thopate — Mon, 29 Dec 2025 08:09:29 +0000

🧠 JavaScript Hoisting

Vijay Thopate ・ Dec 29

#javascript

🧠 JavaScript Hoisting

Vijay Thopate — Mon, 29 Dec 2025 05:52:01 +0000

Most developers hear “hoisting” and think:

“Variables get moved to the top.”

But that’s not what really happens.

Hoisting is about how JavaScript allocates memory before execution, and how variables and functions behave differently during that phase.

Let’s break it down in a simple, intuitive, story-driven way — and then connect it to how the JavaScript engine actually works.

🎯 What is Hoisting?

Hoisting is the process where JavaScript:

1️⃣ scans your code before execution
2️⃣ allocates memory for variables & functions
3️⃣ sets initial values (depending on keyword)

Execution happens only after this.

Nothing is physically “moved”.

It only appears that way.

🏫 Real-Life Analogy #1 — Classroom Attendance Register

Before teaching begins, a teacher:

✔ writes all students’ names in the attendance register
❌ but attendance is not yet marked

Names exist — but values are empty.

Later during class:

✔ attendance is marked
✔ details are filled in

That is exactly how hoisting works.

Stage	Classroom	JavaScript
Before class	write names	store variables & functions in memory
During class	mark attendance	assign values during execution

So when a name is called early,
it exists — but may not have a value yet.

That’s why var becomes undefined.

🍽 Real-Life Analogy #2 — Restaurant Kitchen Plates

Before customers arrive:

✔ plates are kept on tables
✔ table numbers are assigned
❌ food is not yet served

Plates exist — but are empty.

Same with var:

Variable exists → but value is undefined

let and const are like plates that are:

🔒 covered until the right time (TDZ)

We’ll come back to this.

⚙️ How JavaScript Executes Code (2-Phase Model)

Whenever JS runs your code, it creates:

1️⃣ Memory Creation Phase (Hoisting Phase)

function declarations stored fully
variables allocated in memory

2️⃣ Execution Phase

code runs line-by-line
values get assigned
functions get executed

🧩 What Actually Gets Hoisted?

Let’s see behavior for each keyword.

✅ Function Declarations — Fully Hoisted

sayHi();

function sayHi() {
  console.log("Hello");
}

Output:

Hello

Because:

✔ function body is stored in memory
✔ can be called before declaration

This is the useful side of hoisting.

⚠️ `var` — Hoisted but Initialized as `undefined`

console.log(a);
var a = 10;

Output:

undefined

Memory phase:

a = undefined

Execution phase:

a = 10

This often leads to subtle bugs.

🔒 `let` & `const` — Hoisted but NOT initialized (TDZ)

console.log(x);
let x = 10;

Throws:

ReferenceError

Because variable is in

🟡 Temporal Dead Zone (TDZ)

Meaning:

variable exists in memory
but cannot be accessed until declared

This behavior makes code safer.

🧱 Function-Scoped vs Block-Scoped (Why `var` Causes Bugs)

🟡 `var` is Function-Scoped

function test() {
  if (true) {
    var x = 10;
  }
  console.log(x);
}
test();

Output:

x escaped the block 😬

Because:

var ignores { } blocks and lives across the function

🟢 `let` & `const` are Block-Scoped

function test() {
  if (true) {
    let y = 20;
  }
  console.log(y);
}
test();

Output:

ReferenceError

Behavior is predictable & safer.

🧨 Real-World Bug — Why `var` is Discouraged

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i));
}

Output:

3
3
3

Because:

var creates one shared i
loop finishes
async callbacks run later
i = 3

`let` Fixes It

for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i));
}

Output:

0
1
2

Because:

✔ new i is created per iteration
✔ each callback receives correct value

🧠 Why `let` & `const` Were Introduced

They were added to:

✔ prevent hidden hoisting bugs
✔ avoid accidental redeclaration
✔ provide predictable block scope
✔ fix async & loop bugs

🟡 Why TDZ Was Introduced

TDZ forces:

“Declare variable before using it.”

This prevents:

❌ silent undefined behavior
❌ accidental access before initialization
❌ hard-to-debug runtime errors

Instead — JavaScript loudly warns you 👍

🧪 Function Declarations vs Function Expressions

Function Declaration (Hoisted)

hello();
function hello() {}

Works.

Function Expression (NOT hoisted as function)

greet();
var greet = function() {};

Output:

TypeError: greet is not a function

Because:

greet is hoisted as undefined
function assigned later

Arrow Functions behave the same

sayHi();
const sayHi = () => {};

ReferenceError (TDZ)

📌 Summary Table — What Gets Hoisted?

Type	Hoisted?	Initial Value	Safe?
function declaration	✅ yes	full function	👍 useful
var	✅ yes	undefined	⚠️ risky
let	✅ yes	TDZ (not initialized)	✅ safe
const	✅ yes	TDZ + must assign	✅ safe
function expression	⚠️ variable only	undefined	❌
arrow function	⚠️ variable only	TDZ	❌

🧠 Key Takeaways

Hoisting exists because JS engine:

✔ prepares memory before execution
✔ stores declarations first
✔ executes later

Function hoisting is useful.

var hoisting is confusing.

Modern JavaScript prefers:

✔ let for variables
✔ const for constants
✔ declare before using

Because clean code > clever tricks.

✍️ Closing Thought

Hoisting is not a magical behavior.

It is simply how JavaScript:

builds memory first
and runs code afterward

Once you understand:

execution context
scope
TDZ
call stack

JavaScript stops feeling surprising —
and starts feeling logical.

Solana Networking Unpacked: From TCP to QUIC, Quinn, and Transaction Flow

Vijay Thopate — Thu, 27 Nov 2025 13:34:22 +0000

1. From cars and roads to packets and streams

A good way to think about the internet is as a road system.

The road is the network.
Your messages (web pages, transactions, videos) are like groups of cars.
Each car is a small chunk of data called a packet.

Big messages are split into many packets, sent across the network, and then put back together on the other side. Some cars may take slightly different routes, get delayed, or even get lost and re‑sent.

On top of these packets, we build streams: ordered flows of bytes between two endpoints. A stream is like a dedicated lane between two cities where cars go in order. Protocols like TCP and QUIC manage these streams.

2. Application vs transport: who does what?

Networking is usually described in layers. Two important ones for Solana and QUIC are:

The application layer: this is where the meaning of the data lives. Examples: HTTP, gRPC, your custom Solana bot protocol. It defines things like URLs, JSON payloads, “GET /price”, etc.
The transport layer: this is the delivery service. It decides how to move bytes reliably from one process on machine A to one process on machine B (using ports, congestion control, retransmissions, etc.). This is where TCP, UDP, and QUIC live.

In simple terms:

Application layer = “What are we saying?”
Transport layer = “How do we get the message there in one piece (or fast enough)?”

When you send an HTTP request from a browser, HTTP builds the message at the application layer, then hands it to TCP or QUIC at the transport layer, which chops it into packets and sends them on the wire.

3. TCP, UDP, QUIC

Using the road analogy:

TCP is like a careful shipping company. It guarantees that every box arrives, in order, and will re‑ship anything that gets lost. You pay with extra time and overhead.
UDP is like dropping flyers from a plane. It’s very fast and simple, but if some get lost, nobody re‑sends them for you.
QUIC is like a modern shipping company built on top of the same road as UDP, but it adds its own smarts: encryption, multiple lanes (streams), congestion control, and fast setup — all in user space.

All three are transport protocols. Applications (like browsers or Solana clients) choose which one they use.

4. Head‑of‑line blocking: cars stuck in a single lane

Head‑of‑line (HOL) blocking happens when everything behind the front car in a single lane is forced to wait, even though the road ahead might be free.

With TCP:

Packets must be delivered to the application in order.
If packet 3 is lost but packets 4, 5, 6 arrive, TCP holds 4–6 until 3 is retransmitted. One missing packet at the “head of the line” blocks everything behind it.

With HTTP/2 over TCP, many logical HTTP streams share that one TCP stream, so a lost TCP packet can stall all HTTP streams temporarily.

QUIC fixes this by making streams visible at the transport layer:

Each request/response can be its own QUIC stream.
If packets for stream A are lost, packets for stream B can still be delivered immediately. Loss on one stream does not block others.

This is a big reason HTTP/3 (HTTP over QUIC) performs better on lossy or mobile networks.

5. HTTP/1, HTTP/2, HTTP/3 in one picture

Very briefly:

HTTP/1.1 + TCP
- One request per connection (or fragile pipelining).
- Browsers open many TCP connections to the same host to parallelize.
HTTP/2 + TCP
- Multiplexes many HTTP streams over one TCP connection.
- Fixes head‑of‑line at HTTP level, but still suffers from TCP HOL blocking underneath.
HTTP/3 + QUIC
- Runs HTTP on top of QUIC streams.
- Reduces HOL blocking and speeds up connection setup (0‑RTT in many cases).

HTTP/3 is the application protocol; QUIC is the transport it runs on. They are not the same thing.

6. QUIC and Quinn

QUIC started as a Google experiment around 2012 and was later standardized by the IETF in 2021 (RFC 9000 and friends).

It runs over UDP but implements its own reliability, encryption (TLS 1.3), congestion control, and multiplexed streams.

Quinn is an async Rust implementation of QUIC:

It’s a Rust library that lets you open QUIC connections, create streams, and send/receive data without implementing QUIC yourself.
Conceptually, it fills the same role as a TCP library, but for QUIC. Your Rust app uses Quinn at the transport layer and builds higher‑level protocols (like HTTP/3, custom Solana bots, etc.) on top.

7. Solana basics: who does what?

Solana is a high‑throughput blockchain that leans heavily on fast networking. Some core concepts:

Leader: The validator currently responsible for producing a block in a given slot. It collects transactions, executes them, and broadcasts the resulting block.
TPU (Transaction Processing Unit): The internal pipeline inside a validator that ingests, verifies, and executes transactions, then packages them into entries and shreds.
Turbine: The block propagation protocol. It splits blocks into small pieces (shreds) and spreads them through a tree of validators, inspired by BitTorrent. This makes block distribution scalable.
Gulf Stream: Solana’s mempool‑less transaction forwarding. Rather than a big global mempool, transactions are rapidly pushed toward current and future leaders so they’re ready to go when a leader’s slot starts.
RPC nodes: Nodes that expose JSON‑RPC to wallets, apps, bots. They receive user transactions (sendTransaction), forward them into the network, and answer read queries (getBalance, getProgramAccounts, etc.).
Trading bots / bots: Programs that monitor state and send transactions automatically, often latency‑sensitive (arbitrage, sniping, liquidations). They care deeply about network path and congestion.
Indexers: Off‑chain services that read blocks and account changes, then store them in databases or search systems so dapps can query complex views quickly.

Under the hood, Solana historically used UDP heavily for both transaction ingestion and block propagation because it’s low‑overhead and fast.

8. How QUIC enters Solana

Raw UDP is like throwing millions of letters at a post office with no queue or capacity limit. It’s fast, but the receiver has no natural way to slow you down or prioritize traffic.

Solana hit limits with this model:

Leaders could be flooded with more packets than they can realistically process.
There was no built‑in backpressure or fairness across senders.

So Solana introduced QUIC for transaction ingestion:

Instead of sending transactions as one‑shot UDP packets, RPC nodes and serious bots open QUIC connections to the leader’s TPU.
Transactions are sent over these QUIC connections, gaining:
- Per‑connection flow control and congestion control,
- Some accountability per sender,
- Better handling of packet loss and reordering.

Internally, Solana’s QUIC stack is similar in spirit to Quinn: it’s an implementation of the QUIC protocol, tuned for Solana’s traffic patterns.

9. One Solana transaction’s journey (with QUIC)

Here’s a simple end‑to‑end story for a single transaction.

Step 1: Wallet or bot → RPC

You click “Send” in a wallet or your bot decides to trade.
The client builds and signs a Solana transaction and sends it to an RPC endpoint via HTTP or WebSocket.

The RPC node is the gateway between regular web traffic and Solana’s validator network.

Step 2: RPC / bot → leader over QUIC

The RPC node (or a latency‑sensitive trading bot) knows who the current or upcoming leader is, using Solana’s leader schedule and cluster info.
It opens (or reuses) a QUIC connection to the leader’s TPU QUIC port. Over this connection, it streams many transactions.

Think of this as a high‑speed, controlled lane from the RPC/bot to the leader, instead of spamming one‑off UDP packets.

Step 3: Leader’s TPU pipeline

Inside the leader:

Ingress stage: QUIC packets arrive, transactions are extracted, signatures are checked (often on GPUs), duplicates are removed, and priority rules (stake‑weighted QoS, fees) decide what moves forward.
Banking/execution stage: Valid transactions are executed in parallel (Sealevel) against the current state, producing a sequence of entries that will form the block.

If your transaction passes all checks and wins the priority game, it’s now part of the block being built for that slot.

Step 4: Gulf Stream and forwarding

Gulf Stream constantly pushes transactions toward current and future leaders, so when a validator becomes leader, it already has a queue of pending transactions ready to process.
This design removes the classic global mempool bottleneck and reduces confirmation latency.

In practice, your transaction may hop via several validators before it reaches the right leader, but Gulf Stream ensures it gets pushed in the right direction quickly.

Step 5: Turbine block propagation

Once the leader finalizes a block that includes your transaction:

The block is broken into shreds and encoded with erasure coding.
Turbine organizes validators into a tree. The leader sends different shreds to its direct neighbors; they forward to their neighbors, and so on, until everyone can reconstruct the full block.

This works a bit like a torrent swarm for each block: no single node needs to talk to every other node.

Step 6: Other validators verify and vote

Non‑leader validators reassemble the block, re‑execute its transactions to verify state, and then cast votes (as vote transactions) if everything checks out.
As enough stake‑weighted votes land on that block and its descendants, the network gains confidence and finality. Indexers record the change, and bots and users see the updated state.

At this point, your transaction is effectively final on Solana.

10. Why this matters for builders

For a Solana builder, understanding this stack gives you levers to build better systems:

Networking choices (TCP vs UDP vs QUIC) change how fair and robust the chain is under heavy bot traffic.
QUIC and Quinn give you tools to build high‑performance bots, relayers, or custom infra in Rust that speak the same language as Solana’s validators.
Concepts like leaders, Gulf Stream, Turbine, and the TPU explain where latency comes from and where optimizations or MEV strategies live.

You can think of the whole system as many lanes of cars (packets and streams) feeding an extremely fast toll booth (the leader’s TPU), which then fans out receipts of what happened (blocks via Turbine) to the rest of the network.

DEV Community: Vijay Thopate

🧠 JavaScript Hoisting

🧠 JavaScript Hoisting

Vijay Thopate ・ Dec 29

🧠 JavaScript Hoisting

🎯 What is Hoisting?

🏫 Real-Life Analogy #1 — Classroom Attendance Register

🍽 Real-Life Analogy #2 — Restaurant Kitchen Plates

⚙️ How JavaScript Executes Code (2-Phase Model)

1️⃣ Memory Creation Phase (Hoisting Phase)

2️⃣ Execution Phase

🧩 What Actually Gets Hoisted?

✅ Function Declarations — Fully Hoisted

⚠️ var — Hoisted but Initialized as undefined

🔒 let & const — Hoisted but NOT initialized (TDZ)

🧱 Function-Scoped vs Block-Scoped (Why var Causes Bugs)

🟡 var is Function-Scoped

🟢 let & const are Block-Scoped

🧨 Real-World Bug — Why var is Discouraged

let Fixes It

🧠 Why let & const Were Introduced

🟡 Why TDZ Was Introduced

🧪 Function Declarations vs Function Expressions

Function Declaration (Hoisted)

Function Expression (NOT hoisted as function)

Arrow Functions behave the same

📌 Summary Table — What Gets Hoisted?

🧠 Key Takeaways

✍️ Closing Thought

Solana Networking Unpacked: From TCP to QUIC, Quinn, and Transaction Flow

1. From cars and roads to packets and streams

2. Application vs transport: who does what?

3. TCP, UDP, QUIC

4. Head‑of‑line blocking: cars stuck in a single lane

5. HTTP/1, HTTP/2, HTTP/3 in one picture

6. QUIC and Quinn

7. Solana basics: who does what?

8. How QUIC enters Solana

9. One Solana transaction’s journey (with QUIC)

Step 1: Wallet or bot → RPC

Step 2: RPC / bot → leader over QUIC

Step 3: Leader’s TPU pipeline

Step 4: Gulf Stream and forwarding

Step 5: Turbine block propagation

Step 6: Other validators verify and vote

10. Why this matters for builders

References and Further Reading

Networking Basics

QUIC and Quinn

Solana Core Concepts and Networking

⚠️ `var` — Hoisted but Initialized as `undefined`

🔒 `let` & `const` — Hoisted but NOT initialized (TDZ)

🧱 Function-Scoped vs Block-Scoped (Why `var` Causes Bugs)

🟡 `var` is Function-Scoped

🟢 `let` & `const` are Block-Scoped

🧨 Real-World Bug — Why `var` is Discouraged

`let` Fixes It

🧠 Why `let` & `const` Were Introduced