DEV Community: Gaurav Behere

The I/O ’26 Moment That Actually Stuck With Me

Gaurav Behere — Sat, 23 May 2026 16:41:17 +0000

This is a submission for the Google I/O Writing Challenge

Watching the I/O ’26 keynotes and developer sessions, it was easy to get distracted by the big narratives about “agentic workflows” and new capabilities in Gemini. But the part that lodged in my brain wasn’t a new model—it was the moment when Google effectively wired an AI coding agent directly into Chrome DevTools and handed it a set of opinionated web skills called Modern Web Guidance.

Taken together, those two pieces make a simple but important promise: instead of just asking an agent to spit out React components and hoping they run, you can now let it see, audit, and debug a real browser session, guided by a curated checklist of what “good modern web” looks like. That’s a very different posture from “AI as autocomplete,” and it’s the kind of tooling that can quietly change how web teams actually ship code.

What Google Actually Shipped

In the Developer Keynote recap, Google framed this era as “agentic workflows,” and introduced Antigravity as the platform where agents handle the heavy lifting while you stay focused on design and intent. Within that story, Chrome’s announcements were about giving those agents real, first‑class tools rather than treating the browser as an opaque black box.

Two pieces are central here.

First, Chrome DevTools for agents: a Model Context Protocol (MCP) server and CLI that let coding agents like Gemini CLI, Antigravity, Cursor, Claude Code and others connect directly to a live Chrome instance to run audits, emulate devices, and inspect runtime behavior.
Second, Modern Web Guidance: an “evergreen, expert‑vetted” skill package that encodes Google’s own best practices for accessibility, performance, and security into reusable instructions that can be injected into your agent’s context.

Modern Web Guidance ships as an installable skill (via a dedicated CLI, GitHub repo, or integration with agent platforms), while DevTools for agents provides the bridge between those skills and the actual browser runtime where your app lives. In other words, one tells the agent what “good” looks like on the web; the other lets it verify whether your app matches that definition in a real environment.

Agents That Can Actually See the Browser

If you’ve used AI coding assistants before, you know the core limitation: they generate a lot of plausible code, but they typically can’t watch that code run in a real browser. They hallucinate fixes based on static snippets and log fragments, with no real way to test assumptions against a live UI or network waterfall.

Chrome DevTools for agents attacks that gap directly. Google’s documentation shows three key integration surfaces: an MCP server that connects LLMs to DevTools, a CLI for token‑efficient scripted interactions, and a set of “agent skills” that teach agents how and when to use the available tools. Once wired up, the agent can do things that were previously strictly human territory: run Lighthouse audits for accessibility and SEO, emulate different devices and throttled networks, interact with forms, and even debug Chrome extensions.

Critically, this isn’t a synthetic sandbox.

Agents can now connect to your active Chrome session, which means you can hand an authenticated dashboard or an internal tool to the agent and let it investigate issues using your real login state. That’s a big shift compared to the usual pattern of pasting screenshots and hoping the model guesses what’s wrong.

Modern Web Guidance: Opinionated Skills, Not Just Raw Power

On its own, giving an agent access to DevTools could just mean it runs random audits and drowns you in output. Modern Web Guidance is the other half of the story: it’s a curated skill set that tells the agent how to build and repair web experiences in a way that aligns with Chrome’s view of “modern.”

Modern Web Guidance is a set of “evergreen and expert‑vetted skills” that cover over 100 web development use cases, focused on accessibility, performance, and security. You install it via a dedicated CLI (npx modern-web-guidance@latest install), through GitHub, or by using agent‑skill integrations in platforms like Antigravity, Vercel’s Agent Skills, Claude Code, and Copilot CLI.

The effect is that your agent isn’t just generating whatever HTML and JavaScript seems most likely; it’s being steered by explicit patterns that consider Baseline support, fallbacks, and contemporary best practices. When you combine that with a live DevTools connection, you get a loop where the agent can run an audit, compare the findings against those skills, and then propose concrete, standards‑aligned code changes instead of generic advice.

A Quiet Reframing of Web Work

The obvious reading of these announcements is “better AI tools for debugging,” but I think there’s a quieter reframing happening underneath. In the I/O schedule and recaps, Google keeps talking about “agent‑ready web applications” and “agentic workflows,” which is another way of saying they expect AI agents to become first‑class participants in the dev loop, not just helpers that comment on diffs.

When your agent can navigate your app, throttle the network, simulate geolocation, and run Lighthouse, it stops being a code suggester and starts acting more like a junior engineer who can run checks, reproduce bugs, and report back with structured findings. Modern Web Guidance then functions like the senior engineer’s playbook that this junior can follow—opinionated, slightly conservative, but grounded in real‑world experience.

