Orphis

The problem is that you are comparing a device sold to play games to a general purpose device (music, videos, games, banking, productivity, healthcare, phone, modem...).

While consumers generally don't have too many expectations from being able to do much more on a game console (though that is changing on the XBox), people expect a LOT more from their minicomputer in a phone shape. Hampering control on that device is detrimental to the consumer who paid already a LOT for that device.

And banned

Ok, because you asked nicely!

You can just have multiple Google accounts on the same phone for different countries and switch to a different store this way.

Or people could sideload the app on their phone.

There will definitely be always some rivalry between the too countries. Not animosity though, most people are over that.

Source: French

But you don't have push to talk, which is the killer feature for gamers. Proper push to talk will capture key presses even when the app doesn't have focus, the key difference with most other implementations.

And having that feature exposed to the web is a security nightmare. Unless you have a native app for your service, it's unlikely to ever have that functionality.

At the time that change was proposed, the specification was saying that browsers could optionally return, with some examples, but those are never meant to be exhaustive lists.

If it's legal to do so, then your code needs to be ready for it. Relying on a browser's specific version behavior is brittle.

And no, not all browsers currently do, all the browsers you've used in some specific scenarios behaved the way you thought, but there were already ways for it to fail before.

As nice as it is, MDN and all the other websites are just paraphrasing what is in the specification, and sometimes omitting crucial information. Yes, Javascript and web technologies are accessible and can seem simple, but the reality is a lot more nuanced than it is portrayed in most places.

The problem is that people relied on a side effect of a function that isn't guaranteed to block execution all the time (browsers are allowed to ignore those prompts) and now they have to fix their code.

Spotify used to do this.

Bugs happen, it's part of software development and no one is claiming any products from any company are exempt from them. We're only humans and it's still mostly humans writing the tests.

But the bigger story is not about solving specific bugs but how to learn from them, to make sure they don't happen in the future. It's not about putting the blame on specific individual or teams for their insufficient communication or testing.

> To be clear, we're talking about Chris Coyier right now

People are just human, they will fail to understand changes sometimes and their impact. Or maybe, they're just not going to be listening at all. Or they saw it, and then a coworker interrupted them and they forgot. If you tell people that the Earth temperature is going to raise 1 degree, most will just glance over it and not understand the ramifications.

In the end, I don't know that much about this specific change, it's not my domain of expertise, but I know you can't expect random people to receive random messages from random sources. First it doesn't scale, and second it would be preferential treatment which doesn't seem to me in line with the healthy platform the web should be.

> What view of the web does the Chrome team have if they think the majority of site operators have this kind of testing setup running?

No, it's a personal opinion.

And yes, I believe that if you have expectations on the availability of your website, it should be tested frequently enough, with automation or simply having the regular team working on the product or QA use newer browser versions on the regular. If you're only reacting to breakage instead of being proactive, you'll never be able to have a service continuously running and should lower your expectations. The platform is evolving and changing. Most of the time, the impact will be negligible, but sometimes it's not, and you should be prepared. Or you should just freeze all software updates in your company context until you can vet that every critical component works fine.

> It should not have been a surprise to some of the biggest REPL sites on the web that their products were about to break

REPL websites are still largely working though, my samples are still working the same, I just don't use the affected APIs which I've avoided for a long time already. If they care deeply about some specific scenario, they should probably be tested. And every failure to catch an error is an opportunity to learn, for all sides involved.

Here's an example of a major bank website with some user visible non-breaking issue I saw recently: https://youtu.be/GFvaRgFf4LU?t=482 . It seems that it's been visible for a while, yet is not fixed. It's actually quite common to see errors unfixed in software as you may know.

No matter what you do, some websites will only be fixed a long time after very obvious warnings are displayed. Some will never be fixed until they actually stops working. Some will just never be updated at all.

Maybe you're one of the people who take their car to the repair shop when the engine light is on, but there are also many others who will just ignore it as the car still drives "fine" (for now at least).

Regarding your suggestion of using Reddit, HN, Twitter, news, it's not always possible or relevant. I've seen a lot of very interesting publications just not getting any traction on those are they're boring in nature or cater to experts mainly. They're also read only by a fraction of users.

Unfortunately, if you're hit by any issue, you shouldn't be only asking what others should do for you, but also what you can do to catch those issues in the future yourself. All sides can maybe do better at broadcasting information about some changes, or voice their opinion better and sooner, but it's not an easy problem with an easy solution.

But do you use Chrome Canary, Dev or Beta for development purposes? Would you have then noticed the change? Do you have continuous testing on the websites you maintain with those versions?

I presume you're only human, so it's almost expected you will skip over a change as you don't think it's relevant or might even take days off work, in which case, it's easy to forget to read it. ChromeStatus is just one of the many signals you should use to filter issues before they reach customers.

There are archives you can sample to measure the impact of a change to some degree. We can use them to have an estimation of how common some patterns are. It's tricky to query so it may not work for advanced use cases or identify cross origin issues.

