DEV Community: Odiri Teddie

Service Workers Explained Like You're Building Your First PWA

Odiri Teddie — Mon, 20 Jul 2026 14:43:56 +0000

Spend any real time poking around Progressive Web Apps (PWAs), and sooner or later you’ll run headfirst into Service Workers.

The line you’ll hear over and over is that they’re "a proxy between your app and the network."

Which is true, and also close to useless if what you’re actually after is why they exist and what they buy you.

Here’s the framing that finally made it stick for me:

A Service Worker is a programmable layer sitting between your app and the internet, handing you the controls over how every request gets dealt with.

That’s the thing that unlocks offline support, smarter caching, background sync, push notifications — the stuff that starts closing the gap between a web app and a native one.

So in this piece I want to build up a mental model of Service Workers, show where they sit inside a PWA, and make the case for why they’re worth your attention even if you never plan to go fully offline.

What Problem Do Service Workers Solve?

Say you’ve thrown together a little weather app.

Each time someone opens it, the browser pulls down:

HTML
CSS
JavaScript
Images
Fonts
API responses

Now knock out their connection, and the whole thing just falls over.

Not because the browser can’t paint the UI — it’s because it has no idea what it’s meant to do the moment a request comes back empty.

With no Service Worker in the picture, every request walks the same simple line:

Browser
     ↓
 Internet
     ↓
 Server
     ↓
 Browser

And the browser gets almost no say in any of it.

A Service Worker changes the flow.

Browser
     ↓
Service Worker
     ↓
Cache or Network
     ↓
Browser

Now your application can decide:

Should this request come from the cache?
Should it go to the network?
If they’re offline, do I fall back to something cached?
Is this response worth holding onto for next time?

The browser’s defaults stop being the only option, and the decisions become yours.

What Exactly Is a Service Worker?

At its core, a Service Worker is just a JavaScript file — but one that runs off to the side of your actual page.

It never touches the DOM, which already sets it apart from your React or Vue code.

Picture it more as a background process, sitting quietly and listening for browser events and network traffic.

Its responsibilities often include:

Caching application assets
Intercepting network requests
Serving cached responses
Managing offline experiences
Receiving push notifications
Performing background synchronization

And because it lives apart from your UI, it can keep doing some of its work even when nobody has your app open.

The Service Worker Lifecycle

Once the lifecycle clicks, a lot of the "why does it behave like that?" weirdness around Service Workers goes away.

It moves through three stages.

1. Registration

This is your app letting the browser know a Service Worker is around.

if ("serviceWorker" in navigator) {
  navigator.serviceWorker.register("/service-worker.js");
}

Nothing special happens yet.

The browser simply knows about the worker.

2. Installation

Now the worker downloads itself and installs.

This is typically the moment you cache your static assets.

self.addEventListener("install", (event) => {
  console.log("Installing...");
});

Think of it as the app packing a bag for later.

3. Activation

With install done, the worker flips over to active.

self.addEventListener("activate", (event) => {
  console.log("Activated");
});

This is your chance to clear out stale caches from previous versions.

And from the moment it’s active, it starts catching requests.

Intercepting Network Requests

This is the part where Service Workers actually earn their reputation.

Every single network request can be caught mid-flight.

self.addEventListener("fetch", (event) => {
  console.log(event.request.url);
});

Rather than letting the browser fetch things the usual way, you get to make the call on each request yourself.

That freedom is exactly what the more advanced caching strategies are built on.

Caching Isn't Just About Speed

Many developers associate caching with performance.

That’s true, but it’s only half of it.

Caching also improves:

Reliability
Offline support
Reduced bandwidth usage
Faster repeat visits
Better user experience on slow networks

Imagine a news application.

The newest stories might still need a connection, but the ones a reader already opened can sit there ready offline.

Which beats staring at the browser’s dinosaur error page by a wide margin.

Common Caching Strategies

Different resources benefit from different approaches.

Cache First

Check the cache before the network.

Cache
   ↓
Network (if needed)

Best for:

Images
Fonts
CSS
JavaScript bundles

Network First

Try the network first.

Network
    ↓
Cache (fallback)

Useful for:

API requests
Dashboards
Live content

Stale While Revalidate

Immediately serve cached content while downloading a fresh version in the background.

Cache
 ↓
User sees content immediately

Network
 ↓
Cache updated

This strategy creates applications that feel extremely responsive.

It's widely used because it balances speed with freshness.

How PWAs Use Service Workers

A Progressive Web App isn't defined by one feature.

Instead, several technologies work together.

Manifest
        +
Service Worker
        +
HTTPS
        +
Responsive Design
        =
Progressive Web App

The manifest controls installation.

Responsive design keeps it usable from a phone to a widescreen monitor.

HTTPS provides security.

And the Service Worker is what brings the offline behaviour, the caching, and the background tricks to the table.

Pull the Service Worker out and most of what makes a PWA feel like a PWA goes with it.

Things Service Workers Can't Do

For all they can do, Service Workers aren’t a magic wand.

They cannot:

Access the DOM directly
Modify React components
Read page variables automatically
Run on insecure HTTP connections (except localhost)
Replace your backend

They sit alongside your app and support it; they were never meant to stand in for its architecture.

Common Mistakes

Almost everyone trips over the same few things the first time they play with Service Workers.

Caching Everything

Not every response belongs in the cache.

Dynamic data often needs different strategies than static assets.

Forgetting Cache Cleanup

Old cache versions accumulate over time.

Always remove outdated caches during activation.

Assuming Everything Works Offline

Offline support requires planning.

It’s on you to draw the line between what’s safe to cache and what genuinely needs a live connection.

Ignoring Updates

Shipping a new deploy doesn’t just swap out the Service Worker that’s already running.

If you don’t get your head around the update lifecycle, you’ll end up with users quietly stuck on an old build.

Should Every Website Use a Service Worker?

Not necessarily.

A simple marketing website may not benefit much.

The apps that tend to get the most out of them include:

SaaS dashboards
E-commerce platforms
Productivity tools
Travel applications
Educational platforms
News applications
Field service applications
Offline-first business tools

The more your users are counting on the thing being fast and dependable, the more a Service Worker pays for itself.

Final Thoughts

Service Workers feel daunting early on, mostly because they drop you into a new execution context and ask you to rethink how requests work.

But the moment the underlying model lands, the rest tends to fall into place quickly.

Stop picturing each request as something the browser just fires off to a server on autopilot. Picture a gatekeeper instead — every request stops at it first, and that’s where your app gets to choose: go fetch something fresh, hand back a cached copy, or handle a flaky connection without falling apart.

That one shift in how you see requests is really what the whole idea of a PWA rests on.

Small weekend project or a full production app, it doesn’t much matter — getting comfortable with Service Workers is one of those steps that quietly makes everything you ship faster, sturdier, and nicer to actually use.

10 Internationalization Mistakes Frontend Engineers Keep Making

Odiri Teddie — Mon, 13 Jul 2026 14:01:27 +0000

Say internationalization (or i18n, if you’ve typed it enough times) to most people and their mind jumps straight to one thing: translating the text.

That’s part of it, sure. It’s nowhere near the whole thing.

Internationalisation is really about building your app so it can bend to new languages, regions, and cultural expectations later without you having to tear the architecture apart to get there. And in practice that reaches into far more than you’d expect — routing, layouts, how you format dates and currencies, accessibility, performance, right down to the shape of your backend APIs.

I’ve watched "let’s add a second language" land on a board as a small ticket, then quietly detonate once someone actually started on it. Turns out the codebase was full of assumptions nobody had written down. Buttons ran out of room, layouts buckled, dates came out wrong, the currency left people second-guessing what they were paying, and the whole navigation fell apart the moment it hit a right-to-left language.

Here’s the reassuring part: nearly all of this is avoidable once you know where to look.

So here are ten of the internationalization mistakes I see frontend engineers make again and again, and how to stay clear of each one.

