DEV Community: Mohammad

Service Workers Deep Dive: What Actually Happens in the Browser

Mohammad — Fri, 19 Dec 2025 10:13:48 +0000

What Is a Service Worker?

A Service Worker is a JavaScript file that runs in the background, separate from the main page.

Key characteristics:

Runs on a different thread than the UI
Has no access to the DOM or window
Uses only asynchronous APIs
Can intercept and handle network requests

Service Workers act as a programmable network proxy between your application and the internet. Because they run outside the page lifecycle, the browser can start, stop, or restart them whenever needed. For this reason, they must not depend on in-memory state.

Registering a Service Worker

To use a Service Worker, you register it from your page:

navigator.serviceWorker.register("/sw.js");

When this runs, the browser:

Fetches the sw.js file
Compares its content with the previously stored version
Starts the lifecycle if the file is new or changed

The comparison is content-based. Even a one-character change in the file triggers a new install. File names, comments, or version variables do not matter unless they change the actual bytes of the file.

The Lifecycle: install → activate

Install

The install event is the first event fired for a new version of a Service Worker.

Its main purpose is to prepare the application for offline usage by caching required assets.

self.addEventListener("install", (event) => {
  event.waitUntil(
    caches.open("app-shell-v1").then((cache) => {
      return cache.addAll([
        "/",
        "/styles.css",
        "/app.js"
      ]);
    })
  );
});

event.waitUntil() tells the browser not to finish installation until the promise resolves. If this promise rejects, the Service Worker is discarded and never reaches the activate phase. This makes install an atomic step: it either fully succeeds or fails completely.

Activate

After installation, the Service Worker moves to the activate phase.

This event is typically used to:

Remove old cache versions
Release unused resources

Only one Service Worker version can be active at a time. If an older version is controlling open pages, the new one waits. This prevents a page from changing its controlling logic while it is running.

Page Control and Reloading

A page decides whether it is controlled by a Service Worker at load time.

This means:

The page that calls register() is not controlled
A reload or new tab is required for control to take effect

One Service Worker can control many pages at once. All controlled pages share the same worker instance. Global variables are shared and unreliable because the worker can be terminated and restarted at any time. Persistent data must be stored in Cache API or IndexedDB.

Cache API (Detailed)

The Cache API is the primary persistent storage mechanism used by Service Workers to store network responses.

At its core, the Cache API stores Response objects, each associated with a Request object as its key. This means the cache behaves like a map:

Request  →  Response

What exactly is stored?

Only Response objects
Metadata such as headers, status code, and body stream
No automatic serialization of custom data

The Cache API does not store raw files or URLs. It stores full HTTP responses, exactly as they were returned by the network.

How matching works

When you query the cache, the browser tries to find a matching entry based on:

Request URL
HTTP method (usually GET)
Vary-related headers

This matching logic closely follows standard HTTP caching rules, but it is fully controlled by your code. Nothing is automatically added or removed unless you explicitly do so.

Cache lifetime and persistence

Cache entries:

Do not expire automatically
Are not evicted based on time or size
Remain stored until explicitly deleted by your code or the user clears site data

Because of this, cache cleanup is a responsibility of the Service Worker, usually handled during the activate phase.

Scope and isolation

Cache API storage is scoped to the origin, defined as:

protocol + domain + port

This means:

Each domain has its own isolated cache storage
Subdomains do not share caches
Other websites cannot read or modify your cache

This isolation is critical for security and data integrity.

Debugging and inspection

Cache contents can be inspected via browser DevTools:

Application → Cache Storage

From there you can:

View cached requests and responses
Manually delete cache entries
Simulate cache-related edge cases during development

Recap

Service Workers run outside the page lifecycle and are event-driven
Registration is required and update detection is based on file content
The install phase prepares resources and must fully succeed
Only one Service Worker version can be active at a time
Page control is decided at load time, not dynamically
Cache API stores full HTTP responses keyed by requests
Cache data is persistent, origin-scoped, and fully controlled by code
Proper cache management is essential for predictable PWA behavior

The Anatomy of Webpack: What Really Happens Under the Hood

Mohammad — Sat, 11 Oct 2025 07:32:57 +0000

Webpack is far more than a simple bundler—it’s a modular build pipeline. Under the hood, its execution can be divided into several deep technical phases that determine how source code becomes an optimized bundle.

The Resolution phase comes first. Here, Webpack interprets every import or require statement and maps it to an actual file path. This process is powered by the enhanced-resolve package, which supports aliases, custom extensions, and module fallbacks. Multiple entry points can each trigger independent dependency graphs that Webpack merges later, deduplicating shared modules across entries.

