The Web Has No Guardrails, and That's the Point

As a frontend engineer, one thing that hit me hard is how endless the possibility of errors feels on the web. I once had a button that worked perfectly on Chrome. On Safari, nothing happened when users clicked it. The issue? Safari blocks window.open if it’s not called synchronously from the user’s click. My code was fetching an API first, then opening the URL, and Safari treated that as a popup. I had to open a blank window on click, then set the URL after the API responded. That kind of thing only shows up on specific browsers, and it’s just one example. Screen sizes, device series, browser brands, browser versions, network conditions. The combinations are practically infinite. You can’t account for all of them, and something will always look or behave slightly different somewhere.

Then I looked at mobile development. Everything feels like you can just… limit it. Set a minimum OS version and suddenly a huge chunk of edge cases disappears. Only support the last two iPhone sizes. Done. The environment is controlled.

That’s when I learned the term: controlled environment.

What “Controlled Environment” Actually Means

A controlled environment is one where you, as the developer, get to define the boundaries of where your software runs. You decide the hardware, the OS version, the rendering engine, and the screen dimensions your app needs to support.

Mobile development is a controlled environment. You ship to the App Store or Play Store and say “this app requires iOS 16+” or “Android 12+“. Users who don’t meet that requirement simply can’t install it. A huge chunk of the problem disappears before it starts.

That said, “controlled” is a spectrum. iOS is the most controlled since Apple owns both the hardware and the OS, so you’re dealing with a small, known set of devices. Android lets you set a minimum OS version too, but you still face device variety from dozens of manufacturers with different screen sizes, OEM skins, and hardware capabilities. It’s still more predictable than the web, just not as tight as iOS.

Web development is the opposite. You ship a URL and anyone with a browser can open it. Old browsers, tiny screens, massive ultrawide monitors, slow 3G connections, browsers you’ve never heard of. You don’t get to choose your users’ environment. They choose it for you.

What the Web Loses

The lack of a controlled environment is the core reason frontend web development feels harder than it should be.

• Screen sizes are infinite. Mobile has a defined set of devices per platform. Web has everything from a 360px phone to a 3440px ultrawide, and every size in between.
• Browser engines differ. Chrome uses Blink, Safari uses WebKit, Firefox uses Gecko. They interpret CSS and JavaScript slightly differently. A layout that looks perfect in Chrome might break in Safari.
• Browser versions stack up. Users don’t always update their browsers. You might need to support Chrome from two years ago because a chunk of your users are still on it.
• You can’t enforce a minimum. There’s no “this website requires Chrome 120+” gate. You can show a warning, but you can’t stop someone from opening your site on Internet Explorer if they really want to.
• Mobile browsers add another layer. Your website also runs on mobile Safari and Chrome on Android, and they don’t behave the same as their desktop counterparts. Safari on iOS has viewport height issues when the address bar shows and hides, position: fixed behaves differently, and strict privacy rules that block patterns like redirects, window.open, and popups. These restrictions protect users, but they mean developers need workarounds for legitimate use cases.
• Accessibility adds yet another. Screen readers, keyboard navigation, and other assistive technologies interact with your site in ways you might not expect. It’s another axis of variability that mobile apps handle more consistently through platform-provided accessibility APIs.

This is the tradeoff you accept when you build for the web.

What the Web Gains

But that same openness is also the web’s biggest advantage, and it’s massive.

You ship in seconds, and iterate just as fast. Push your code, and it’s live. No app store review. No waiting for Apple or Google to review and approve your hotfix. No hoping users actually update the app. You deploy, users refresh, done. Found a bug in production? Fix it, deploy, and it’s fixed for everyone immediately. On mobile, you submit a patch, wait for review, and then hope users update. On the web, the feedback loop between “found a problem” and “problem is fixed for all users” can be minutes.

No install friction. A URL is the lowest barrier to entry in all of software. No download, no storage space warning, no “update available” nag. Just click and you’re there.

This speed is why startups often start with web, especially in SaaS and B2B. When you’re trying to find product-market fit, the ability to ship and iterate multiple times a day is worth more than a perfectly controlled environment.

How to Deal with It

You can’t turn the web into a controlled environment. But you can bring some of that control into your workflow.

Define Your Own Support Matrix

Just because the web is open doesn’t mean you have to support everything. Be intentional. Check your analytics, see what browsers and screen sizes your actual users are on, and let that data drive your decisions. Don’t guess. If 90% of your users are on Chrome and Safari, that’s where you focus. Define a support matrix like “we support the last 2 versions of Chrome, Firefox, and Safari, and screen widths from 375px to 1440px.” That’s your controlled boundary.

Use Responsive Viewer for Chrome

Chrome DevTools has a built-in device toolbar for testing one screen size at a time, but if you want to see multiple viewports simultaneously, use the Responsive Viewer Chrome extension. It shows your web app across multiple device widths at the same time, side by side. You see your 375px mobile view, your 768px tablet view, and your 1440px desktop view all in one screen. It turns “did I break something on mobile?” from a 5-minute manual check into a glance.

Use Playwright for Cross-Browser Testing

For browser differences, use Playwright. It lets you run your tests across Chromium, WebKit (Safari’s engine), and Firefox automatically. Instead of manually opening three browsers and clicking through your app, you write the test once and Playwright runs it on all three engines.

# Install Playwright with all browsers
npm init playwright@latest

# Run tests across all browsers
npx playwright test --project=chromium --project=webkit --project=firefox

This is how you bring “controlled environment” thinking to the web. You can’t control what your users use, but you can verify that your app works across the environments that matter.

The Mindset

The web has no guardrails. You can’t pick your users’ browsers, screen sizes, networks, or devices. That’s not a flaw. That’s the point.

The web was built to be open and accessible to everyone. That openness is exactly why a URL can reach anyone on the planet without an app store, without a download, without permission. No other platform gives you that.

But that doesn’t mean you have to suffer through it. Define your boundaries. Automate your testing. Use the right tools. And if you need some of mobile’s strengths, Progressive Web Apps (PWAs) are an option, they can be installed, work offline, and access device APIs without giving up the web’s reach.

You trade control for reach. That’s the deal. And with the right approach, it’s a deal worth taking.

All the experiences in this post are real, but AI was involved in writing this blog. If anything seems off, feel free to let me know.