That’s not as flashy as a new parameter count for a model, but for teams that ship web apps week after week, this is where AI genuinely starts to feel like infrastructure rather than a toy. The browser stops being the final black‑box stage of the pipeline and becomes a programmable surface the agent can reason about.

Concrete Use Cases That Actually Make Sense

If you ignore the hype and look at the workflows the docs emphasize, a few grounded use cases pop out. The most obvious is automated quality gates: have an agent run Lighthouse audits on every preview deployment, flag anything that drops below a threshold, and propose Modern Web Guidance–aligned fixes before a human even opens the URL.

Another is environment‑aware debugging. The DevTools for agents documentation shows examples of simulating locations (like Berlin) and verifying that a store locator behaves correctly, or testing responsive layouts on mobile breakpoints. Instead of bouncing QA engineers between devices and VPNs, you can let an agent script those flows, collect screenshots and logs, and surface only the cases that fail.

The third is extension and WebMCP tooling, which came up both in the DevTools for agents docs and the I/O developer recap. For teams experimenting with WebMCP to expose structured tools to browser‑based agents, having DevTools‑level visibility into how those tools are invoked—and where they break—looks essential. That’s the kind of plumbing that makes “agents in the browser” feel less like a demo and more like something you’d risk in production.

Where This Still Falls Short

None of this magically makes AI a senior engineer. The Chrome team is explicit that DevTools for agents is about visibility and automation, not judgment. An agent can run audits and suggest fixes, but it doesn’t understand your product roadmap, business trade‑offs, or how a specific regression will land with your users.

There’s also a trust question. Giving an agent write access to your codebase is one thing; giving it write access plus direct control of your browser session, authenticated state, and extension environment is another. The documentation talks about using it as a tool in your workflow, but in practice teams will need guardrails—clear scopes, review steps, and probably some internal policies on what agents are allowed to touch.

Finally, Modern Web Guidance is opinionated by design. That’s good for consistency but can be limiting if you’re working on something that deliberately pushes browser capabilities beyond the comfort zone of a curated skill set. I expect early adopters will run into those edges and either extend the skills or selectively disable them where they conflict with legitimate experimentation.

How I’d Actually Use This on a Real Team

If I were integrating this into a real web stack, I wouldn’t start by letting the agent auto‑merge fixes. I’d start by letting it watch and report. For example, wire up DevTools for agents to run on every pull request preview, with Modern Web Guidance configured for your Baseline targets, and have it produce a structured report: what audits it ran, what failed, and suggested code changes in a separate patch.
From there, I’d gradually give it narrow powers. Maybe the agent can auto‑fix alt‑text issues and color contrast problems, since those are relatively low‑risk and well‑defined. Maybe it can propose but not apply performance tweaks, leaving a human to decide whether a particular lazy‑loading strategy or bundling change is worth the trade‑offs.
Over time, if the signal proves reliable, you could start treating this combo—DevTools for agents plus Modern Web Guidance—as a sort of web quality coprocessor: something that runs continuously alongside your normal CI, catching the mundane but important issues that humans miss when they’re in a rush. That’s not science fiction; it’s basically just operationalizing what Google demoed in the I/O ’26 sessions and then exposed through the open Chrome and I/O docs.

Why This Might Be One of I/O ’26’s Most Important Announcements

I/O this year had plenty of “headline” moments around models and agent platforms, and those matter. But for day‑to‑day developers, the combination of Chrome DevTools for agents and Modern Web Guidance feels like the kind of change we’ll notice more in six to twelve months than in six days.
By giving agents high‑fidelity access to the browser runtime and pairing that with a shared, opinionated definition of “good web,” Google is quietly rewriting the contract between web developers and their tools. Instead of hoping that an AI assistant understands your app from a code snippet, you can put it in front of the real thing and ask it to prove that it understands what it’s seeing.
That’s not a magic future where agents replace web teams. It’s a pragmatic step toward something more useful: agents that behave less like autocomplete and more like reliable collaborators—especially in the messy, browser‑only corners of our work that we’ve never really been able to automate well. And for me, that’s the part of I/O ’26 that feels most likely to change how we build for the web.

Thank you for reading. If you have enjoyed the article, do share it with the community & spread the word.

Time to say goodbye to Webpack?

Gaurav Behere — Thu, 13 Jan 2022 09:50:25 +0000

Before we answer the big question, lets look at why we are even considering it.

