The Bizarre APIs That Shaped the Modern Web (And What They Teach Us About Tech Decisions)

Let's play a game: name the weirdest browser API you know.

If you're a frontend developer, you probably immediately thought of canPlayType(). This method on HTMLMediaElement returns three possible values: an empty string (no), "probably", or "maybe". It's a probabilistic answer wrapped in vague language, and honestly, it's a bit of a mess.

But there's another API that really showcases the web's commitment to never breaking existing code: History.pushState().

When you call pushState(), you're supposed to pass three parameters: state, title, and url. The state object makes sense—it lets your app restore data when users click the back button. The URL parameter is useful for updating the browser's address bar without triggering a page reload.

But that title parameter? It's completely ignored. Every major browser discards it entirely.

So why does it exist?

Back in 2008, when the History API was first drafted, someone thought browsers should let apps set a custom title for each history entry. The idea was that your SPA could show "Dashboard" in the app while storing "Analytics Report" in the browser history.

It sounded reasonable at the time. But browsers quickly realized this would create confusing situations—what happens when a user bookmarks a history entry and the title doesn't match what they see in their browser tabs?

Rather than deal with that headache, browsers simply ignored the parameter. By then, though, countless sites had already built their apps expecting three parameters. Removing it would break production sites. Making it optional would cause confusion with existing pushState(state, url) calls.

So the spec did something elegant: it renamed the parameter to unused and documented that it has no effect.

This is the web's dirty secret—we prioritize backward compatibility over almost everything else. The web will bend over backward (sometimes literally) to ensure that code from 2008 still runs on today's browsers.

This philosophy is exactly why we advocate for static sites and proven web technologies at NameOcean. When you're building something that needs to last—media archives, documentation, landing pages—the stability of vanilla web technology isn't a limitation; it's a feature.

The same principle applies when you're choosing a domain registrar or hosting provider. You want companies that understand the long game. The web isn't going anywhere, and the technologies you build on today should still work a decade from now.

There's a lesson here for developers and startups alike: sometimes the "wrong" decision becomes permanent not because it's correct, but because too much depends on it. That's not a bug in the web—it's a feature that keeps millions of sites running smoothly.

The next time you encounter a quirky API or deprecated parameter, remember: someone, somewhere, made a judgment call years ago, and now it's carved into the foundation of the web. Respect the weirdness. It's keeping things working.