Forem: CodeScoop.dev

Real-Time on the Frontend - SSE, WebSockets & Polling

Yogesh Yadav — Sun, 03 May 2026 13:58:37 +0000

Real-time doesn't always mean WebSockets. Picking the right tool changes everything.

In this article we'll cover when polling is actually the right answer, why SSE is the most underrated real-time technology on the web, when WebSockets are genuinely worth the complexity, how to handle reconnections properly, lessons from building real-time features at scale and a clear decision framework so you stop defaulting to WebSockets out of habit.

Every time a developer hears "real-time", the next word out of their mouth is usually "WebSockets."

I get it. WebSockets feel like the serious, production-grade choice. Polling feels naive. SSE feels like something you read about once and forgot. So the default becomes WebSockets and teams end up maintaining infrastructure complexity they didn't need for a problem that SSE would have solved in 30 lines.

I've built real-time features on platforms handling more than 10 million active users. Subscription verification flows, live event score updates, notification systems. Different problems, different tools. And the most important lesson I've taken from all of it is this: pick the simplest technology that actually solves the problem.

This article will help you do that.

Polling - Not Always the Wrong Answer

Polling gets dismissed quickly. "Just use WebSockets" is the usual response. But polling has a place and understanding when it's appropriate saves you from over-engineering.

Short Polling

The simplest form. Make a request every N seconds, get a response, repeat.

function startPolling(interval = 5000) {
  return setInterval(async () => {
    const data = await fetch('/api/status').then(res => res.json())
    updateUI(data)
  }, interval)
}

This works fine when:

The data changes infrequently and slight delays are acceptable.
You have a small number of concurrent users.
The implementation complexity budget is low and you need something working fast.

Where it falls apart is scale. If 100,000 users are polling every 5 seconds, that's 20,000 requests per second hitting your server for data that probably hasn't changed. At that point polling isn't simple anymore - it's expensive.

Smarter Polling

If you're going to poll, at least do it intelligently. Back off when the tab is hidden, increase the interval when responses show no change, stop entirely when the user is inactive.

function smartPoll(fetchFn, options = {}) {
  const { baseInterval = 5000, maxInterval = 60000 } = options
  let currentInterval = baseInterval
  let timeoutId = null

  async function poll() {
    if (document.hidden) {
      timeoutId = setTimeout(poll, maxInterval)
      return
    }

    const data = await fetchFn()
    currentInterval = data.changed ? baseInterval : Math.min(currentInterval * 1.5, maxInterval)
    timeoutId = setTimeout(poll, currentInterval)
  }

  poll()

  return () => clearTimeout(timeoutId)
}

This alone can cut unnecessary requests significantly without changing the fundamental approach.

When to use polling: low-frequency updates, small user base, dashboard data that refreshes every minute or so, situations where you need something working today and can revisit later.

SSE - The Underrated Middle Ground

Server-Sent Events is the technology most developers skip over on their way to WebSockets. That's a mistake.

SSE is a one-directional, HTTP-native protocol. The server pushes data to the client over a persistent connection. The client listens. That's it.

What makes SSE genuinely compelling:

It runs over regular HTTP. No protocol upgrade, no special infrastructure, no load balancer configuration changes.
The browser handles reconnection automatically. If the connection drops, the browser retries with the last event ID so you don't miss events.
It works through HTTP/2 multiplexing, meaning multiple SSE connections share a single TCP connection.
It's dramatically simpler to implement than WebSockets on both the client and server side.

function connectToEventStream(url, handlers) {
  const eventSource = new EventSource(url, { withCredentials: true })

  eventSource.onopen = () => {
    console.log('SSE connection established')
  }

  eventSource.onmessage = (event) => {
    const data = JSON.parse(event.data)
    handlers.onMessage(data)
  }

  eventSource.onerror = (err) => {
    if (eventSource.readyState === EventSource.CLOSED) {
      handlers.onClose()
    }
  }

  // Listen to named events
  eventSource.addEventListener('subscription-update', (event) => {
    handlers.onSubscriptionUpdate(JSON.parse(event.data))
  })

  return () => eventSource.close()
}

The server side is equally straightforward. Any server that can keep an HTTP connection alive and stream data to it can serve SSE. No WebSocket library needed.

// Express example
app.get('/events', (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream')
  res.setHeader('Cache-Control', 'no-cache')
  res.setHeader('Connection', 'keep-alive')

  const sendEvent = (eventName, data) => {
    res.write(`event: ${eventName}\n`)
    res.write(`data: ${JSON.stringify(data)}\n\n`)
  }

  // Send initial state
  sendEvent('connected', { timestamp: Date.now() })

  // Clean up on disconnect
  req.on('close', () => {
    // Remove this client from your subscriber list
  })
})

Where SSE Shines at Scale

I've used SSE for subscription verification flows where the client needs to know the moment a payment has been confirmed on the backend. The user completes a payment, the frontend opens an SSE connection and the moment the backend confirms the transaction, it pushes an event. The client reacts immediately.

No polling loop hammering the endpoint. No WebSocket infrastructure. Just an HTTP connection that the server writes to when something happens.

SSE is the right tool for: notifications, live feed updates, subscription and payment status, progress tracking for long-running operations, any scenario where data flows server-to-client and you don't need the client to send messages back in real time.

The one real limitation: SSE is one-directional. The client cannot send data back over the same connection. If you need bidirectional communication, you need WebSockets.

WebSockets - When You Actually Need Them

WebSockets give you a full-duplex connection. Both the client and server can send messages at any time over a single persistent connection. That's genuinely powerful and genuinely more complex to operate.

class WebSocketClient {
  constructor(url) {
    this.url = url
    this.socket = null
    this.reconnectAttempts = 0
    this.maxReconnectAttempts = 5
    this.listeners = new Map()
  }

  connect() {
    this.socket = new WebSocket(this.url)

    this.socket.onopen = () => {
      console.log('WebSocket connected')
      this.reconnectAttempts = 0
    }

    this.socket.onmessage = (event) => {
      const message = JSON.parse(event.data)
      const handler = this.listeners.get(message.type)
      if (handler) handler(message.payload)
    }

    this.socket.onclose = () => {
      this.reconnect()
    }

    this.socket.onerror = (err) => {
      console.error('WebSocket error', err)
    }
  }

  send(type, payload) {
    if (this.socket?.readyState === WebSocket.OPEN) {
      this.socket.send(JSON.stringify({ type, payload }))
    }
  }

  on(type, handler) {
    this.listeners.set(type, handler)
  }

  reconnect() {
    if (this.reconnectAttempts >= this.maxReconnectAttempts) {
      console.error('Max reconnect attempts reached')
      return
    }

    const delay = Math.min(1000 * 2 ** this.reconnectAttempts, 30000)
    this.reconnectAttempts++

    setTimeout(() => this.connect(), delay)
  }