If you look at bestofJS data for 2021, you would see that the rising star in the build tools category is Vite, leaving Webpack far behind in terms of popularity.
Check out more stats here:
2021 JavaScript Rising Stars

Lets have a closer look at `Vite`

Vite (French word for "quick", pronounced /vit/, like "veet") is a build tool that aims to provide a faster and leaner development experience for modern web projects.

Please note the emphasis on development. Vite does not promise a multifold optimization or better production experience. So don't expect your production build to be optimized or any drastic reduction in the bundle size you generate.

So what does `Vite` do to make the development experience better?

It consists of two major parts:

A dev server that provides rich feature enhancements over native ES modules, for example extremely fast Hot Module Replacement (HMR).
A build command that bundles your code with Rollup, pre-configured to output highly optimized static assets for production.

Vite is opinionated and comes with sensible defaults out of the box, but is also highly extensible via its Plugin API and JavaScript API with full typing support.

It has been long since we have been writing JS code in a modular fashion specially since ES6 modules. Since not a lot of browsers were handling loading ES6 modules natively, we have the concept of bundling our code, using tools that crawl, process and concatenate our source modules into files that can run in the browser.

Tools like Webpack, parcel & rollup do the same job.
When you start a project, the size & number of JS modules may look like a smaller problem but as you write more code, the project grows & you see that starting a dev server takes a long time.
Since it has to transpile the code & concatenate the code in a way that can be loaded in browsers.
The slow feedback loop can greatly affect developers' productivity and happiness.

Vite aims to address these issues by leveraging new advancements in the ecosystem: the availability of native ES modules in the browser, and the rise of JavaScript tools written in compile-to-native languages.

Vite splits the bundles into two parts:

External dependencies (Vendor code): Dependencies are mostly plain JavaScript that do not change often during development.
Vite pre-bundles dependencies using esbuild. Esbuild pre-bundles dependencies 10-100x faster than JavaScript-based bundlers.
Your code (ES modules): Vite serves source code over native ESM. This is essentially letting the browser take over part of the job of a bundler. Vite only needs to transform and serve source code on demand, as the browser requests it.

Here, Vite assumes that while you are developing in your local machine you would have latest of browsers that support loading ES6 modules natively.

That essentially means no time spent on bundling your code before the server can start.

Awesome, so why bundle for production?

Though most of the browsers now support loading ES modules natively, if not all of your target audience is on latest browsers, you still need bundling.
If you don't bundle, you are going to make a lot of round trips on the network to fetch modules. To get the optimal loading performance in production, it is still better to bundle your code with tree-shaking, lazy-loading and common chunk splitting (for better caching).

Getting started with `Vite`

With minimal dev dependencies, you can be off to a flying start

"devDependencies": {
  "@vitejs/plugin-react": "^1.1.4",
  "vite": "^2.7.10"
}

A very basic vite.config.js

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [react()]
});

Two simple commands to start a dev server & make a production build:
vite & vite build respectively.

Vite looks for an index html entry in the root directory from where you need to load the root/index module of your code.

index.html

<!DOCTYPE html>
<html>
<head></head>
<body>
  <div id="root"></div>
  <script type="module" src="./index.jsx"></script>
</body>
</html>

index.jsx

import React from 'react';
import ReactDOM from 'react-dom'
import App from './src/app';

ReactDOM.render(
    <React.StrictMode>
        <App />
    </React.StrictMode>,
    document.querySelector('#root')
);

src/app.jsx

import React from 'react';

const App = () => {
  return <>
    <div>Hello There</div>
    <div>Time right now: {new Date().toTimeString()}</div>
  </>
}

export default App;

Without bundling the code, server starts in a fraction of a second

If you look at how the ES modules are loaded in the browser, note that app.jsx loaded as a native ES module

Hot replacement of modules (HMR)

Developers need to get immediate feedback of changes made in the code. You can't wait for full bundling to happen again & reloading the page which breaks the current state & flow.
This is why some bundlers support Hot Module Replacement (HMR), allowing a module to "hot replace" itself without affecting the rest of the page. Again as the project grows, HMR also takes a long time which can be a productivity killer.

Vite takes an edge over other bundling tools by performing HMR over native ESM. When a file is edited, Vite only needs to precisely invalidate the chain between the edited module and its closest HMR boundary (most of the time only the module itself), making HMR updates consistently fast regardless of the size of your application.

Vite also takes advantage of HTTP headers to speed up full page reloads. Source code module requests are made conditional via 304 Not Modified, and dependency module requests are strongly cached via Cache-Control: max-age=31536000,immutable so they don't hit the server again once cached.

Recap