1. Treating Internationalization as "Just Translation"

This one is the misconception the whole topic suffers from.

Translation is a single slice of internationalization, not the pie.

An app that’s genuinely internationalized has to account for a lot more:

Locale-specific date and time formatting
Currency and number formatting
Text direction (LTR and RTL)
Address formats
Phone numbers
Units of measurement
Local conventions and cultural expectations

For example, replacing:

<h1>Welcome</h1>

with:

<h1>{t("welcome")}</h1>

is a fine first step, but it barely scratches what building for a global audience actually asks of you.

Treat internationalization as an architectural decision, not a job you hand off to translators at the end.

2. Hardcoding User-Facing Strings

Few things make localization more painful than sprinkling hardcoded text across all your components.

Instead of:

<button>Checkout</button>

store the text in your translation files:

<button>{t("checkout")}</button>

The benefits are immediate:

Easier maintenance
Cleaner components
Consistent terminology
Simpler translation workflows
Room to scale as the app keeps growing

The moment a translator has to go spelunking through your source to find the strings, you know localization was never really part of the plan.

3. Concatenating Strings Together

Gluing strings together happens to work in English because English word order is fairly predictable.

Plenty of other languages aren’t so obliging.

Consider this:

"Hello " + user.name

Looks innocent enough, until you remember that not every language drops the name in that same spot.

A better approach is using placeholders:

Hello {{name}}

or ICU MessageFormat:

Hello {name}

This gives translators complete control over sentence structure while keeping your code flexible.

The rule of thumb I’d hand anyone: translate whole sentences, never fragments.

4. Designing Layouts That Only Work in English

English is relatively compact.

Many other languages aren't.

A button that comfortably displays:

Settings

may need to display something much longer in another language.

Likewise:

Account

could become:

Paramètres du compte

or another significantly longer phrase depending on the locale.

Lean on fixed widths, hardcoded spacing, or layouts squeezed too tight, and translated text will drag every one of those assumptions into the light.

Some good practices include:

Using flexible layouts
Avoiding fixed-width buttons where possible
Allowing text to wrap gracefully
Testing with longer translations during development

One of the simplest ways to uncover layout issues is to switch your application to a language known for longer words, such as German.

5. Forgetting About Right-to-Left Languages

Supporting Arabic or Hebrew involves much more than translating text.

Entire layouts often need to mirror.

Common issues include:

Navigation alignment
Icons pointing the wrong direction
Incorrect spacing
Misaligned forms
Broken flex layouts

Instead of writing:

margin-left: 16px;

prefer logical properties:

margin-inline-start: 16px;

Likewise:

Instead of:

padding-right

use:

padding-inline-end

Logical CSS properties flip themselves based on the text direction, which makes your layouts hold together in places physical properties would’ve broken.

6. Formatting Dates, Times, and Numbers Manually

Hardcoding a date format is a trap far more people fall into than you’d think.

For example:

07/03/2026

Is that:

July 3rd?
March 7th?

The honest answer is that it depends entirely on where the person reading it lives.

Instead of manually formatting values, use the browser's internationalization APIs:

new Intl.DateTimeFormat(locale).format(date)

The same applies to:

Time
Percentages
Decimal separators
Thousands separators

Hand the locale-specific formatting to the platform rather than rebuilding it badly yourself.

7. Assuming Every User Uses the Same Currency

Even applications written entirely in English may serve users from different countries.

Consider these:

United Kingdom → GBP (£)
United States → USD ($)
Canada → CAD ($)
Australia → AUD ($)

A dollar sign on its own tells you almost nothing about which currency you’re actually looking at.

Instead of manually formatting values:

"$25"

use:

new Intl.NumberFormat(locale, {
  style: "currency",
  currency: "GBP",
})

Now the price shows up the way someone in that region would actually expect to read it.

8. Ignoring Pluralization Rules

Pluralization is more complicated than adding an "s".

English has relatively simple rules:

1 item
2 items

Many languages have several plural forms.