  disconnect() {
    this.socket?.close()
  }
}

WebSockets are the right tool for:

Chat and messaging - messages flow in both directions in real time.
Collaborative editing - multiple users editing the same document simultaneously.
Live gaming - state needs to sync between players with minimal latency.
Live auctions or trading - both the server and client are pushing updates constantly.

What most tutorials don't tell you about WebSockets:

Load balancers need sticky sessions or a pub/sub layer. A WebSocket connection is stateful - it lives on one server instance. If you're running multiple server instances behind a load balancer, a message published on instance A won't reach clients connected to instance B unless you have a message broker like Redis pub/sub in between.

At scale, this infrastructure cost is real. It's manageable, but it's not free, and it's worth knowing about before you commit to WebSockets for a use case that SSE would have handled.

Reconnection - The Part Everyone Gets Wrong

Every real-time implementation needs to handle disconnections. Networks drop. Servers restart. Mobile users switch between WiFi and cellular. If your reconnection logic is wrong, users silently stop receiving updates with no indication that anything is broken.

A few things that matter:

Exponential backoff with jitter. Don't retry on a fixed interval. If your server goes down and 100,000 clients all retry every 5 seconds in perfect synchrony, they'll create a thundering herd the moment the server comes back up.

function getReconnectDelay(attempt) {
  const base = Math.min(1000 * 2 ** attempt, 30000)
  const jitter = Math.random() * 1000
  return base + jitter
}

The jitter spreads reconnection attempts across time so your server isn't hit by a simultaneous spike.

Track the last received event. For SSE, the browser does this for you with the Last-Event-ID header. For WebSockets, you need to implement this yourself. When you reconnect, tell the server where you left off so it can replay missed events.

Distinguish between clean closes and unexpected drops. A user navigating away is a clean close - don't reconnect. A network error is unexpected - do reconnect. Handle them differently.

Show the user when the connection is lost. A silent failure is worse than a visible one. If the real-time connection drops and doesn't recover quickly, tell the user. A small "reconnecting…" indicator is far better than them wondering why the live scores stopped updating.

Lessons From Building Real-Time at Scale

A few things you learn when real-time features are running for millions of users that don't show up in tutorials:

Connection count is a resource. Every open SSE or WebSocket connection holds state on the server. At scale, you need to think about connection limits, memory per connection and what happens when a deployment causes all connections to drop and reconnect simultaneously.

Health checks matter. Long-lived connections can appear alive to both sides while being silently broken in the middle - a dropped connection that neither end detected. Implement a heartbeat: the server sends a ping event every 30 seconds, the client expects it. If it doesn't arrive, reconnect.

// Server heartbeat
setInterval(() => {
  clients.forEach(client => {
    client.write('event: ping\ndata: {}\n\n')
  })
}, 30000)

// Client - restart connection if no ping received
let lastPing = Date.now()

eventSource.addEventListener('ping', () => {
  lastPing = Date.now()
})

setInterval(() => {
  if (Date.now() - lastPing > 45000) {
    eventSource.close()
    reconnect()
  }
}, 10000)

Authentication on long-lived connections needs thought. Tokens expire. If a user's access token expires while they have an open WebSocket connection, how do you handle that? You need a mechanism to refresh the token and either send it over the existing connection or re-establish with a new one.

Test with realistic concurrency. A real-time feature that works perfectly with 10 concurrent connections can behave completely differently with 10,000. Load test before you ship.

What Else Is Out There

WebRTC

WebRTC is a different category entirely. Where SSE and WebSockets are server-client protocols, WebRTC enables peer-to-peer communication directly between browsers. Audio, video and data can flow between clients without going through your server.

If you're building video calling, live audio or peer-to-peer file sharing, WebRTC is the right tool. It's not a replacement for SSE or WebSockets for server-push use cases - it solves a fundamentally different problem.

WebTransport

WebTransport is a newer protocol built on HTTP/3 and QUIC. It offers lower latency than WebSockets, supports both reliable and unreliable message delivery and handles connection migration better on mobile networks. It's promising, but browser support is still maturing. Worth keeping an eye on for the next few years.

GraphQL Subscriptions

If your stack uses GraphQL, subscriptions give you real-time updates through a familiar query interface. Under the hood they typically run over WebSockets. Useful if you're already invested in GraphQL and want real-time without adding a separate protocol layer.

How to Pick the Right Approach

Here's the decision framework I use:

Do you need the client to send messages to the server in real time?

No - SSE is probably enough. Start there.
Yes - WebSockets.

How frequently does data change?

Every few minutes or less - polling with a sensible interval.
Continuously or on server events - SSE or WebSockets.

What's your infrastructure complexity budget?

Low - polling or SSE. Both work over standard HTTP.
Higher - WebSockets, with the understanding that you'll need to handle load balancing and state carefully.

Do you need peer-to-peer communication?

Yes - WebRTC.
No - SSE or WebSockets.

Start simple. Polling is not embarrassing. SSE handles more use cases than most developers realize. WebSockets are powerful but come with operational overhead that you should only take on when you genuinely need what they offer.

The real-time feature that works reliably in production is always better than the one built with the most impressive technology.

Final Thoughts

Real-time on the frontend is not a single technology decision. It's a series of decisions, made per feature, based on what that feature actually needs.

SSE is HTTP-native, automatically reconnecting and dramatically simpler than WebSockets for one-directional data flows. Most real-time use cases are one-directional. Start there.

Use WebSockets when you genuinely need bidirectional communication. Understand the infrastructure implications before you commit.
And never underestimate polling for the right use case. At low frequency and low scale, it's often the most maintainable solution you can ship.

Pick the simplest tool that solves the problem. Your future self - and the engineer who maintains this after you - will thank you.

Have thoughts or questions on real-time frontend? Drop them in the comments, always happy to discuss.

This article is part of the Frontend at Scale series.

Frontend Security - What Your Browser Is Quietly Protecting You From

Yogesh Yadav — Sun, 26 Apr 2026 11:45:57 +0000

The browser is doing more security work than you realize. Here's what happens when you accidentally get in its way.

In this article we'll cover how XSS actually happens in real frontend codebases, how CSRF works and where the browser's default protections break down, how clickjacking works and how one header stops it, what Content Security Policy actually does and how to implement it without breaking your app, and the CORS misconfigurations that create vulnerabilities while feeling like security.

Frontend security has a reputation for being someone else's problem. The backend handles auth, the infrastructure team handles firewalls and the frontend just renders what it's given.

That mindset is expensive.

I've worked on platforms handling more than 10 million active users. At that scale, a single security misconfiguration isn't a bug report - it's an incident. And the uncomfortable truth is that most of the vulnerabilities I've seen on the frontend weren't sophisticated attacks. They were gaps left behind by developers who didn't know the browser was already protecting them and accidentally turned that protection off.