Vite starts your dev server fast by skipping the bundling.
Vite make use of HTTP status codes for a faster reload & caching.
Vite uses native ESM for hot module replacement. Thus your changes reflect in your app faster.
Since Vite is a bit opinionated about the config, with a minimal config you are good to go.

Server side rendering

Vite is also pre-configured to handle your build as a universal app. Vite can pre-render the HTML pages, so robot crawlers can fetch your page content without executing js.
Read more https://vitejs.dev/guide/ssr.html

So should we just move to `Vite` & stop using tools like Webpack?

Coming back to the question that we started with. With all the benefits listed above, it seems promising to move to Vite.

What gives you a lot of simpler APIs with a lot of abstraction and an opinion is often hard to configure.

Based on this principle if you use some very specific long tail configurations of Webpack, it won't be a good idea to jump to Vite rightaway. If you use Webpack with basic configurations, you should move to Vite for a better developer experience.

If I am starting a new project, it will be using Vite for sure.

Thank you for reading. If you have moved a large scale project from Webpack to Vite, do share your experience. It will be great to learn from your experience.

Unit testing service workers

Gaurav Behere — Wed, 15 Dec 2021 13:03:27 +0000

Writing unit tests for service workers made easy.

Prelude

While service workers amaze us with its capabilities to cache requests, edit headers before putting requests on the network etc.
I think you will agree that unit testing service workers is not straight-forward.
The biggest question is 'what to mock?'

A big shout out to Zack Argyle for writing Service Worker Mock. This library prepares all the mocks & lets your tests have an environment where you have the recipe to test your service worker.

Note

This code sample is an enhancement on top of Service Worker Mock. Service Worker Mock explains how to write unit tests for service works. Since it is not maintained any more, I am writing this code sample to unblock ourselves from the current issues in that library.
Tests are written using the sample service worker given at service worker example

Problem with the current version (2.0.5) of service worker mock

Object.assign(global, makeServiceWorkerEnv()) no longer puts EventTarget methods like addEventListener into the global scope because they are no longer "own" properties of ServiceWorkerGlobalScope

Workaround

Make addEventListener an enumerable property

beforeEach(() => {
   const serviceWorkerEnv = makeServiceWorkerEnv();
   Object.defineProperty(serviceWorkerEnv, 'addEventListener', {
      value: serviceWorkerEnv.addEventListener,
      enumerable: true
   });
   Object.assign(global, serviceWorkerEnv)
   jest.resetModules();
});

Testing Event registration

it('should add listeners', async () => {
  require('../src/sample-sw');
  await self.trigger('install');
  expect(self.listeners.get('install')).toBeDefined();
  expect(self.listeners.get('activate')).toBeDefined();
  expect(self.listeners.get('fetch')).toBeDefined();
});

Testing cache deletion on activation

it('should delete old caches on activate', async () => {
  require('../src/sample-sw');

  // Create old cache
  await self.caches.open('OLD_CACHE');
  expect(self.snapshot().caches.OLD_CACHE).toBeDefined();

  // Activate and verify old cache is removed
  await self.trigger('activate');
  expect(self.snapshot().caches.OLD_CACHE).toStrictEqual({});
});

Testing fetch event to see if it returns cached response

it('should return a cached response', async () => {
  require('../src/sample-sw');

  const cachedResponse = { clone: () => { }, data: { key: 'value' } };
  const cachedRequest = new Request('/test');
  const cache = await self.caches.open('TEST');
  cache.put(cachedRequest, cachedResponse);

  const response = await self.trigger('fetch', cachedRequest);
  expect(response.data.key).toEqual('value');
});

Testing if fetch event makes network call & updates cache. Also test any custom logic like appending a bearer token in the request

it('should fetch and cache an uncached request and append the right auth token in the header', async () => {
  const mockResponse = { clone: () => { return { data: { key: 'value' } } } };
  global.fetch = (response) => Promise.resolve({ ...mockResponse, headers: response.headers });

  require('../src/sample-sw');

  const request = new Request('/test');
  const response = await self.trigger('fetch', request);
  expect(response.clone()).toEqual(mockResponse.clone());

  expect(response.headers.get('authorization')).toBe('Bearer my secret auth');

  const runtimeCache = self.snapshot().caches.runtime;
  expect(runtimeCache[request.url]).toEqual(mockResponse.clone());
});

Testing if the requests to the external domains are ignored

it('should ignore the requests to external world', async () => {
  const mockResponse = { clone: () => { return { data: { key: 'value' } } } };
  global.fetch = (response) => Promise.resolve({ ...mockResponse, headers: response.headers });

  require('../src/sample-sw');

  const request = new Request('http://google.com');
  const response = await self.trigger('fetch', request);
  expect(response).not.toBeDefined();
});

