We Are Google Lab Rats

I developed web services before Larry or Sergey even thought about Google. From back then to now I have morphed from being a web-technology engineer to a dumb woker-rat in Google’s laboratory. And it pisses me off.

I remember times when we had to code a web-site in multiple versions because, well, you know – Microsoft and it’s infamous Internet Explorer. They had pretty much cornered the market and it was their way or no way. Those times are over, but another company has cornered the market and they are not a bit better. Nowadays you do as Google wants you to do or .. well .. you get the idea. With Mozilla following on Google’s heels towards a steady dwindling market-share, they are not much of an alternative either.

I don’t have a problem following guidelines. When Chrome implements a certain service or API, of course I will have to follow their rules on how to implement it. So – where’s my problem? Simple. They change the rules all the time. They ignore W3C standards. They break things and refuse to repair it. The whole Chrome project looks like a play-ground for sometimes very weird philosophies.

But let me give you a few examples:

AUDIO and AUTOPLAY: The <audio> element is a W3C standard. The “autoplay” attribute is defined as follows: “When present, the user agent (as described in the algorithm described herein) will automatically begin playback of the media resource as soon as it can do so without stopping.” This element and it’s attribute have been around for years – and website visitors bothered by autoplaying sound had two simple choices: Accept it or don’t visit the web-site again. But Google (and, of course, Mozilla) decided they had to change this. So they simply ignored the “autoplay” attribute. Think about it: They overrode the developers intentions by unliterary ignoring a W3C standard that has been around for years. Google even “invented” a “Media Engagement Index” that measures how and when a user interacts with a web-site and calculates a media engagement score to decide if “autoplay” is allowed or not. This broke several benign web-applications I wrote: A record player, but even more problematic, a network monitoring tool that would sound an alarm when something went wrong. Other advanced web-serviced developed by other engineers where affected too. I made suggestions to make this new rule more palatable. Like a permissions pop-up if “autoplay” is encountered. But to no avail. Back to the hamster-wheel, you lab rats.

Web-Push API: Have you ever heard of web-push? It allows web-sites to push notifications to your desktop or mobile device. In order to allow this, users have to agree to a notification request. It’s really a cool idea. You can get new headlines or other notifications even if you are not on the web-site. I use it to signal incoming messages and other important events. And it used to work very well. Until Google’s Android operating system introduced the “doze” mode putting apps to sleep when the phone is not being used. No more notifications. Not even for installed (added to home screen) web-apps. They just broke it and, though the bug has been known since 2017, refused to fix it. So – this API has become useless. The lab-rat can struggle as much as she wants. Nobody cares.

Web-RTC: Now here’s is a great idea: Direct voice,video or data sharing between participating browsers. Just talk or video-conference with somebody directly in your browser – share the Desktop or arbitrary data. It too used to work very well. With a catch of course: How do you signal an incoming call? The Web-Push API could be used. If it would be working. But it doesn’t. So you have to call the other end to tell him or her that you would like to call him in the browser. Does this make sense to you? And here’s another problem: The “autoplay” doesn’t work (see above). Even if you are able to catch the other party and to initiate a call or video session, unless you are Google “magically” permitted to initiate auto-playback of the receiving stream, the Web-RTC session is mute. Literally.

I could extend this list quite a bit more. For example: How do you deal with functionality that has been marked as “obsolete” for years? Take the “ScriptProcessorNode” as an example. It is used to patch JavaScript code into the Web-Audio stream. It has been marked as deprecated since 2014. But the replacement, a contraption called “AudioWorklet”, isn’t even available in most browsers.

Not to mention the fact that the new proposed methods follow a completely new philosophy and all sources will require a rebuild from scratch. Talking about a hamster wheel. So – how do you deal with a new project that requires “ScriptProcessorNode” or “AudioWorklets” ? Use what is available and prepare to completely rebuild in a year or so? Or use the new stuff which is still not supported in all browsers and that may change in the future anyway?

Look: Chrome is not only the de facto standard for all web-environments, it is also a monopoly. They treat the world-wide developer community with blatant disregard. As long as we web-coders just keep our heads down and quietly accept whatever someone with a “google.com” email-address tells us, nothing will change. We will continue to drive the hamster wheel in perpetual motion. We will remain Google’s lab rats.

So what can we do? For once: We can organize. A single coder tweeting won’t change a lot. A thousand tweets may change things. That’s why I started the W3 Coders Association. It’s not much for now. But when we join forces, it may become something bigger. But I can’t do it alone.

So – please visit my initial W3CA web-site and leave your email address. I would also appreciate it if you would talk to co-workers and other folks about it. Or contact me to tell me your ideas. You may even tell me about the lousy web-site. Thanks.