This article is about understanding what the browser does for you by default, so you never accidentally undo it.

XSS - The Attack That Lives in Your Own Code

Cross-Site Scripting is the most common frontend vulnerability. The idea is simple: an attacker finds a way to get malicious JavaScript to run in your page, in your users' browsers, with access to everything your page has access to - cookies, localStorage, DOM, API tokens.

The most important thing to understand about XSS is that it doesn't require a sophisticated attacker. It requires a place in your codebase where user-controlled content is rendered without sanitization.

// This is all it takes
document.getElementById('username').innerHTML = userInput

If userInput contains <script>alert(document.cookie)</script> that script runs. Game over.

Modern frameworks help significantly here. React, Vue, and Angular all escape output by default. When you write {userInput} in JSX, React treats it as text, not HTML. That's the browser's XSS protection working through the framework.

The danger is when you deliberately bypass it:

// This bypasses React's built-in escaping
<div dangerouslySetInnerHTML={{ __html: userContent }} />

dangerouslySetInnerHTML exists for legitimate reasons - rendering rich text, markdown output, CMS content. But every time you use it, you're taking on the responsibility of sanitizing that content yourself.

If you need to render HTML from an untrusted source, sanitize it first:

import DOMPurify from 'dompurify'

const clean = DOMPurify.sanitize(userContent)
// Now safe to render

DOMPurify strips anything that could execute JavaScript while preserving legitimate HTML structure. At scale, this belongs in a shared utility, not copied across components.

The other XSS surface most teams miss: third-party scripts.

Every analytics library, chat widget, and ad script you load is running JavaScript in your page with the same privileges as your own code. If any of those scripts are compromised - through a supply chain attack on the npm package or a hijacked CDN - your users are exposed.

This is where Content Security Policy becomes critical, which we'll cover shortly.

CSRF - The Attack the Browser Already Mostly Fixed

Cross-Site Request Forgery works like this: a user is logged into your platform. They visit a malicious site. That site silently makes a request to your platform's API - a request that carries the user's cookies automatically, because that's how cookies work.

If your API trusts cookie-authenticated requests without verifying their origin, the attacker can perform actions on behalf of the user without them knowing.

The browser has quietly been fixing this for years through the SameSite cookie attribute.

Set-Cookie: session=abc123; SameSite=Lax; Secure; HttpOnly

SameSite=Lax tells the browser: only send this cookie on requests that originate from the same site or on top-level navigation. Cross-site requests from a malicious page won't carry the cookie.

SameSite=Strict is even more restrictive - the cookie won't be sent on any cross-site request, including navigations. Good for sensitive session cookies.

Most modern browsers now default to SameSite=Lax even if you don't set it explicitly. That's the browser protecting you without you asking.

Where this breaks down:

If your frontend and API are on different domains - app.yourplatform.com and api.yourplatform.com - cookie handling gets more complex. Subdomains are generally considered same-site, but cross-domain setups are not.

If you're using token-based auth with the Authorization header instead of cookies, CSRF is largely not your problem. Browsers don't automatically attach Authorization headers to cross-site requests the way they do with cookies.

But if you're mixing both - cookies for session management and tokens for API calls - understand exactly what each request is sending and why.

Clickjacking - The Invisible Iframe Attack

Clickjacking is straightforward in concept. An attacker embeds your platform in an invisible iframe on their site, positioned perfectly over a button the attacker wants you to click. You think you're clicking something on the attacker's page. You're actually clicking something on yours.

On a platform with payment flows, subscription management or any destructive actions, this is a real risk.

One HTTP header stops it entirely:

X-Frame-Options: DENY

Or the more modern equivalent via Content Security Policy:

Content-Security-Policy: frame-ancestors 'none'

DENY means your page cannot be embedded in any iframe, on any site. If you need to allow embedding on specific trusted domains:

Content-Security-Policy: frame-ancestors 'self' https://trusted-partner.com

This is one of those protections that takes 30 seconds to implement and eliminates an entire category of attack. There is almost no reason not to have it.

Content Security Policy - The Most Powerful Tool Nobody Uses

CSP is the most underutilized browser security feature in frontend development. It's also the most powerful.

A Content Security Policy is a HTTP header that tells the browser exactly what it's allowed to load and execute on your page. Scripts, styles, images, fonts, iframes - you define the allowlist. Anything not on the list gets blocked.

Content-Security-Policy: 
  default-src 'self';
  script-src 'self' https://cdn.trusted.com;
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  font-src 'self' https://fonts.gstatic.com;
  frame-ancestors 'none'

What this does:

default-src 'self' - by default, only load resources from your own domain.
script-src 'self' https://cdn.trusted.com - scripts can only come from your domain or this specific CDN. An injected script from anywhere else is blocked by the browser before it executes.
frame-ancestors 'none' - replaces X-Frame-Options, prevents clickjacking.

This is your XSS backstop. Even if an attacker injects a script tag into your page, if the script source isn't on your allowlist, the browser won't run it.

Why most teams don't implement it:

CSP is hard to get right, especially on established codebases. Inline scripts, eval usage and dynamically injected styles all conflict with a strict policy. The error messages aren't always helpful.

The right approach is to start in report-only mode:

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-violations

This enforces nothing but logs every violation. You can see exactly what your existing codebase would break before you flip the switch. Run it for a few weeks, fix the violations, then move to enforcement.

At scale, CSP is not optional. It's the difference between a contained incident and a platform-wide compromise.

CORS - The Misconfigurations That Feel Like Security

CORS - Cross-Origin Resource Sharing - is widely misunderstood. Most developers encounter it as an error to fix, not a security mechanism to understand.

Here's the core idea: browsers block JavaScript from reading responses from a different origin unless that origin explicitly allows it. CORS headers on the server tell the browser what's permitted.

The misconfig that creates vulnerabilities:

Access-Control-Allow-Origin: *

This tells the browser any site can read responses from your API. For truly public, unauthenticated APIs this is fine. For an API that returns user data or accepts authenticated requests, this is a problem.

An even worse pattern:

// On the server - don't do this
const origin = req.headers.origin
res.setHeader('Access-Control-Allow-Origin', origin)
res.setHeader('Access-Control-Allow-Credentials', 'true')

This dynamically reflects whatever origin made the request and allows credentials. Effectively any site can make credentialed requests to your API and read the responses. This defeats the entire purpose of CORS.

The correct approach is an explicit allowlist:

const allowedOrigins = [
  'https://yourplatform.com',
  'https://app.yourplatform.com'
]

const origin = req.headers.origin
if (allowedOrigins.includes(origin)) {
  res.setHeader('Access-Control-Allow-Origin', origin)
}

CORS is not an authentication mechanism. It controls what the browser allows JavaScript to read. It does not stop direct requests made with curl, Postman or server-to-server calls. Your API still needs proper authentication and authorization regardless of CORS configuration.