Coverage

Epilogue

Check out the code repo for this sample here:
unit-test-service-worker

Inversion of Control — A simple & effective design principle

Gaurav Behere — Sun, 17 Oct 2021 13:57:49 +0000

Reducing code complexity with IoC

Inversion of control (IoC)

If you have heard of dependency injection(DI) you have been using inversion of control but maybe not knowingly.
IoC is often seems used interchangeably with DI but IoC as a concept is much more than that.

IoC is a design principle that helps you in reducing the complexity of code that you may want to ship as a reusable component or a library.
DI is one of the patterns that help in implementing IoC.

Usually, we have seen libraries/components implementing all the features for us & expose APIs to be called in a certain way to get the functionality we need. We may call the same API with a different set of parameters & value combinations to get what we want.

There is a level of abstraction to us in a way that we need not bother about the library/component reusable code but we need to know the meaning of each option/parameter to be passed so that we can understand the API’s behavior better.

Now put yourself in the shoes of the guy who wrote that library or the reusable component.

There is n number of use cases that he needs to support out of the same piece of code. There can be different values of the parameters & different combinations of those which may result in the same API or component to behave differently.

What does this translate to in code?

Lots of IF ELSE statements

What does it lead to?

More cyclomatic complexity

Less maintainable code

Lengthier documentation about all the options & their combinations

Any new feature that our generic component now has to support will have to be done very carefully so that we don’t break any existing support.

When we refactor the code it is not easy to get away with any option or any conditional branch as we may not know who is consuming our component using that code flow.

All these are very usual problems we see almost every day, isn’t it? This is an ever-growing problem too as the request for new functionalities with more if-else will keep coming.
Let’s look at this piece of code to understand the problem better.

You are writing a function that does the sorting of an array:

const sortArray = (array) => array.sort();

At a very basic level, it just returns the native sort. This is not sufficient as it doesn’t work well with numbers & custom sort for objects, also the default order of sort would be ascending. Let's add these features one by one.

Let us add support for descending sort:

// order = 1 -> ascending
// order = 2 -> descending
const sortArray = (array, order=1) => {
  if(order === 1)
    return array.sort();
  else if(order === 2)
    return array.sort((a,b) => b - a);
  else
   console.error("Unsupported sort order provided")
}

Let us add support for sorting objects with a specified key:

// @param order(number) = 1 -> ascending
// @param order(number) = 2 -> descending
// @param objectSort(boolean) 
const sortArray = (array, objectSort, key, order=1) => {
  if(objectSort) {
    if(order === 1)
      return array.sort((a,b) => a[key] - b[key]);
    else if(order === 2)
      return array.sort((a,b) => b[key] - a[key]);
    else
     console.error("Unsupported sort order provided")
  }
  else {
    if(order === 1)
      return array.sort();
    else if(order === 2)
      return array.sort((a,b) => b - a);
    else
     console.error("Unsupported sort order provided")
  }
}

As you can see that addition of features is adding code paths & branches in our code. Now say we need to support a case insensitive sort based on an option & we want to keep all the undefined values at the start of the array, that too based on an option, how many more if-else do we need?

This list of features is ever-growing.

I took the example of sorting as a library function because the native sorting in JavaScript is also based on the principle of IoC.

Inversion of Control

As Wikipedia explains it:

A software architecture with this design inverts control as compared to traditional procedural programming: in traditional programming, the custom code that expresses the purpose of the program calls into reusable libraries to take care of generic tasks, but with inversion of control, it is the framework that calls into the custom, or task-specific, code.

In simple terms, in the inversion of control, the library or the reusable component lets the consumer take control of what the functionality is & it provides an abstraction on top of it.

Now imagine passing the sorting method as a parameter to the library & it actually invokes your own sorting method to do the sorting.

How does it help?

The extensibility of functionality is now independent of the code complexity in the library rather the consumer gets a handle to override the default behavior in its own way.

const sortArray = (array, sortFunction) => {
  if (sortFunction) {
    return array.sort(sortFunction);
  }
  return array.sort();
}

Testability: We can substitute the core functionalities with mocks during the testing.
Substitutability: We enable a plugin architecture that makes it easy for us to swap out plugins, and program against code that doesn’t yet exist. All we need to do to substitute the current dependency is to create a new one that adheres to the contract defined by the interface.
Flexibility: According to the “Open Closed Principle”, a system should be open for extension but closed for modification. That means if we want to extend the system, we need only create a new plugin in order to extend the current behavior.
Delegation: IoC is the phenomenon we observe when we delegate behavior to be implemented by someone else but provide the hooks/plugins/callbacks to do so. We design the current component to invert control to another one. Lots of web frameworks are built on this principle.

