Before I go: When it comes to complaining about web browsers

I’m not planning on leaving the industry (yet), but before I go I’d like to offer up what I know when it comes to complaining about web browsers.

I have logged hundreds of hours complaining about browsers on Twitter, on podcasts, and on this blog. I have logged thousands more hours trying to keep up with browsers and I frequently interact with people who write specs and make browsers. I have not been 100% successful in my efforts to get a <rupert> element as my legacy but I have learned a lot about giving feedback to web browsers.

Browsers are really complex

Eric Meyer recently put it very well…

[W]eb browsers are actually 60fps+ rendering environments. They’re First-Person Scrollers.

When you complain about browsers, the first thing you must know is: Browsers are big, complex pieces of software that must run very, very, very fast.

“Browsers should do _______” may sound like an easy feature, but have you considered that your idea might be a bad idea? Not just bad on paper, but bad on a bad for computers level. Browsers render the page at 60fps even while scrolling so your idea must work within a 4ms window… along with the million other tasks the browser is trying to do during that same 4ms window.

To get your feature implemented you’ll need either a giant pile of cash or the willing ear of someone who works on a browser. And then you’ll need lots of consensus. Browsers are an exercise in consensus building; getting consensus for features inside your company, then shop it to web developers, then with other browsers, then you have to run the gauntlet through the official W3C working group tracks on the path to standardization. It’s consensus all the way down. Lots of input and lots of compromises along the way.

Let’s dig into some of the different ways we lay people can offer input and what I think works and doesn’t work based on past attempts.

Talking shit doesn’t work

Complaining on Twitter sure does feel good but it doesn’t do much other than burning bridges and burning through people’s patience. I guess you may also get hit with the mute button which is probably the opposite effect you were hoping for. Despite how good or valid your complaint is, combativeness results in immediate dismissal by your target audience… not once, but for years. People hold grudges for a shockingly long time.

Jokes, snark, and sarcasm walk a thin line too. Exhibit A: I know some people at Google are a bit salty with me because I made a dumb joke on Twitter about <toast>, AMP, and Chrome seemingly over-exerting its dominant market share position in 2019. The irony here is I actually like the <std-element> pathway, but my commentary (punditry?) didn’t help as I joined the pile on, which was so bad that no one wants to ever try shipping native web components ever again.

Being toxic and abusive to the people that make browsers doesn’t add to the conversation. One possible goal it might achieve is amplifying feelings of burnout in the people you’re hoping will adopt your cause. We don’t need to be naive about business incentives (e.g. AMP, App Store revenue, developer mindshare landgrabs, etc) but we can dial back the heat a bit.

I recommend being specific about the features you need, curb the outrage.

Saying “is the new IE” doesn’t work

To the previous point, lobbing general criticisms of monopolistic behaviors or constant out-of-datedness doesn’t help further the conversation. I agree that browsers probably need to go to court more for their behavior, but each browser company has its own historical baggage. Browser folk and fanboys will often deflect with whataboutism and invoke some kind of other finger pointing (Safari’s slow release cycle, Google’s data collection, Brave CEO’s support of California’s Prop 8 in 2007, Mozilla’s mass layoffs and dependency on Google Search money, Microsoft’s actual IE monopoly, etc). The criticism doesn’t land like it used to.

I’d recommend being specific about what features are missing and what is holding you back.

Yelling about privacy sort of works

Privacy is important and can raise security flags, but invoking privacy like a boogeyman doesn’t go far. Privacy is such a big topic, people (and corporations) often have different perspectives on what qualifies as a privacy invasion. Raise the flag, yes, it’s important to yell about what’s important but don’t let them run off and decide what “privacy” means.

It’s better to be specific about what privacy measures you are requesting.

And now for the best thing you could ever do…

Blogging your specific problems works

The best thing I’ve ever done in my career is blog about my specific problems with browsers (or any software you’re passionate about). This goes for software beyond browsers too. I’ve done this for IE, Safari, Edge, Firefox, Chrome, Windows 10, WSL and I’ve seen first hand how a “friction log” can become a powerful tool in an organization.

Behind the scenes, your posts will get picked up by external-facing developer advocates and shared internally. A single blog post is worth 10,000 tweets. It’s valuable because it shows you thought through your problem and narrowed it down to a set of specific issues. All the more if it’s non-combative (see above). I’ve seen this play out dozens of times.

A simplified example of a problem solved by Container Queries is a million times more helpful than an abusive “Support Container Queries, ya fuckers” jab. A list of features causing expensive workarounds is great. If you’re blocked on a feature due to a lack of implementation… blog it.

I’ll even simplify this into to a user story for you:

When building [project]
I couldn't accomplish [task] 
Because [browser] 
Doesn't support [feature]

Add a bit more context or story there, edit out the drama, and I think you’ve got a legitimate and useful criticism people can act on. You may even get on Hacker News (not that you’d want to do that). There may be times where you’ll need to raise the social temperature on an issue, but you have to start here and outline the actual problems first.

Other activities that help

If intentionally collecting your thoughts and blogging sounds like too much, here’s some other entry points in providing feedback to browsers.

Responding to browser surveys helps - If you see someone from a browser ask for feedback, jump on it. These surveys turn into internal data that get put in powerpoint decks and shared around.
Starring issues helps - If a browser has an open bug tracker and you can star issues, do it. It sends a signal to engineers that this it’s an important request. No need to comment unless you have stack traces, a star is enough.
Saying “Thank you” helps - You catch more flys with honey than you do with vinegar. If a browser or someone you know shipped a cool feature, say thank you. Give that person or team some recognition. Heck, they may even get promoted and have more internal leverage. Do that over and over and guess what, I bet if you have an actual complaint people will listen.
Making demos helps - Hear about a beta feature or an origin trial? Play with it! Find a way to crash the GPU? File a bug! Making demos in CodePens or some other sharable code format is probably the fastest way to become a person who gives feedback to browsers and they may even start reaching out to you for feedback first.

Wrapping up, there’s one more thing you can do…

Make other browsers better with this one weird trick

If you truly want other browsers to get better… use other browsers! Money tends to follow eyeballs. Engineers get apportioned appropriately. And be sure to blog your troubles along the way.

Thus ends the imparting of what I know when it comes to complaining about web browsers.