What Developers Accidentally Break

The browser's security model is opt-out, not opt-in. Most of the protections are on by default. The problems happen when developers don't realize they're turning them off.

Using `target="_blank"` without `rel="noopener"`

Opening a link in a new tab with target="_blank" gives the new page a reference back to your page through window.opener. A malicious site opened this way can redirect your original tab.

<!-- Vulnerable -->
<a href="https://external.com" target="_blank">Link</a>

<!-- Safe -->
<a href="https://external.com" target="_blank" rel="noopener noreferrer">Link</a>

Modern browsers now default to noopener behavior for target="_blank", but it's still worth being explicit.

Disabling certificate warnings in development

Running your local dev server with a self-signed cert and clicking through browser security warnings trains developers to ignore those warnings. More importantly, configurations that disable certificate validation sometimes make their way into staging or production environments.

Putting secrets in frontend code

API keys, client secrets, internal endpoint URLs - these don't belong in frontend code. They end up in your JavaScript bundle, which is downloaded by every user and readable by anyone who opens DevTools. If a key needs to be kept secret, it belongs on the server.

Using `eval()` or `new Function()`

Beyond being a performance issue, eval executes arbitrary strings as JavaScript. If any user-controlled content reaches an eval call, it's an XSS vulnerability. CSP's script-src directive blocks eval by default for exactly this reason.

Final Thoughts

The browser is not your enemy. It's doing a significant amount of security work on your behalf, quietly on every page load. SameSite cookies, CORS restrictions, XSS escaping in frameworks, referrer policies - most of this just works if you don't interfere with it.

The job of a security-conscious frontend engineer is not to implement security from scratch. It's to understand what the browser already does, build on top of it and avoid accidentally disabling it.

At scale, that understanding is the difference between a platform your users can trust and one that's one misconfiguration away from an incident.

Know what the browser does for you. Don't get in its way.

Have thoughts or questions on frontend security? Drop them in the comments, always happy to discuss.

This article is part of the Frontend at Scale series.

Authentication on the Frontend - More Than Just Tokens

Yogesh Yadav — Sun, 19 Apr 2026 14:12:36 +0000

The decisions behind auth are more consequential than most developers realize.

In this article we'll cover how token storage works and why the wrong choice creates real security vulnerabilities, how silent refresh keeps users logged in without interrupting their experience, how to handle session expiry gracefully, what actually happens during an OAuth flow, and the authentication decisions most frontend developers get wrong.

Authentication is one of those things that looks simple from the outside. User logs in, you get a token, you attach it to requests. Done.

Except it's not done. Not even close.

I've worked on platforms handling more than 10 million active users across multiple OTT applications. Authentication touches every single one of them. And the decisions you make at the frontend layer - where to store tokens, how to refresh them, how to handle expiry - have consequences that go well beyond a login form.

Get it wrong and you're looking at XSS vulnerabilities, session hijacking or users getting logged out mid-stream during a live event. At scale, any of those is a serious incident.

This article is about getting it right.

Token Storage - The Decision That Has the Most Security Consequences

When you authenticate a user and get back an access token, the first question is: where do you put it?

There are three common options. Each has real tradeoffs.

localStorage

This is the most common choice because it's the easiest. Persist the token, read it back on page load, attach it to requests. Simple.

The problem is XSS. If an attacker manages to inject malicious JavaScript into your page - through a compromised dependency, a third-party script or an unsanitized input - they can read everything in localStorage. Your token is gone. The attacker now has it.

// Any injected script can do this
const token = localStorage.getItem('access_token')
// Token is now in the attacker's hands

At scale, with multiple third-party scripts running on your platform, the XSS surface area is larger than you think.

httpOnly Cookies

The browser sets these cookies automatically on every request to your domain. JavaScript cannot read them. That means an XSS attack cannot steal them.

This sounds like the obvious winner, and for many server-rendered applications it is. But it comes with its own complexity. You need to think about CSRF protection, SameSite cookie attributes and cross-origin request handling. On a platform with multiple subdomains or a separate API domain, cookie configuration gets complicated quickly.

In-Memory Storage

This is the approach I consider most secure for single-page applications. Store the access token in a JavaScript variable, never in localStorage, never in a cookie readable by JavaScript.

let accessToken = null

export function setToken(token) {
  accessToken = token
}

export function getToken() {
  return accessToken
}

An XSS attack cannot read a JavaScript variable from another script's scope if you're careful about how you expose it. The token lives only in memory and disappears when the tab closes.

The tradeoff is that you lose persistence across page refreshes. Which is exactly why silent refresh exists.

Silent Refresh - Keeping Users Logged In Without Asking Them To

Access tokens are short-lived by design. Typically 15 minutes to an hour. That's intentional - if one gets stolen, the damage window is limited.

But you can't ask a user to log in again every hour. Especially on an OTT platform where they might be mid-stream during a live sports event.

Silent refresh solves this. The idea is straightforward: before the access token expires, use the refresh token to get a new one automatically, without any visible interruption to the user.

Here's the basic pattern:

let refreshTimeout = null

function scheduleTokenRefresh(expiresIn) {
  // Refresh 60 seconds before expiry
  const refreshIn = (expiresIn - 60) * 1000
  refreshTimeout = setTimeout(async () => {
    try {
      const newToken = await refreshAccessToken()
      setToken(newToken.accessToken)
      scheduleTokenRefresh(newToken.expiresIn)
    } catch (err) {
      // Refresh failed, session has expired
      handleSessionExpiry()
    }
  }, refreshIn)
}

A few things worth noting here:

The refresh token should be stored in an httpOnly cookie. It's longer-lived and more sensitive than the access token. You don't want JavaScript touching it directly. The server reads it from the cookie and issues a new access token.

Handle the case where the tab has been in the background. Browsers throttle timers in inactive tabs. When the user comes back to the tab, check if the token has already expired and refresh immediately if so.

Guard against multiple simultaneous refresh calls. On platforms with multiple concurrent API requests, several calls can fail at the same time when a token expires. Without a guard, you'll fire multiple refresh requests simultaneously.

let refreshPromise = null

async function refreshAccessToken() {
  if (refreshPromise) {
    return refreshPromise
  }
  refreshPromise = fetch('/auth/refresh', { method: 'POST' })
    .then(res => res.json())
    .finally(() => {
      refreshPromise = null
    })
  return refreshPromise
}

This ensures only one refresh request goes out regardless of how many callers triggered it.

Session Expiry - Handle It Like It's Part of the Product

Session expiry is inevitable. Refresh tokens expire. Users get logged out on other devices. Admins revoke access. Your job is to handle it in a way that doesn't feel broken.

The worst experience is a silent failure - the user clicks something, nothing happens, no explanation. Or worse, they get a raw 401 error in the UI.

A better approach has three parts:

Intercept 401 responses globally. Don't handle auth errors individually in every API call. Set up a single interceptor that catches 401s, attempts a token refresh, and retries the original request. If the refresh fails, then you handle expiry.

async function apiFetch(url, options) {
  let response = await fetch(url, {
    ...options,
    headers: {
      ...options?.headers,
      Authorization: `Bearer ${getToken()}`
    }
  })

if (response.status === 401) {
    try {
      const newToken = await refreshAccessToken()
      setToken(newToken.accessToken)
      // Retry original request with new token
      response = await fetch(url, {
        ...options,
        headers: {
          ...options?.headers,
          Authorization: `Bearer ${newToken.accessToken}`
        }
      })
    } catch {
      handleSessionExpiry()
    }
  }
  return response
}

Tell the user what happened. When the session genuinely expires, show a clear message. "Your session has expired, please log in again." Not a blank screen, not a generic error. A real explanation with a clear action.

Preserve their intent. Store the URL they were trying to access before redirecting to login. After they authenticate, bring them back to where they were. On a content platform this matters - a user who was about to watch something should land back on that content, not the homepage.

OAuth and Social Login - What Actually Happens in the Browser

Most developers use a library for OAuth and treat it as a black box. That's fine until something breaks and then you need to understand what's actually happening.

Here's the simplified flow for a third-party login:

User clicks "Login with Google."
Your app redirects the browser to Google's authorization endpoint with your client ID, requested scopes and a redirect URI.
Google authenticates the user and redirects back to your redirect URI with an authorization code.
Your frontend sends that code to your backend.
Your backend exchanges the code for tokens directly with Google using your client secret.
Your backend issues its own session token to your frontend.

A few things to pay attention to here:

Never exchange the authorization code on the frontend. The code exchange requires your client secret. That should never be in frontend code.

Use the state parameter. This is a random value you generate before the redirect and verify when the user comes back. It protects against CSRF attacks on the OAuth flow.

function initiateOAuthLogin() {
  const state = crypto.randomUUID()
  sessionStorage.setItem('oauth_state', state)

  const params = new URLSearchParams({
    client_id: CLIENT_ID,
    redirect_uri: REDIRECT_URI,
    response_type: 'code',
    scope: 'openid email profile',
    state
  })
  window.location.href = `https://accounts.google.com/o/oauth2/auth?${params}`
}

function handleOAuthCallback() {
  const params = new URLSearchParams(window.location.search)
  const returnedState = params.get('state')
  const savedState = sessionStorage.getItem('oauth_state')
  if (returnedState !== savedState) {
    throw new Error('OAuth state mismatch. Possible CSRF attack.')
  }
  // Safe to proceed
}

Use PKCE for public clients. If you're doing the token exchange from a mobile app or a pure SPA without a backend, PKCE (Proof Key for Code Exchange) replaces the client secret with a cryptographic challenge. It's the current best practice for frontend-only OAuth flows.

The Security Decisions Most Developers Get Wrong

Storing sensitive tokens in localStorage. Covered above, but worth repeating. The convenience is not worth the XSS exposure.

Not setting token expiry short enough. Access tokens should be short-lived. If yours are valid for 24 hours, a stolen token gives an attacker a 24-hour window. Keep them short and lean on silent refresh.

Trusting the frontend for authorization. Hiding a button in the UI is not authorization. The API must enforce access control. Frontend checks are for user experience only, never for security.

Not handling token refresh race conditions. Already covered with the single refresh promise pattern. This one causes subtle bugs that are hard to reproduce and harder to debug in production.

Logging out only on the current device. When a user logs out or changes their password, invalidate their refresh tokens on the server. Otherwise they're still effectively logged in on every other device they've used.

Sending tokens in URL parameters. Tokens in URLs end up in browser history, server logs, and referrer headers. Always send them in the Authorization header or a cookie. Never in the URL.

Final Thoughts

Authentication on the frontend is not just a login form and a token in localStorage. It's a set of decisions that affect the security, reliability, and user experience of your entire platform.

Get the storage right. Build silent refresh properly. Handle expiry gracefully. Understand the OAuth flow well enough to debug it when it breaks.

The developers who handle auth well aren't the ones who memorized every OAuth RFC. They're the ones who understood the tradeoffs and made deliberate decisions at each step.

At scale, deliberate decisions are the only kind that hold up.

Have thoughts or questions on frontend authentication? Drop them in the comments, always happy to discuss.

This article is part of the Frontend at Scale series.

Frontend Performance That Actually Moves the Needle

Yogesh Yadav — Thu, 16 Apr 2026 20:01:05 +0000

In this article we'll cover why Lighthouse scores alone don't tell the full story, what metrics actually matter at scale, how real user monitoring changes the way you think about performance, and the optimizations that have the most impact on platforms serving millions of users.

Lighthouse is a great tool. I'm not here to tell you to ignore it. But I've seen teams chase a perfect Lighthouse score while their real users were experiencing 4-second load times on mid-range android devices with a 4G connection.

The score looked great. The experience wasn't.

When you're building for 10 million users, performance stops being about a number in a report. It becomes about real people on real devices with real network conditions. And the gap between a lab score and what your users actually feel is wider than most developers realize.

This article is about closing that gap.

Lighthouse Scores Are Lab Data, Not Reality

Lighthouse runs in a controlled environment. Throttled CPU, simulated network, a clean browser with no extensions, no cached data, no background tabs. That's not how your users browse.

Your users are on a 3-year-old phone with 15 browser tabs open, on a train with patchy network, while your JavaScript is fighting with a background app for CPU time.

This is why a 90+ Lighthouse score can still result in a poor user experience. The lab doesn't lie, but it only tells you part of the truth.

Lab data: what Lighthouse gives you - is useful for catching regressions and tracking trends over time. But it should never be your only signal.

Field data: what your real users experience - is where performance work actually pays off.

The Metrics That Actually Matter at Scale

Core Web Vitals

Google's Core Web Vitals are the closest thing we have to a standardized set of user-centric performance metrics. Three of them matter most:

LCP - Largest Contentful Paint: How long does it take for the largest visible element to render? For most platforms this is a hero image, a video thumbnail or a headline. This is what the user perceives as "the page loaded."

Target: under 2.5 seconds.

INP - Interaction to Next Paint: How quickly does the page respond after a user interaction? Click a button, tap a menu, submit a form - how long before the page visually responds? This replaced FID (First Input Delay) in 2024 and is a much better measure of real interactivity.

Target: under 200 milliseconds.

CLS - Cumulative Layout Shift How much does the page jump around while loading? Ads loading late, images without dimensions, fonts swapping - these all contribute to CLS. On a content-heavy platform this can quietly destroy the user experience.

Target: under 0.1.

These three metrics directly impact SEO ranking and user retention. At scale, a 0.1 improvement in CLS or a 500ms reduction in LCP translates to measurable engagement and conversion improvements.