There are many real-life use cases where you would have seen IoC in action. A good example is a state reducer pattern.
React, rather than providing a complex way of managing your state, lets you do that with your own reducer function & lets you provide your reducer as a hook before rendering your components.

Dependency Injection in angular is also based on this principle. Dependency Injection (DI) is one of the implementations of IoC based on the composition of dependencies in the container (the library).

Hooks in React are based on the IoC too.

Conclusion

Though IoC is a good principle to follow & there is a large number of libraries following it, it should be a conscious decision to choose IoC. In case you are aware of all the possible functionalities & code branches, a non-inverted control would make the consumption of the library easier. If you dealing with unknown extensibilities, it would be recommended to implement an inverted control.

Re-architecting authentication with Service Workers

Gaurav Behere — Mon, 13 Sep 2021 06:06:42 +0000

A use case of changing the authentication mechanism of a web application without touching a lot of legacy codebase

Many times you would encounter situations where you have a legacy codebase in front of you which has been in the market for quite a while. It may be written in a technology that is seeing a downward trend in terms of popularity. You cannot make a change very easily in the architecture of such applications as the amount of risk, testing efforts & impact is huge.
Let me run you through such a use case where we recently had to change the authentication mechanism of an existing legacy web application from a JSP session & a cookie-based authentication mechanism to an MSAL (Microsoft Authentication Library) token-based authentication method.
What this essentially means is the login should grant a token to the web application acquiring the token using MSAL (react-msal) in our case & the same token should be used for making further calls to the server.
Read more about MSAL tokens here:
https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/acquire-token.md

Challenges

There are two challenges we are looking at:

Changes to the webserver: The web server should be able to authenticate our requests with the token that the client application is going to send as a bearer token.
Changes to the legacy UI code written in JSP: The amount of legacy code which is an amalgamation of many UI technologies where there are requests like POST from FORM submits, XHR calls, calls through native JS fetch, Jquery’s $.ajax & a bit of axios too. It becomes very hard to avoid changes in almost every part of the code & still get the new authentication mechanism working where every call to our server should have a bearer token attached to the HTTP header.

Adding to the complexity of the application, the code base grew up with a lot of acquisitions of companies adding to the integrations in the existing codebase. Thus the application grew horizontally in terms of technology over the last 10 years.

Also when you have such a legacy codebase, it becomes hard to keep the knowledge fresh. There are pieces of the code that developers might not have even looked at for a long long time. Touching such code may result in unaccounted for side effects as the application has a significant number of customers who are using different versions & flows of the application.

How can we have a centralized solution which avoids making changes to a lot of files?

Service workers & promises to the rescue.
We try to avoid changes in the front-end code updating the APIs to authenticate based on the incoming MSAL token.
The solution is to capture all the network calls originated from the web application & append a bearer token in the HTTP header in the request.

Take a hold of all the network calls generated by your web application using a service worker registered at the root of your web application.

self.addEventListener('fetch', (event) => {
  const token = "some dummy token"; // This needs to be requested from MSAL library

  // Responding with a custom promise
  const promise = new Promise((resolve, reject) => {
    // edit event.request & respond with a fetch of a new request with new headers
    let sourceHeaders = {};
    for (var pair of event.request.headers.entries()) {
      sourceHeaders[pair[0]] = pair[1];
    }
    const newHeaders = { ...sourceHeaders, 'Authorization': 'Bearer: '+ token };
    const newRequest = new Request(event.request, {headers: newHeaders}, { mode: 'cors' });
    resolve fetch(event.request);
  });

  event.respondWith(promise);
});

In the fetch event we need to respond with a new request that has HTTP headers we need. In the gist above, we are just adding a dummy auth token to the request. Here we do a couple of things:

a. We copy all the headers of the incoming request.
b. We create a new request with incoming headers & a new authorization header containing a token.

Now let us get the right token.

Here comes the tricky part. A service worker comes with its own limitations, it has no access to DOM & it can’t access shared storage between the page & itself. Somehow we need to get the token from the main thread & the container app.
Here is a good article explaining how to establish communication between a service worker & the container page.

https://felixgerschau.com/how-to-communicate-with-service-workers/

We choose the Broadcast API to get away with the need of the two parties to remember the ports to have a 1:1 communication channel.

// Create a channel for communication
const channel = new BroadcastChannel('TOKEN_EXCHANGE');

