What The Web Can Actually Do

I used to think I knew the browser.

DOM manipulation, event listeners, fetch, maybe localStorage. That was the complete picture in my head. Build the UI, respond to user input, talk to the server.

Then I found out the browser can read NFC cards.

The browser I thought I knew was a small corner of the platform that actually exists.

The Platform Nobody Told You About

There are two ways to learn about the browser. The first is the obvious path: follow a JavaScript tutorial, learn the DOM, learn how to build UIs. That curriculum is well-worn and easy to find.

The second path is less obvious, and most developers skip it entirely. Underneath the document layer sits a massive API surface for hardware integration, physical sensors, OS-level integrations, and device connectivity.

Most of this has been available for years. The Geolocation API shipped in 2013. The Gamepad API in 2014.

The reason most developers don't know them isn't that they're obscure or experimental.

It's that nobody put them in the curriculum.

What a Web Capability Actually Is

A web capability is any browser API that lets a web app do something that previously required a native app.

That's a wide definition on purpose. It covers:

• Sensors and location -- the accelerometer, gyroscope, magnetometer, and GPS built into your device
• Input devices -- touch events, device orientation, gamepad controllers, virtual keyboard APIs
• Speech and vision -- voice recognition, text-to-speech, face detection, barcode scanning
• Hardware devices -- Bluetooth peripherals, USB devices, NFC tags, serial connections, MIDI instruments
• OS integration -- PWA installation, file type handlers, URL protocol handlers, window management
• Security and permissions -- the model that controls who can access what

ExpandThe Web Capabilities Landscape

None of these are fringe topics or vendor experiments. Most are shipping in all major browsers right now. The web has spent the last decade quietly becoming something that looks a lot more like an operating system.

Why Most Developers Miss This

The browser's API surface has a visibility problem.

Search "learn JavaScript" and you get DOM tutorials. Search "learn React" and you get component tutorials. The curriculum points inward, toward the document layer, and away from the hardware layer underneath it.

The hardware layer doesn't announce itself. You won't discover the Web Bluetooth API by accident. You won't bump into the Gamepad API while building a to-do app.

Knowing what exists is a prerequisite for reaching for the right tool. You cannot solve a problem with something you don't know about.

What This Series Covers

This series is a survey of the landscape, not a deep dive into any single API.

The goal is to build a mental map. When a product requirement lands on your desk that sounds like "this probably needs to be a native app," you should already know whether the web can handle it. Each post covers one area: how the permission model works, how sensors report data, how to wire up Bluetooth, how to make a web app install and behave like a native one.

To make it concrete, I'll also build a small recipe app that uses several of these APIs together: voice commands for navigation, gamepad controls for scrolling, NFC tags to jump to a specific recipe. The kind of thing that sounds like it needs an app store.

It doesn't.

Why This Matters Now

Clients want installable web apps. Users are on mobile-first devices. Teams are building products where the web layer needs to feel native.

The "this needs to be a native app" answer is less true every year.

The PWA section and the Service Workers deep dive later in this series show what production-ready installation and offline support look like. But both of those sit on top of a foundation -- understanding what the platform can actually do.

That foundation starts here.

Next up: not all these APIs are safe to ship today. Some work in every browser on every platform. Some are experimental. Some are behind flags. Before touching any capability, you need to know how to read the landscape -- and that starts with understanding what API maturity levels actually mean.

The Essentials

1. The browser exposes far more than the DOM layer -- hardware, device connectivity, sensors, and OS integration have been available for years and are underused because they're undertaught.
2. A web capability is any browser API that replaces something that previously required a native app. Six areas: sensors, input devices, speech and vision, hardware, OS integration, and permissions.
3. Knowing what exists is a prerequisite for using it. This series is the map before the deep dives.

Further Reading and Watching

• A Tour of Web Capabilities by Max Firtman -- Course Preview -- Frontend Masters preview covering the full capability landscape in one sitting
• Learn PWA -- web.dev -- Google Chrome team's open-source guide with a full chapter dedicated to browser capabilities