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