And it's not possible to reach out directly to those people. We can't just send deprecation notices to random contact emails (if there's any) on websites. We can't just open a "support request" to L1 customer support of websites telling them their site might not work soon. We're not going to send dead-tree mail to addresses listed on websites either.

If you want to support specific browsers, as part of your ongoing maintenance, you should test your site with canary and beta versions of browsers to catch issues before they go live at a minimum. You can also read the relevant mailing lists or blog posts for the major browsers to have an idea of the direction they're taking.

Chrome 91 went stable July 15. But the first beta was April 22. The change was probably in Canary before that as well. Quite a long time to catch issues with the right automation.

Personally, I wouldn't want to have to read the mailing lists and other articles. I would want a dashboard that tells me everything is tested and working fine automatically. And when it doesn't, I know I have many months to fix the issue before it hits stable and find the relevant documentation about the changes that might be causing the issues. Or just open an issue to the browsers, sometimes people are using APIs in very unexpected ways, or you know, a bug sneaked in despite the testing we have in place.

I've removed some feature from the web in Chrome after a long deprecation phase with warnings in devtools, proper announcements in ALL the relevant mailing lists and release notes. Still, many major websites broke as they failed to implement the very simple required changes in their products.

Did they break in Chrome? No, we landed the change at a later date than announced. But Firefox did the same removal and it landed to stable a few weeks before Chrome. They also advertised for the removal extensively and were hit by all the "Major site X and Y are broken" bugs unfortunately. A couple days later, everything was fixed though, when Chrome's side of thing reached stable, no sites were really impacted.

The replacement API had been available for many years before, people used the old non-standard and deprecated way still.

So no, websites owner will not be proactive and fix their products no matter what you do unless they break. We do our best to be upfront with the changes, but both sides have to be willing to communicate for it to happen.

Chrome engineer, working on WebRTC here. Here's my personal opinion:

Safari's WebRTC implementation is not outdated, it's just bindings over the same library that is used and developed by Chrome. At worst, it's lagging a bit by a few months.

What the post highlights is how some features are not available, like some codecs on some platforms. That's unlikely to be a decision from the browser engineers but probably closer to the lawyers who need time to approve a codec or other engineers working on HW acceleration.

Another point is also that while WebRTC was available in most contexts, getUserMedia wasn't, and that's the API used to access cameras and microphones. Without it, WebRTC functionality loses its appeal. I believe that's now fixed and webviews can now use it.

While I don't necessarily approve of those decisions for the users' sake, I still respect their choice to be able to make decisions on their own product and chose when a feature is deemed safe for release in potentially dangerous contexts. I don't know their security model, but from talking with the engineers on many occasions, they are not unreasonable people.

And while Safari is lacking some new WebRTC related APIs released in Chrome, it would be fair to say that they are not all standardized yet at the IETF or W3C level. Other browsers don't necessarily implement them either, and that's fine.

I don't have that much experience migrating codebases from JS to TS, but I do have experience converting codebases from C to C++. The corollary is that C++ is typesafe while C isn't. So you can call a function taking a point to an int with a pointer to a double, and the compiler won't complain (too much).

Word on the street says that C programmers are usually expert engineers that know what they're doing. Yet, I had to deal with those conversion errors all the time. That C code isn't a random CRUD application on a simple website. That can be software embedded in controllers in sensitive equipment, or equipment that will be harder to update. So it's even more important to get it right. And yet...

A monorepo surely makes that kind of change difficult. But when it's in, you know every team has access to it. Not just 2 or 3 teams out of hundreds.

It has many other benefits as well that have been outlined in lots of other posts.

Your company probably has a better budget per computer than the school for the teachers and students.

The problem was that most people compared big inboxes managed in Outlook when brand new emails in GMail. It's certainly easier to search when you have very little data to go through.

Having a standard doesn't mean you're not allowed to innovate and create another one.

SCTP dates from RFC2960, first draft was published in 1999. It had enough time to get traction, and it didn't. Why would anyone build something new with it now, knowing that it doesn't answer some of the issues with the current Internet?

Even WebRTC's DataChannels were introduced at the IETF in 2012, that's 9 years ago (although ironically, the RFC just got published in January...).

3 of those are related to DataChannels in WebRTC, which at this point is baked into the standard and can't be replaced by another protocol. The SCTP in DataChannels is quite limited, that subset is reasonable to implement somehow.

Only the last one is really general purpose and has had a lot of security issues as well.

Fun fact: I do work on one of those implementations and with another one, and it's out of necessity rather than a career choice.

SCTP over DTLS over ICE over UDP is used quite a lot though!

That's how DataChannels in WebRTC were specified a while ago, and it's the only mechanism to do browser to browser communication.

SCTP can also be run over DTLS over ICE over UDP. How many layers is that?!

It doesn't matter if SCTP has good features if no one is willing to implement quality libraries for it. The protocol exists for a while and only one general purpose library exists for it that's widely used. And it's not without a lot of flaws and limitations.

There are good reasons no one wants to invest in it, and I'm sure they did consider it.

Hey, that's not true. People use it... in the telecom industry and everyone using WebRTC's DataChannel (SCTP over DTLS actually).

The protocol is probably mostly fine, but there are no quality library for using it in a general purpose way. Because of that, no one can really use the protocol to its full designed capabilities anyway (and the ossified network nodes don't help either).

I remember stories of the default password being a weak hash of the SSID. And when those are "ISPNAME-4DIGITS", it's not too hard to collect them all.

Sometimes, they can be retrieved from the MAC address as well. So it's just the illusion of security for most.

It really depends on how the game is made. If the game knows what latency you have, it can compensate for it.

You can also automate the upgrade process with good tooling.

Detect a new version? Update your local copy, run your CI, if it passes, you can automatically merge. Or you could ask for someone of your team to review the changes, knowing your tests passed. And if it doesn't, you can warn your team, who can then either fix the build manually (hopefully a small incremental change) or open a bug report to the library.

The point is to do that continuously, so that the deltas are smaller and easier to handle. I do that with some pretty critical libraries at work and it's mostly fine, takes a few minutes usually to approve changes every week. Doing an upgrade after 6 months+? That'd require a long rollout.

And that way, you can't have atomic updates across the repositories and need to synchronize them all the time, great.