TTFB - Time to First Byte

Before the browser can render anything, it needs a response from the server. TTFB measures that wait time. High TTFB usually points to server-side issues - slow API responses, no CDN or unoptimized server rendering.

On platforms with a global audience, CDN configuration alone can cut TTFB from 800ms to under 100ms for a significant portion of your users.

TTI - Time to Interactive

When can the user actually use the page? Not just see it, but interact with it without the UI freezing. This is where JavaScript bundle size and execution time have the most direct impact.

A page that looks loaded but isn't responding to clicks is one of the most frustrating experiences a user can have.

Real User Monitoring - The Signal You Can't Ignore

If you're only running Lighthouse, you're flying partially blind. Real User Monitoring (RUM) captures performance data from actual user sessions and sends it back to you.

The difference is significant. With RUM you can see:

How performance varies by device type, browser and geography
Which pages have the worst real-world LCP or INP
How performance degrades over time as your codebase grows
What percentage of your users are experiencing poor performance right now

Tools like Datadog RUM, SpeedCurve, Mux Data or even the free Chrome User Experience Report (CrUX) give you this visibility.

On a platform serving millions of users, even if 5% of your users are experiencing poor performance, that's 500,000 people having a bad time. RUM makes that visible. Lighthouse doesn't.

The Optimizations That Actually Move the Needle

1. JavaScript Bundle Size

This is almost always the biggest lever. JavaScript is the most expensive resource on the web - it has to be downloaded, parsed, and executed before it does anything useful.

Code splitting is non-negotiable at scale. Every route should load only the JavaScript it needs.

// Instead of importing everything upfront
import HeavyComponent from './HeavyComponent'

// Load it only when needed
const HeavyComponent = React.lazy(() => import('./HeavyComponent'))

Audit your bundle regularly. Tools like webpack-bundle-analyzer or vite-bundle-visualizer will show you exactly what's in your bundle and where the weight is coming from. You will almost always find something surprising.

Third-party scripts are usually the worst offenders. Analytics, chat widgets, ad scripts - these are often loaded synchronously and block rendering. Load them async or defer them entirely until after the page is interactive.

2. Image Optimization

Images are the largest assets on most pages. Getting this wrong has a direct impact on LCP.

Use modern formats. WebP is widely supported and significantly smaller than JPEG or PNG. AVIF is even better where supported.
Always set explicit width and height on images. This prevents layout shift and helps the browser allocate space before the image loads.
Use lazy loading for images below the fold.
Serve appropriately sized images. Don't serve a 2000px wide image to a 400px wide mobile screen.

<img
  src="thumbnail.webp"
  width="400"
  height="225"
  loading="lazy"
  alt="Video thumbnail"
/>

For a platform with a large content library, image optimization alone can reduce page weight by 40–60%.

3. Critical Rendering Path

The browser has to download your HTML, parse it, discover CSS and JavaScript, download those, parse them and then render the page. Every step in that chain is an opportunity to either speed things up or slow things down.

Inline critical CSS - the styles needed to render above-the-fold content - directly in the HTML. This eliminates a render-blocking network request for the initial view.
Preload key resources the browser won't discover until late in the parsing process.

<link rel="preload" as="font" href="/fonts/main.woff2" crossorigin>
<link rel="preload" as="image" href="/hero.webp">

Defer non-critical JavaScript. If a script doesn't need to run before the page is interactive, it shouldn't block rendering.

4. Caching Strategy

I covered this in depth in the previous article in this series, but it's worth mentioning here because caching is one of the highest-impact performance optimizations available to you.

Repeat visitors on a well-cached platform can load pages almost entirely from cache. No network requests for static assets, no server round trips for unchanged resources. The performance improvement for returning users is dramatic.

If you haven't read the caching article yet, it's worth going back to.

5. Reducing Main Thread Work

INP and TTI both suffer when the main thread is busy. JavaScript execution, long tasks, layout recalculations - these all compete for the same thread that handles user interactions.

A few things that help:

Break up long tasks. Any task that takes more than 50ms can cause noticeable jank. Use setTimeout or scheduler.postTask to yield control back to the browser between chunks of work.
Avoid layout thrashing. Reading and writing to the DOM in alternating calls forces the browser to recalculate layout repeatedly. Batch your reads and writes.
Move heavy computation off the main thread with Web Workers.

// Yielding to the browser between heavy tasks
async function processLargeDataset(items) {
  for (let i = 0; i < items.length; i++) {
    process(items[i])
    if (i % 100 === 0) {
      await new Promise(resolve => setTimeout(resolve, 0))
    }
  }
}

Performance Budgets - Making It Stick

One of the hardest parts of performance work at scale is keeping improvements from regressing over time. A performance budget solves this.

A performance budget sets explicit limits on metrics like bundle size, LCP or TTI. If a pull request would push you over the budget, it fails the build.

{
  "resourceSizes": [
    { "resourceType": "script", "budget": 300 },
    { "resourceType": "total", "budget": 1000 }
  ],
  "timings": [
    { "metric": "first-contentful-paint", "budget": 1500 },
    { "metric": "interactive", "budget": 3500 }
  ]
}

This keeps performance on everyone's radar, not just the engineer who cared enough to optimize it once.

What Scale Actually Teaches You About Performance

Here's what I've learned from working on platforms at this size that you don't find in most performance guides:

Device distribution matters more than you think. Your development machine is not representative of your users. Profile on a mid-range Android device and you will find issues you never knew existed.

Geography matters. A platform with a global audience needs a CDN strategy, not just a fast server in one region. Network latency from a distant origin server can add seconds to TTFB for users in certain regions.

Performance degrades gradually. Nobody ships a slow app intentionally. It gets slow one dependency, one feature, one third-party script at a time. Without a budget and regular monitoring, you won't notice until users are already complaining.

The 80/20 rule applies. A small number of pages usually account for the majority of your traffic. Find those pages, measure them obsessively and optimize them first. That's where your performance work will have the most impact.

Final Thoughts

Lighthouse is a tool, not a goal. A green score means you've done the basics right. It doesn't mean your users are having a fast experience.

The teams that get performance right at scale are the ones who measure what their real users experience, set budgets to prevent regression and focus their effort on the optimizations that actually move the needle for their specific platform and audience.

Start with RUM. Find where your real users are struggling. Fix those things first.

The Lighthouse score will follow.

Have thoughts or questions on frontend performance? Drop them in the comments, always happy to discuss.

This article is part of the Frontend at Scale series.

Frontend Caching Done Right

Yogesh Yadav — Sun, 05 Apr 2026 06:39:19 +0000

In this article we’ll cover how the browser cache and HTTP headers work, when and how to use stale-while-revalidate, how service workers give you programmatic control over caching, what you should never cache, and how cache invalidation works in practice. All of it from the perspective of building for platforms that can’t afford to get this wrong.