const getAToken = () => {
  const promise = new Promise((resolve, reject) => {
    // Listen to token response
    channel.onmessage = (e) => {
      resolve(e.data);
    };
    // Send a token request to the main thread
    channel.postMessage("TOKEN_REQUEST");
  });
  return promise;
}

Changes in the container app

The container app now needs to listen to the messages on the same broadcast channel & respond with a token.
This allows up to keep the front end legacy code as-is & at the same time have a new authentication mechanism.

Things to note

As our solution is based on service workers, promises & Broadcast API, browser compatibility can be a limitation.
We still had to re-factor the APIs to honor tokens in the request for authentication.

Must-Have Weapons in Your React Armory

Gaurav Behere — Mon, 13 Sep 2021 05:48:48 +0000

Weapons (tools) make a soldier (developer) effective. Advanced and effective weapons (tools) in your armory ensure you have the firepower to handle the complexity of an ever-growing code base.
Let’s look at a few of the tools I used in my last project. These tools helped me to write code quickly yet maintain quality.

React Dev Tools

Programming is 20% coding and 80% debugging. Debugging is what makes a programmer efficient in comparison to others.
React Developer Tools let you inspect a React tree, including the component hierarchy, props, state, and more. To get started, just open the React Developer Tools and switch to the React Components or React Profiler tab.
By selecting one of the components in the tree, you can inspect and edit its current props and state in the panel on the right. In the breadcrumbs, you can inspect the selected component, the component that created it, the component that created that one, and more.
React developer tools are available for Chrome and Firefox as an extension.

Styled Components

While styling components, we also have to take care of vendor prefixes for cross-browser operability. If we’re using LESS or SASS we have to compile code to CSS.
With a component being an individual entity and a basic building block for building apps, it’s recommended for styling to be included within the component, rather than the container app taking care of styling with class names.
Styled components allow us to keep the styles within the component, coupled with the JavaScript code.
Read about some more benefits here.

React-Intl

Having strings, a lot of text in the UI, and having to internationalize it can be painful at times. With the right translation based on browser locale or user preference, presenting the user interface in a different language can be tricky.
React-Intl handles it in an elegant way, wrapping your components in a scope and rendering strings based on the locale.
With support for formatting dates, numbers, plurals, etc out of the box, it makes handling such translations easy. Moreover, for a fully-fledged translation conversion, you can have translations based on languages you want to support and you can configure React-Intl to pick up the right translation file at runtime.
Read more here.

Storybook

Storybook allows you to write and test components in isolation.
When there are multiple people working on UI components that need integration at a later point in time, storybook makes it easier for individual developers to write and test their components in isolation.
Moreover, the storybook also serves as a living document of what has been done so far. You can look at all the components at a glance and check how they behave. You can play with a component by modifying supplied props and testing its behavior.
I may sound crazy if you’ve only worked with a smaller codebase but when projects grow, there are times when a developer ends up writing a component that already existed or a behavior variation of an existing component could have met the purpose. In such cases, the storybook acts as a go-to page to see what components & what behaviors already exist.
Check out how you can add stories to your components and make it available as a storybook, here.

React Testing Library

It comes last in this piece but this is the most important one and a lifesaver when testing React apps.
Based on this principle, and I quote the author,

The more your tests resemble the way your software is used, the more confidence they can give you.

The biggest confusion I have as a developer is when writing tests whether my suite is under mocked or over mocked. Am I testing with the right expectations?
React Testing Library comes up with guidelines about what should be tested, allowing us to test the DOM changes and updates as good as what the end-user will perceive.
Combine it with Jest and you get a robust set of APIs that you need to be able to render your components in isolation, mimic behavioral changes, and observe DOM changes.
Get started here.

I have listed the tools that have helped me. That said, there may be tools that have helped you, which you think are better than the ones I’ve listed. I’d love to hear about them.

JavaScript - All The Things, Mostly

Gaurav Behere — Wed, 01 Sep 2021 04:56:02 +0000

JavaScript - All The Things, Mostly

Curated list of awesome JS resources

Books

JavaScript: The Good Parts - Douglas Crockford
Programming JavaScript Applications - Eric Elliott
JavaScript: The Definitive Guide, 7th Edition - David Flanagan
Learning JavaScript Design Patterns - Addy Osmani
You Don't Know JS: ES6 & Beyond - Kyle Simpson
Exploring ES6 - Axel Rauschmayer
High Performance JavaScript - Nicholas C. Zakas
JavaScript for Kids - Nick Morgan
Eloquent JavaScript - Marijn Haverbeke
Effective JavaScript - David Herman

