8 posts tagged with "Frontend Development"

You are building a screen against an API that is not ready, or you need to see what the page does on a 500, an empty list or a slow response. The fastest way to get there is a browser extension that answers the request for you, so the page receives your response as if the server had sent it.

There are dozens of extensions that claim to do this. This post covers the ones worth installing in 2026: what each does, what it is best for, what the free tier gets you and where it stops. I build tweak, so it comes first, but I will tell you when another tool is the better fit.

Your computer is in one time zone, your CI runner is in UTC, and your users are everywhere else. A date that renders fine on your screen can be a day off in Sydney, an hour off the week clocks change, and "today" can mean yesterday for a customer in Los Angeles. Most of these bugs are invisible until someone in the wrong place opens the page.

The fix is to look at the page from another time zone on purpose. This guide covers four ways to change the timezone in Chrome for testing, what each one actually changes, and a checklist of the cases worth checking once you can.

The bug only happens on production. The fix is in your editor. Deploying a branch to find out whether it works takes twenty minutes, and you will need three tries. What you want is the production page, with its real data and its real login, talking to the code running on your machine.

That is a redirect: when the page asks for https://api.example.com/... or https://cdn.example.com/app.js, the browser goes to http://localhost instead. This guide shows how to do it in Chrome with a free redirect rule, and the four or five things that will get in your way the first time.

The Network tab is where most frontend bugs are actually solved. A blank screen, a spinner that never ends, a form that "does nothing": open the Network tab and the answer is usually one row away. Most developers use about a fifth of it. This guide goes through the rest: the filters, the details panes, the right-click menu, and the features hidden under More tools.

Everything here is Chrome's DevTools, and the same in Edge and other Chromium browsers. Firefox's Network Monitor has most of the same features under slightly different names.

You call an API from your frontend, the request shows up in the Network tab with a perfectly good response, and your code still gets nothing but this in the console:

Access to fetch at 'https://api.example.com/orders' from origin 'http://localhost:5173'
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on
the requested resource.

This post explains what the browser is doing, how to read the variations of that message, how to fix it properly, and how to get unblocked right now while you develop, with one click.

The happy path gets tested every time someone opens the app. The error paths get tested when production breaks. That is backwards: an error screen is the one screen a user sees when they are already frustrated, and it is usually the least reviewed code in the project. The reason is simple: errors are hard to produce on demand. The backend works, so you cannot see what happens when it does not.

This guide lists the failures worth testing, what a good UI does for each, and how to produce every one of them in the browser without changing a line of backend code.

Sooner or later every frontend team builds a screen against an API that does not exist yet, is down, or cannot be made to return the case you need. There are two broad ways to fake it in the browser: put the mocks inside your app with a library like Mock Service Worker (MSW), or put them outside your app with a browser extension. They solve the same problem from opposite ends, and picking the wrong one costs you either setup time or test coverage.

To mock an API call is to answer a request your app makes with a response you wrote, instead of the one the server would send. The app cannot tell the difference: it receives the JSON, the status code and the headers you chose, and renders whatever they lead to.

You need it more often than you would think. The endpoint you are building against does not exist yet. A bug only shows up with a payload you cannot reproduce. The staging server is down on demo day. You want to see the screen for a 500, an empty list or a response that takes eight seconds. In all of these, waiting for the backend is the slow option.

This guide covers what mocking is, the three ways to do it and their trade-offs, then shows step by step how to mock a response right in the browser with tweak: no code, no proxy, no change to your app.