Once files are resolved, the Evaluation phase begins. Each file runs through a chain of loaders—executed from right to left—to transform the content into JavaScript modules. For example, a .scss file may pass through sass-loader, css-loader, and style-loader, turning styles into JS-compatible strings. During this step, plugins can intercept runtime events and alter the output or even extract assets, as seen in MiniCssExtractPlugin.

Next, the Optimization and Code Splitting stage groups modules into chunks using SplitChunksPlugin, isolates vendor dependencies, and optionally separates the Webpack runtime—a small script that manages module loading in the browser. Dynamic import() statements create asynchronous chunks that the runtime loads only when needed, improving initial load time.

Finally, Webpack’s Output phase writes everything to disk, generating hashed filenames and a manifest that maps chunk identifiers to their physical files. The runtime uses this manifest at execution time to locate and load modules dynamically.

In essence, Webpack is not just bundling—it’s constructing, transforming, optimizing, and orchestrating the runtime behavior of modern web applications.

Behind the Scenes of Performance: How We Built a Data-Driven Frontend Dashboard

Mohammad — Tue, 23 Sep 2025 14:03:59 +0000

Over the past few weeks, I’ve been diving deep into real-time performance monitoring for our platform. It started with analyzing Round Trip Time (RTT) — the total time for a request to leave the client, hit our servers, and return with a response. Monitoring RTT gave us the first insight into end-to-end latency, helping us identify whether delays came from the client, network, or backend.

Next, we built a custom query to track Timeout and Cancelled Transactions. The idea was simple: some transactions never finish properly, and without surfacing this metric, they remain hidden behind average response times. By separating these failed interactions, we could measure how often users abandon requests or face slow services — a critical signal for reliability.

We didn’t stop there. Rendering Time became another key metric. Measuring frontend rendering duration helped us spot performance bottlenecks after the backend response arrives. It turns out, a fast API is not enough if the UI takes forever to paint meaningful content.

We also added visibility into Failed Resource Loads — things like missing scripts, broken images, or third-party calls silently failing in the background. Tracking these issues revealed UX problems that standard error metrics often miss.

On top of this, we experimented with custom dashboards, big number widgets for KPIs, threshold-based alerts in Sentry, and trend tables for historical analysis. Each feature brought a new layer of observability, from real-time incident detection to long-term optimization.

What I loved about this journey is how each metric unlocked a different perspective: latency, reliability, frontend performance, and user experience — all connected. The result is a monitoring setup that’s not just reactive but proactive and actionable.

Why I’m Not Ready to Trust BiomeJS (Yet)

Mohammad — Tue, 26 Aug 2025 13:45:15 +0000

I tried BiomeJS recently and honestly—I couldn’t fall in love with it.

Sure, it’s blazing fast, written in Rust, and promises to replace ESLint + Prettier in one shot. But the reality wasn’t that smooth:

It feels too opinionated. Instead of fitting into my workflow, it wanted me to adapt to its rules and defaults.
Speed is nice (I’ve seen people lint hundreds of files in milliseconds), but in my projects performance bottlenecks rarely come from linting. What matters more is flexibility and ecosystem support.
The maturity isn’t there yet. If I run into an edge case or need a plugin, Biome doesn’t give me the same safety net that a stable, well-adopted toolchain does.
Migration also isn’t as seamless as it sounds. Rewriting configs, figuring out which rules match what—I’d rather not burn hours just to get back to where I already was.

Funny enough, even ESLint’s latest releases remind me of this balance. They’ve added flat configs, better defaults, even multithreaded linting—but those changes showed me how much ecosystem readiness matters. A shiny new config system doesn’t help if plugins and tools aren’t ready to support it.

So for now, I’m staying with the “boring but reliable” stack. BiomeJS looks promising, and I’ll keep an eye on it. But until it feels stable enough to trust in production, I’m not ready to make it my team’s daily driver.

Sometimes boring tools are exactly what you need to keep shipping.

How JS Really Takes Photos!

Mohammad — Sat, 02 Aug 2025 19:23:35 +0000

There are two main ways to access the user's camera in JavaScript (and React). One of them became the go-to solution, and most libraries are just creative variations of it.

1. The video tag + Screenshot Trick

You stream the camera into a video tag element, and when the user hits the shutter button, you capture a screenshot using a .
📷 The image quality depends on the resolution you define — it’s usually lower quality, but fast and lightweight.

2. The ImageCapture API

Instead of grabbing the whole screen, this API captures a single frame directly from the video stream.
📸 The quality is much better, but unfortunately, it’s not supported in Safari or Firefox yet, and there’s no widely adopted library around it.