Dropping browser support can take you places

There was a time in the front-end world where browser compatibility skills were a must-have. You’d spend hours debugging why something worked in Chrome but broke in IE11. Today, things are a lot better. The web is more standardized, and browsers don’t take too long to catch up when something new and cool comes along. But now and then, you still run into problems.

Let me take you back to 2021. I was working at this company, and we were building a customizable JavaScript SDK for different business units. It was a B2B thing, so flexibility was key. As one of the core maintainers, I juggled API design, breaking changes, and trying to keep up with new tech while ensuring everything stayed consistent and innovative.

The hackathon idea

During one of our hackathons, we had this lightbulb moment: What if we used CSS variables for theming? It sounded perfect. No more bundling different styles, no complex configurations, just let users override the theming with a few lines of code. It was clean, modern, and exactly what we needed.

But then, reality hit. We checked for browser compatibility and bam—CSS variables weren’t supported in some of the browsers we were supposed to support. IE11, of course, was the main problem.

The roadblock

At first, it felt like a dead end. We were told we had to support these browsers. But something didn’t sit right with me. Were we going to let a tiny fraction of users hold us back? I decided to dig deeper into the analytics, and what I found was interesting but surprising.

Turns out, IE11 was used by less than 2% of our customer base. And get this—some people were accessing our site on a PlayStation 2. A PlayStation 2! I couldn’t help but laugh. Were we going to block innovation for a handful of users, including someone browsing on a console from 2000?

Making the call

Armed with the data, we brought it to the team. The decision wasn’t as hard as I thought. We set a threshold for browser support—something we hadn’t defined before—and agreed that supporting IE11 (and, yes, the PlayStation 2) wasn’t worth the cost. It was holding us back, and it was time to let go.

The best part? We didn’t have to convince many people. The numbers spoke for themselves. Why block progress for less than 2% of users? It just didn’t make sense.

The aftermath

Dropping IE11 support was like a breath of fresh air. We could finally move forward with CSS variables, and the theming system turned out even better than we’d hoped. Users loved it, and our team was thrilled to be working on something modern and innovative instead of wrestling with old browsers.

But it wasn’t just a technical win. It was a reminder to make decisions based on impact, not fear. Sometimes, you have to let go of the past to move forward.

After that moment to prevent this from happening again, we decided to put a threshold and a deprecation policy in place, like most library maintainers do, we have to let things go, so we can jump to whatever comes next.

Takeaways

Look at the data. Analytics don’t lie. If something doesn’t add up, dig deeper.

Set limits. Define what you’re willing to support, and what you’re not.

Don’t let a small group hold you back. Supporting a tiny fraction of users shouldn’t block the majority.

Final thought

Looking back, it’s funny how something as small as dropping IE11 support can feel so freeing. It’s not just about the tech. It’s about making space for innovation and focusing on what matters. So, the next time you’re stuck maintaining something outdated, ask yourself: is it worth it? Or is it time to let go and take your team (and your sanity) to new places?