Caching is one of those topics that every frontend developer thinks they understand, until they’re staring at a production issue where users are getting stale data, or worse, the server is getting hammered because nothing is being cached at all.

I’ve worked on platforms handling more than 10 million active users. And I can tell you, caching stops being a “nice to have” the moment your scale starts growing. It becomes the difference between a platform that feels fast and one that quietly falls apart under load.

This article is everything I’ve learned about frontend caching, written the way I wish someone had explained it to me early in my career.

First, Understand What You Are Actually Caching

Before you touch a single HTTP header or write a line of service worker code, ask yourself one question.

What is the cost of serving stale data here?

That question determines everything. Because caching is always a tradeoff between freshness and performance. The mistake most developers make is treating all resources the same way. They’re not.

Here’s how I think about it:

Static assets (JS bundles, CSS, fonts, images) - these can be cached aggressively, sometimes forever, if you version them correctly.
API responses - depends entirely on how often the data changes and how much it matters if the user sees something slightly outdated.
HTML documents - usually should not be cached aggressively, especially for authenticated apps.
User-specific data - almost never cache this without thinking carefully.

Get this mental model right first. Everything else follows from it.

Browser Cache and HTTP Headers

The browser cache is your first and most powerful caching layer. It lives between the user and your server, and it’s controlled entirely through HTTP response headers.

Cache-Control

This is the header you’ll use the most. Here’s what the key directives actually mean:

Cache-Control: max-age=31536000, immutablety

max-age tells the browser how many seconds to keep this resource before considering it stale. immutable tells the browser not to bother revalidating it even on a hard refresh, because the content will never change.

Use this combination for versioned static assets, your JS bundles, CSS files, and images that have a content hash in the filename. Something like main.a3f9c2.js. The hash changes every build, so the URL changes, so you never serve stale code. Cache it forever.

Cache-Control: no-cache

Despite the name, this does not mean “don’t cache.” It means “cache it, but check with the server every time before using it.” The server can respond with a 304 Not Modified and the browser uses the cached version. No full download needed.

Use this for your HTML documents. You want the browser to always check if there’s a new version, but still benefit from caching when nothing has changed.

Cache-Control: no-store

This actually means “don’t cache.” Nothing is stored anywhere. Use this for sensitive data, authentication responses, anything you never want sitting in a cache.

ETag and Last-Modified

These work alongside Cache-Control for revalidation. When the browser asks "has this changed?", the server uses these to answer.

ETag: "abc123"
Last-Modified: Mon, 01 Jan 2024 00:00:00 GMT

The browser sends back If-None-Match: "abc123" or If-Modified-Since on the next request. If nothing changed, the server returns 304 and saves the bandwidth of sending the full response again.

At scale, these small savings add up to a significant reduction in server load.

Stale-While-Revalidate

This is one of the most underused caching strategies I’ve seen in frontend codebases, and it’s genuinely powerful.

Cache-Control: max-age=60, stale-while-revalidate=300

Here’s what this does. For the first 60 seconds, serve from cache, no questions asked. Between 60 and 300 seconds, serve the stale cached version immediately, but kick off a background request to revalidate it. After 300 seconds, it’s stale and must be revalidated before serving.

The user gets an instant response. The cache gets updated in the background. No loading spinner, no waiting.

This pattern is perfect for data that changes occasionally but doesn’t need to be real-time. Think navigation menus, configuration data, content that updates a few times a day. The user always gets a fast experience and the data stays reasonably fresh.

You’ll also recognize this pattern from TanStack Query’s staleTime and gcTime configuration. The underlying idea is exactly the same, just applied at the JavaScript layer instead of the HTTP layer.

Service Workers - The Programmable Cache

HTTP headers give you declarative control over caching. Service workers give you programmatic control. That’s a significant difference.

A service worker sits between your app and the network, intercepting every request. You decide what happens with each one.

self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request).then((cachedResponse) => {
      if (cachedResponse) {
        return cachedResponse
      }
      return fetch(event.request)
    })
  )
})

This is a simple cache-first strategy. Check the cache first, fall back to the network if nothing is found. For a platform serving millions of users, this means repeat visitors often never hit your server for static assets at all.

Caching Strategies with Service Workers

Cache First - Serve from cache, fall back to network. Best for static assets that rarely change.

Network First - Try the network, fall back to cache if offline. Best for API data where freshness matters but offline support is needed.

Stale While Revalidate - Serve from cache immediately, update cache in background. Best for non-critical content where speed matters more than freshness.

Cache Only - Only serve from cache. Useful for assets you’ve pre-cached during install.

Network Only - Always go to network. For requests that should never be cached, like analytics or payment endpoints.

Pick your strategy per resource type, not globally. A single strategy for everything is almost always the wrong call.

Pre-caching vs Runtime Caching

Pre-caching happens when the service worker installs. You explicitly list assets to cache upfront.

self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open('v1').then((cache) => {
      return cache.addAll([
        '/',
        '/styles/main.css',
        '/scripts/main.js',
      ])
    })
  )
})

Runtime caching happens dynamically as requests come in. You cache responses as they’re fetched, so frequently accessed resources end up in cache naturally over time.

For most platforms, you want both. Pre-cache your critical shell, runtime cache everything else.

What Not to Cache

This is the part that trips people up. Caching the wrong things causes bugs that are genuinely hard to debug in production.

Never aggressively cache:

Authentication tokens or session data
Payment and transaction endpoints
User-specific personalization data
Anything that changes per user or per session
A/B test configurations if they need to be real-time

I’ve seen teams cache API responses that included user-specific entitlements. The result was users seeing content they shouldn’t have access to, or not seeing content they’d just purchased. At scale, that’s not just a bug. It’s a trust problem.

When in doubt, don’t cache it, or use no-cache so at least revalidation happens.

Cache Invalidation - The Hard Part

There’s a famous saying in computer science: there are only two hard things, naming things and cache invalidation.

It’s funny because it’s true.

For static assets, content-hashed filenames solve this completely. New deploy, new hash, new URL, new cache entry. Old one expires naturally.

For API responses and service worker caches, you need a versioning strategy.

const CACHE_VERSION = 'v2'

self.addEventListener('activate', (event) => {
  event.waitUntil(
    caches.keys().then((cacheNames) => {
      return Promise.all(
        cacheNames
          .filter((name) => name !== CACHE_VERSION)
          .map((name) => caches.delete(name))
      )
    })
  )
})

Every time you deploy, bump the cache version. The activate event cleans up old caches. Users get fresh data on their next visit without you having to manually purge anything.

Caching at Scale - What Actually Changes

When you’re building for 10 million users, the fundamentals don’t change. But the consequences of getting it wrong are amplified significantly.

A few things I’ve learned from operating at that scale:

Measure before you optimize. Use Chrome DevTools, Lighthouse, and your RUM (Real User Monitoring) data to understand where your actual cache hit rates are. Don’t guess.

CDN caching and browser caching are different layers. Your CDN has its own cache headers, often separate from what the browser sees. Understand both. Misconfiguring your CDN can mean millions of users bypassing the browser cache entirely.

Cache stampedes are real. When a popular cached resource expires simultaneously for millions of users, they all hit your server at once. Stale-while-revalidate and jittered expiry times help prevent this.

Monitor your cache hit ratio. If it’s low, you’re leaving performance on the table. If it’s too high and you’re seeing stale data complaints, your TTLs are too aggressive.

Final Thoughts

Caching is not a set-it-and-forget-it feature. It’s an ongoing engineering decision that touches performance, correctness and user experience all at once.

Start with HTTP headers and get those right. Layer in stale-while-revalidate for the right resources. Add service workers when you need offline support or more granular control. And always think about invalidation before you think about caching.

The developers who get this right aren’t the ones who know the most cache directives. They’re the ones who ask the right question first.

What is the cost of serving stale data here?

Answer that honestly for every resource, and the rest follows.

Have thoughts or questions on frontend caching? Drop them in the comments, always happy to discuss.

This article is part of the Frontend at Scale series.

Explore the lexical Environment & Environment Record in Javascript 2021

Yogesh Yadav — Wed, 17 Aug 2022 07:23:00 +0000

Let's first understand the Lexical Environment & Environment Record as per different versions of ECMAScript Specification.

From ES2015 till ES2020 Specification:-

Lexical Environment:

A lexical environment is a specification type used to define the association of Identifiers to specific variables and functions, based upon the lexical nesting structure of your code.
A lexical environment consists of two components:
1. Environment Record
  It records the identifier bindings that are created within the scope of its associated Lexical Environment. It is referred to as the Lexical Environment's EnvironmentRecord.
2. Outer Reference
  A reference to outer environment (null in the global environment).

A conceptual view using pseudo-code:

executioncontext.environment = {
    environmentRecord: { 
    // storage
    <identifier> : <value>
    <identifier> : <value>
    }
    // reference to the parent environment
    outer: <...>    
}

Note: - The [[Environment]] created inside Execution Context is of type Lexical Environment
[refer ES2020]

According to 12th Edition ECMAScript2021 Specification:

Environment Record

A Environment Record is a specification type used to define the association of Identifiers to specific variables and functions, based upon the lexical nesting structure of your code.
Every Environment Record has one component:
1. Outer Reference
  An [[OuterEnv]] field, which is either null or a reference to an outer Environment Record. A conceptual view using pseudo-code:

executioncontext.environment = {
    // storage
    <identifier> : <value>,
    <identifier> : <value>,
    // reference to the parent environment
    outer: <...> 
}

Note: - The [[Environment]] created inside Execution Context is of type Environment Record [refer ES2021]

Let's also understand the Structure of execution context

Execution Context:

An execution context is a specification device that is used to track the runtime evaluation of the code.
To keeps the track of execution progress of its associated code, it needs various state components like LexicalEnvironment, VariableEnvironment, etc.

In pseudo-code:

ExecutionContext = {
    VariableEnvironment: { ... },
    LexicalEnvironment: { ... },
    // other components
}

Note:

Till ES2020	From ES2021
- The `LexicalEnvironment component` and `VariableEnvironment component` of an execution context are always Lexical Environments [refer ES2020]	- The `LexicalEnvironment component` and `VariableEnvironment` components of an execution context are always Environment Records [refer ES2021]

Summary

Let's have a quick recap of all the steps we perform in the above code snippet.

In ECMAScript2021, the [[environment]] which is created inside the execution context is of type Environment Record instead of Lexical Environment.
So, The LexicalEnvironment component and VariableEnvironment components of an execution context are always Environment Records.

Wrap Up!!

Thank you for your time!! Let's connect to learn and grow together.
Github Twitter

Forem: CodeScoop.dev

Real-Time on the Frontend - SSE, WebSockets & Polling

Polling - Not Always the Wrong Answer

Short Polling

Smarter Polling

SSE - The Underrated Middle Ground

Where SSE Shines at Scale

WebSockets - When You Actually Need Them

What most tutorials don't tell you about WebSockets:

Reconnection - The Part Everyone Gets Wrong

Lessons From Building Real-Time at Scale

What Else Is Out There

WebRTC

WebTransport

GraphQL Subscriptions

How to Pick the Right Approach

Final Thoughts

Frontend Security - What Your Browser Is Quietly Protecting You From

XSS - The Attack That Lives in Your Own Code

The other XSS surface most teams miss: third-party scripts.

CSRF - The Attack the Browser Already Mostly Fixed

Where this breaks down:

Clickjacking - The Invisible Iframe Attack

Content Security Policy - The Most Powerful Tool Nobody Uses

Why most teams don't implement it:

CORS - The Misconfigurations That Feel Like Security

What Developers Accidentally Break

Using target="_blank" without rel="noopener"

Disabling certificate warnings in development

Putting secrets in frontend code

Using eval() or new Function()

Final Thoughts

Authentication on the Frontend - More Than Just Tokens

Token Storage - The Decision That Has the Most Security Consequences

localStorage

httpOnly Cookies

In-Memory Storage

Silent Refresh - Keeping Users Logged In Without Asking Them To

Session Expiry - Handle It Like It's Part of the Product

OAuth and Social Login - What Actually Happens in the Browser

The Security Decisions Most Developers Get Wrong

Final Thoughts

Frontend Performance That Actually Moves the Needle

Lighthouse Scores Are Lab Data, Not Reality

The Metrics That Actually Matter at Scale

Core Web Vitals

TTFB - Time to First Byte

TTI - Time to Interactive

Real User Monitoring - The Signal You Can't Ignore

The Optimizations That Actually Move the Needle

1. JavaScript Bundle Size

2. Image Optimization

3. Critical Rendering Path

4. Caching Strategy

5. Reducing Main Thread Work

Performance Budgets - Making It Stick

What Scale Actually Teaches You About Performance

Final Thoughts

Frontend Caching Done Right

First, Understand What You Are Actually Caching

What is the cost of serving stale data here?

Browser Cache and HTTP Headers

Cache-Control

ETag and Last-Modified

Stale-While-Revalidate

Service Workers - The Programmable Cache

Caching Strategies with Service Workers

Pre-caching vs Runtime Caching

What Not to Cache

Cache Invalidation - The Hard Part

Caching at Scale - What Actually Changes

Final Thoughts

Explore the lexical Environment & Environment Record in Javascript 2021

Lexical Environment:

Environment Record

Outer Reference

Environment Record

Outer Reference

Execution Context:

Summary

Using `target="_blank"` without `rel="noopener"`

Using `eval()` or `new Function()`