[Orphis]

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.

[danShumway]

> 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.

To be clear, we're talking about Chris Coyier right now. The Chrome team doesn't have any way to contact him? The team had to know that REPLs would be impacted by this, right?

You can blame people for not having the right automation and dev tools lined up and for not reading the right blogs, but it still seems to me like this is covering up the fact that the Chrome team does not view it as their job to reach out to web developers or put serious effort into marketing changes. If Chris didn't know about these changes, then I seriously doubt that the Chrome team was getting any kind of a representative sample of developer feedback during this process.

> 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.

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? It just feels so ridiculously out of touch with the reality of where web developers congregate and how news gets disseminated. I know it's a difficult problem, but the responsibility of Chrome is to work with the web community as it exists, not as the professional fully-automated community they'd like it to be.

Chrome couldn't send out some Twitter DMs? Chrome team couldn't post a heads up to HN? Any effort to post anything to the popular web dev communities on Reddit? Did the team reach out to any any popular bloggers or members of the community to ask them to spread the word? When the Chrome team is making changes to the dominant browser for what is (imo) the most important platform on the planet, it just is not enough to say "we put it in the mailing list, and you weren't testing well enough." The expectations for the Chrome team here are higher, because Chrome matters more than other products.

Yes, developers need to meet Chrome halfway on communication, but frankly, Chrome is not coming halfway right now to meet us. It should not have been a surprise to some of the biggest REPL sites on the web that their products were about to break. I don't know what to say about this, I'm not trying to be mean, but if the Chrome team's perspective is that developer communication isn't at least partially their problem to solve, and they think that if they roll out a feature and nobody knows about it that developers are the problem, then those people shouldn't be in charge of the dominant web browser.

[Orphis]

> 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.

[joepie91_]

> 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.

This is so, so illustrative of the problem with the Chrome team's attitude - I'm not sure you could imply "the web is for businesses, amateurs should get out and just consume" any more heavily if you tried.

[danShumway]

> 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.

Wait, but... no. Scientists wouldn't have glanced over it and not understood the ramifications, and they didn't. Global warming doesn't seem like a great example to use here both because people have put a ton of effort into evangelizing it, and because it wasn't glossed over or ignored, many people took it seriously and worked to try and sound alarms. If only the Chrome team was putting even a fraction of the effort into evangelizing its changes as environmental advocates put into evangelizing global warming -- I would have no complaints in that world!

> but I know you can't expect random people to receive random messages from random sources

I have never personally spoken to Chris, but I can still promise you right now that he would not be offended or angry about being contacted for help evangelizing a breaking change. The Chrome team is not a random source, it should have contacts in the community. It should be a part of the community. If the Chrome team thinks of itself as outside of the community, as a random source that doesn't know anyone, that they would be intruding if it jumped into any conversations -- then that's a real big problem.

You want to meet us halfway on communication? Come meet us! Form some developer connections, get to know us. We're not all isolationists, we're in this together. We care about what the Chrome team has to say, we want the Chrome team to interact with us.

> First it doesn't scale

So, the alternative is to do no outreach at all? I don't get this.

> second it would be preferential treatment which doesn't seem to me in line with the healthy platform the web should be.

This is also such an odd take to me. The Chrome team should reach out to prominent members of the Javascript community that will be affected by breaking changes because those people will make it more likely that the news gets widely disseminated. Healthy communities talk amongst themselves, they communicate. If you went to developer advocates/bloggers like Coyier or Simmons who are deeply entrenched in these communities and asked for help spreading news about a change, they would help.

How much trouble would have been averted with Web Audio if anyone on the Chrome web team had thought to talk to people like Bennett and involve them in the actual decision making process and feature design? Nobody would have complained, game devs would have helped spread the word and warned the team about potential issues. We all would have been grateful!

I hope this idea is not representative of the overall Chrome team's opinions. I don't think anyone in the Javascript developer community thinks that "fairness" should mean that all developers are equally in the dark about every change.

> 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.