Assume every language plays by English’s rules and, sooner or later, your translations start coming out grammatically wrong.

Most internationalization libraries support pluralization out of the box, often through ICU MessageFormat or similar syntax.

Take advantage of these features rather than trying to build plural logic yourself.

9. Shipping Every Translation to Every User

As your application supports more languages, translation files can become surprisingly large.

Loading every language during the initial page load wastes bandwidth and increases bundle size.

Instead:

Lazy-load translation files
Split translations into namespaces
Load only the active locale
Consider route-level translation loading

Going international shouldn’t come at the cost of how fast your app feels.

Nobody should be downloading resources they’re never going to use.

10. Waiting Until the End of the Project

Of everything on this list, this is the one that costs the most to fix.

A team builds the whole product around one language, ships it, and then someone in a meeting says:

"We need to support three more countries."

Suddenly everything needs revisiting:

Routing
URLs
Forms
Validation messages
API responses
SEO
Metadata
Content management
Layouts
Design system components

Bolting internationalization on after the fact is nearly always harder than having designed for it on day one.

Even if today it’s one language and one market, building with i18n in the back of your mind buys you room to grow later without a painful rewrite.

A Quick Internationalization Checklist

Before shipping a feature, ask yourself:

Are all user-facing strings externalized?
Are dates locale-aware?
Are numbers locale-aware?
Are currencies formatted correctly?
Does the layout handle longer translations?
Have you tested right-to-left layouts?
Are pluralization rules handled correctly?
Are translation files loaded efficiently?
Can your routing support multiple locales?
Would adding another language require changing application logic?

If you can say "yes" to those without wincing, you’re already in better shape than a lot of shipped projects.

Final Thoughts

Internationalization was never a "we’ll get to it" item. It’s a design principle, and it shapes how the whole thing gets built from the first commit.

The apps that get this right don’t just swap in translated strings — they feel native to whoever’s using them, wherever they are and whatever they speak. Getting there means treating layouts, formatting, accessibility, performance, routing, and plain user expectations as first-class parts of the build, not afterthoughts bolted to the side of the translation work.

None of this requires launching in ten languages to pay off. Even a single-market app is easier to live with when it’s built this way. And the day expansion into a new region does land on your desk, past-you will have quietly done present-you an enormous favour.

What’s the i18n gotcha that blindsided you at some point? Drop it in the comments — I’d genuinely like to hear it.

How to Choose Between Cache First, Network First, and Stale-While-Revalidate

Odiri Teddie — Sun, 05 Jul 2026 21:57:23 +0000

Caching looks simple enough on paper. Then you start building something real, and the questions pile up fast.

Should your product images come from the cache?

Should your shopping cart always hit the server?

Is it fine to serve data that’s a little stale if it makes the whole thing feel noticeably snappier?

Sooner or later, most web apps lean on one of three caching strategies:

Cache First
Network First
Stale-While-Revalidate (SWR)

Learning what each one does takes an afternoon.

Working out when to reach for which is where the actual engineering starts.

So in this piece I want to walk through the trade-offs each one makes, and leave you with a mental model you can actually apply to your own apps.

The Mental Model

Forget implementation for a moment.

Underneath, all three are wrestling with the exact same question:

When a request arrives, where should I look first?

Should the application check the cache?

Or skip that and go straight to the network?

Or hand back what’s cached right away and quietly go fetch a fresher copy in the background?

Get that question straight in your head and the rest of it stops feeling so slippery.

Cache First

Cache First checks whether a resource already exists locally.

If it’s there, you get it back straight away.

If it’s not, the app goes and grabs it over the network, then tucks it into the cache so next time is quick.

                                Request
                                   │
                                   ▼
                                 Cache
                                   │
                      ┌────────────┴────────────┐
                      │                         │
                    Found                    Not Found
                      │                         │
                      ▼                         ▼
                    Return                 Fetch Network

The obvious win here is speed.

Pulling something out of the cache beats a round trip to the server almost every single time.

That's why Cache First works well for resources that rarely change.

Examples include:

Company logos
Images
Icons
Fonts
CSS
JavaScript bundles

When to avoid it

Don't use Cache First for information that users expect to be current.

Serving an outdated shopping cart or account balance might be fast, but it creates a poor user experience.

Network First

Network First takes the opposite approach.

Rather than reaching for the cache first, it goes to the server every time to pull the newest version.

If that call goes through, you get the fresh copy.

If the network’s down, it drops back to whatever’s in the cache instead.

                                Request
                                   │
                                   ▼
                                Network
                                   │
                      ┌────────────┴────────────┐
                      │                         │
                   Success                    Failure
                      │                         │
                      ▼                         ▼
                    Return                    Cache
                    Fresh

The goal isn't speed.

It's correctness.

Network First is a good fit for data that changes frequently, such as:

Shopping carts
Notifications
Account information
Inventory
Order status
User permissions

The trade-off

The user might wait a touch longer, but what lands in front of them is the most current data you’ve got.

When getting it right beats getting it fast, that’s a trade worth making.

Stale-While-Revalidate

Stale-While-Revalidate (SWR) is the middle path between those two.

Rather than picking speed or freshness, it tries to give you a bit of each.

When a request arrives:

Return the cached version immediately.
Go fetch the newer version in the background.
Swap the fresh copy into the cache for next time.

                                Request
                                   │
                                   ▼
                      Return Cached Data Immediately
                                   │
                                   ▼
                           Fetch Latest Version
                                   │
                                   ▼
                             Update Cache

To the person using it, the app feels basically instant, and it’s quietly keeping itself current at the same time.

It’s a great fit for things like:

Product listings
Blog articles
Documentation
News feeds
Search results
Social timelines

The trade-off

For a moment, someone might be looking at slightly old content before the fresh version swaps in.

For a lot of apps, that’s a perfectly fine trade.

For anything touching banking or payments, it usually isn’t.

Choosing the Right Strategy

Don’t bother memorising definitions. Just ask yourself a couple of questions instead.

Does this resource rarely change?

Use Cache First.

Examples:

Images
Fonts
Logos
Icons
Static assets

Does it always need to be current?

Use Network First.

Examples:

Checkout
Shopping cart
User permissions
Payment status
Inventory

Is slightly outdated content acceptable if the application feels much faster?

Use Stale-While-Revalidate.

Examples:

Product catalogues
Blogs
Documentation
Search
News feeds

A Practical Cheat Sheet

Resource	Recommended Strategy
Company logo	Cache First
Product images	Cache First
Fonts	Cache First
Product catalogue	Stale-While-Revalidate
Search results	Stale-While-Revalidate
Documentation	Stale-While-Revalidate
Shopping cart	Network First
Checkout	Network First
Payment status	Network First
Account balance	Network First

Common Mistakes

Using one strategy everywhere

Not every resource wants the same thing.

An image, a payment, a notification, a set of search results — treating all four the same way is asking for trouble.

Optimising for speed instead of user expectations

Faster isn’t automatically better.

Flashing someone a stale account balance is a far bigger problem than making them wait one more second for the real number.

Forgetting that caches become stale

Caching was never only about stashing data somewhere.

It’s just as much about deciding when that data has gone off.

Whatever you cache, have a plan for how and when it gets refreshed or thrown out.

Engineering Takeaways

If only a handful of this sticks, make it these:

Cache First prioritises responsiveness.
Network First prioritises correctness.
Stale-While-Revalidate balances responsiveness and freshness.
Different kinds of data call for different caching strategies.
Optimise for what the user expects to see, not just for a green number on a dashboard.

One Thing to Remember

Every caching strategy is a trade-off. What decides the right one isn’t the tool in your hands — it’s what your users expect from the data they’re asking for.

Once caching clicks into that frame, picking between Cache First, Network First, and Stale-While-Revalidate stops being a guessing game.

If you want to go deeper, I’m putting together a much fuller guide right now — browser caching, HTTP caching, Service Workers, PWAs, and the architectural calls that sit behind modern frontend caching.