Video Tutorials
What the heck is the event loop anyway? | Philip Roberts | JSConf EU
JavaScript Tutorial for Beginners: Learn JavaScript in 1 Hour [2020]
JavaScript Tutorial for Beginners - Full Course in 8 Hours [2020]
Learning Functional Programming with JavaScript - Anjana Vakil - JSUnconf
JavaScript: The Good Parts
ES6 and Beyond Workshop Part 1 at PayPal (Jan 2017)
ES6 and Beyond Workshop Part 2 at PayPal (March 2017)
Jafar Husain: Async Programming in ES7 | JSConf US 2015
JavaScript: Understanding the Weird Parts - The First 3.5 Hours
Debugging The Web (Chrome Dev Summit 2016)
Rediscovering JavaScript by Venkat Subramaniam
Franziska Hinkelmann: JavaScript engines - how do they even? | JSConf EU
Recursion, Iteration, and JavaScript: A Love Story - Anjana Vakil | JSHeroes 2018
Learn JavaScript - Full Course for Beginners
Object-oriented Programming in JavaScript: Made Super Simple | Mosh

Courses
JavaScript Fundamentals Workshop
Learn JavaScript
The Complete JavaScript Course 2020
JavaScript Tutorials for Beginners
Getting Started With Javascript | Javascript Tutorial For Beginners
JavaScript Best Practices
JavaScript Tutorials and Courses

Useful Blogs/Articles
Prototypes and Inheritance in JavaScript
A Guide to Proper Error Handling in JavaScript
Service Workers: an Introduction
10 JavaScript concepts you need to know for interviews

Websites
Google Web Developers
ECMAScript 6
Node JS
MDN
JavaScript.info
Superhero.js

Dev Channels
JSConf
Google Chrome Developers
web.dev
JavaScript Daily

Publications/Magazines
JavaScript on Medium
JavaScript on Smashing Magazine
JavaScript on Dev.to
JavaScript Weekly
Node Weekly

Useful Github Links
33-js-concepts
JavaScript Questions
Front-end-Developer-Interview-Questions
es6-cheatsheet
clean-code-javascript

People
BrendanEich
Kent C. Dodds
Addy Osmani
Paul Irish
Douglas Crockford
Ben Awad
Eric Elliott
Dan Abramov
Marijn Haverbeke
Kyle Simpson
Wes Bos
Dan Wahlin

These resources have helped me a lot in keeping up with JS. If you have a suggestion, please comment. I would love to read & add to this.

DEV Community: Gaurav Behere

The I/O ’26 Moment That Actually Stuck With Me

What Google Actually Shipped

Agents That Can Actually See the Browser

Modern Web Guidance: Opinionated Skills, Not Just Raw Power

A Quiet Reframing of Web Work

Concrete Use Cases That Actually Make Sense

Where This Still Falls Short

How I’d Actually Use This on a Real Team

Why This Might Be One of I/O ’26’s Most Important Announcements

Time to say goodbye to Webpack?

Lets have a closer look at Vite

So what does Vite do to make the development experience better?

That essentially means no time spent on bundling your code before the server can start.

Awesome, so why bundle for production?

Getting started with Vite

Hot replacement of modules (HMR)

Recap

Server side rendering

So should we just move to Vite & stop using tools like Webpack?

Unit testing service workers

Prelude

Note

Problem with the current version (2.0.5) of service worker mock

Workaround

Testing Event registration

Testing cache deletion on activation

Testing fetch event to see if it returns cached response

Testing if fetch event makes network call & updates cache. Also test any custom logic like appending a bearer token in the request

Testing if the requests to the external domains are ignored

Coverage

Epilogue

Inversion of Control — A simple & effective design principle

Reducing code complexity with IoC

Inversion of control (IoC)

What does this translate to in code?

What does it lead to?

Inversion of Control

How does it help?

Conclusion

Re-architecting authentication with Service Workers

Challenges

How can we have a centralized solution which avoids making changes to a lot of files?

Changes in the container app

Things to note

Must-Have Weapons in Your React Armory

React Dev Tools

Styled Components

React-Intl

Storybook

React Testing Library

JavaScript - All The Things, Mostly

JavaScript - All The Things, Mostly

Curated list of awesome JS resources

Books

Video Tutorials

Courses

Useful Blogs/Articles

Websites

Dev Channels

Publications/Magazines

Useful Github Links

People

Lets have a closer look at `Vite`

So what does `Vite` do to make the development experience better?

Getting started with `Vite`

So should we just move to `Vite` & stop using tools like Webpack?