I would again point out that Google itself is not meeting your standards for testing upcoming browser features (https://news.ycombinator.com/item?id=28056738), and I still think it's tone-deaf to blame normal web developers for not following a process that nobody at all seems to have mastered. I don't expect Google to be perfect, but normal developers will always be less perfect than Google. The solution your proposing really isn't feasible for most companies.

But ignore the professional sites for a second. This is also just really troubling to hear as someone who cares about the web as a medium, not just as a business platform. The web is admittedly a moving platform, breaking changes will happen. That has always been the case. But we have also always emphasized that breaking changes are dangerous.

People die or they move on in life, and their websites stay up. Not every site can be migrated or updated, and when old sites break, that's a bad thing that we feel bad about. High school kids make games and weird offshoot communities put up forums in their basements. Nontechnical people build on the web to solve their problems because the web is accessible, which is good! We don't want a web that requires professional attention. It's not a purely professional platform, the professionals are in some ways the minority of the content that really matters to the web as a revolutionary, democratizing platform for human connection and innovation.

This has always been a core principle online: the tension between the need for the web to evolve vs the very serious charge that the web is for ordinary people and we don't break their stuff. Google itself has been a proponent of that view for so long. To ignore that tension or act like the real answer is to require developers to constantly have polished build/testing pipelines -- it's a really limited view of what the web is and what kinds of things get built on it, and it's kind of disappointing to hear it from someone on the Chrome team.

----

In general, I still don't understand this aversion to thinking of the web as a community or thinking of the web standards process as something that communities should be involved in. That's not meeting developers halfway on communication.

I've seen some takes and talked to people on the Chrome team before who have caught me by surprise, but I've never seen outright fatalism about the very idea of developers and browser makers having a close, collaborative relationship.

[svieira]

Testing base, stable (from my perspective) infrastructure? Should I have tests that validate that JPGs still render? How about when used as a CSS background image? Does Chrome test the register reads assembly code produced by the C++ compiler in case there's a breaking change that gets missed?

[danShumway]

I don't mean to hammer this point too hard, but when Chrome released click-to-play breaking changes for web audio, they broke alarms/timers on Google search.

So the "you'd catch all these changes if you were testing" excuse honestly kind of rubs me the wrong way, because as far as I can tell Google itself has trouble meeting that standard for even its biggest products.

[Orphis]

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.

[danShumway]

> It's not about putting the blame on specific individual or teams for their insufficient communication or testing.

We don't need to put the blame on anyone, but to your point on learning from bugs and making sure they don't happen in the future, how can that happen if we're fatalistic about why those bugs were caused?

I don't know what the Chrome team is doing differently now to prevent another situation like web audio from happening, because there was never any followup about process changes. The only thing that we were ever told during the web audio failure was that we needed to trust the Chrome team, and that they cared. But that never turned into anything tangible or visible. And X years later and X broken feature launches later, we're still having the same conversation.

If avoiding blame means we can't talk about why something went wrong, then that's a broken process. You're telling me that reaching out to developers is futile, and unless we pay a ton of attention to the mailing lists we're going to miss stuff, and that testing is the only thing that can save us. That's a regression from what I heard from Chrome devs during the web audio debacle. The team seems to have gotten more insular, not less.

We don't need to assign blame, but it would be good to actually learn from these situations. Nothing is changing, the dysfunctional communication between the Chrome dev team and developers is still just as bad today as it has ever been. Is the Chrome team going to do anything at all to help make the situation better?

[lstamour]

> 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.

What about folks who've registered for either origin trials or Google Search Console? Or Google Analytics?

That said, I'd love it if telemetry APIs were baked into the web, perhaps OpenTelemetry API support? Then website owners could set up their own error reporting OTLP endpoints or services to receive sampled deprecation alerts in a standard way, rather than assuming everybody can read the developer console in an end-user's browser (especially when it's hidden most of the time...)

Bonus points if we can ignore errors caused by extensions, or have extra feedback as to which extensions might be causing problems. Double bonus points if there's a UI so end users can choose whether to share this data or not, or to cache and sync the data so it only gets shared when on wifi or idle, in an extremely compressed way, and to provide a settings screen where you can browse what telemetry or errors are shared from/to websites in your history.

[cxr]

> If you want to support specific browsers

This is a pretty arrogant position. If this is your perspective, please go work on Android team or something with a traditional SDK churn cycle. The Web is special.