No Google I/O deste ano, Ben Galbraith e Malte Ubl apresentaram um gráfico durante a palestra de abertura que mostrava como a Web está ficando mais interoperável:

Essa tendência é muito importante para a equipe do Chrome: os desenvolvedores Web devem ser capazes de criar para a plataforma Web e não para quatro plataformas diferentes (embora com alguma sobreposição). O gráfico foi criado com os dados do nosso Web API Confluence Dashboard. Esse projeto, originalmente desenvolvido para engenheiros de browser, oferece ideias e informações sobre a interoperabilidade na Web monitorando as APIs JavaScript visíveis na página em diversas versões dos quatro maiores mecanismos de navegação. Veja este exemplo:
Legenda: O número de APIs específicas de navegador sobe quando os navegadores são os primeiros a lançar uma nova API e cai quando (i) um segundo navegador implementa uma nova API, ou (ii) uma API que não conseguiu alcançar um consenso é removida pelo navegador que a implementou.
Esse gráfico mostra o número de APIs lançadas por apenas um dos quatro navegadores ao longo do tempo. Interagindo com o gráfico no painel, você consegue abrir a lista de APIs correspondente a cada contagem:
Essas informações ajudam os navegadores a priorizar as tarefas que aumentarão a interoperabilidade da Web, seja removendo APIs antigas específicas de navegador ou trabalhando com outros fornecedores para implementar APIs que ainda não contam com um suporte amplo.

Como as APIs são coletadas

Para contar APIs na Web, primeiro tivemos que definir o que é considerado uma "API da Web". A Web é repleta de recursos úteis, e alguns deles são difíceis de definir e ainda mais difíceis de detectar. Para essa análise, examinamos as APIs JavaScript que ficam visíveis para o desenvolvedor quando a página carrega pela primeira vez. Isso exclui diversas classes de recursos, como propriedades CSS, atributos HTML e APIs indisponíveis no carregamento da página (por exemplo, APIs exibidas só com interação do usuário com a API ou disponíveis apenas em alguns tipos de worker). Mesmo assim, conseguimos ter uma visão geral dos recursos programáveis dos navegadores.
Nosso algoritmo de detecção de API JavaScript inspeciona o gráfico do objeto JavaScript exposto no objeto window global. Confira o link para ver detalhes sobre como conseguimos extrair APIs dos protótipos JavaScript. Com a ajuda das mais de 1.000 configurações de navegador/sistema operacional do BrowserStack, conseguimos coletar dados de API para versões de navegador datadas até 2012.
Como determinar se a Web está saudável
Examine a página de métricas do painel. Você verá alguns gráficos que geramos sobre o cenário da Web. Essas métricas, e as APIs que elas representam, oferecem aos implementadores da plataforma Web informações sobre que APIs estão fragmentando a Web. As APIs que fragmentam a Web são:
  1. Lançadas por praticamente todos os navegadores, mas não todos;
  2. Removidas por um navegador, mas não pelos outros; ou
  3. Lançadas por um navegador, mas não pelos outros.
Por exemplo, nossos dados mostram que o Safari é o único grande navegador que não oferece CSSStyleDeclaration#backfaceVisibility, o Chrome removeu várias APIs SVGSVGElement que ainda são oferecidas por todos os grandes navegadores e o Edge é o único que oferece várias APIs BhxBrowser.

Como consultar os dados brutos por conta própria

O objetivo do painel não é substituir ferramentas como o MDN Docs ou o caniuse.com, mas sim mostrar as tendências que ajudam os navegadores a continuar a promover a interoperabilidade da Web. Sabendo disso, a página de catálogo do painel pode dar aos desenvolvedores outro mecanismo para confirmar informações de interoperabilidade de fontes administradas manualmente. Teste a caixa de pesquisa acima do catálogo de APIs. Ela permite consultas básicas estruturadas, como in:firefox60 ou notin:chrome66 para ver as APIs do Firefox 60 ou as que não estão no Chrome 66, ou RTCPeerConnection count:2 para ver as APIs relacionadas ao RTCPeerConnection oferecidas por exatamente dois dos navegadores que estão sendo visualizados no momento. Clicando no ícone de elipse vertical, você consegue adicionar ou remover dezenas de versões de navegador da tabela. A barra de URL sempre tem um link que retorna você à consulta atual.

Validação de tabelas de compatibilidade de navegador da MDN

Já começamos a usar os dados para ajudar escritores técnicos a checar programaticamente suas contribuições no excelente banco de dados de compatibilidade entre navegadores da MDN. Experimente:
# Clone o banco de dados de compatibilidade entre navegadores da MDN
git clone https://github.com/mdn/browser-compat-data.git
cd browser-compat-data
# Instale as dependências
npm install
# Carregue os dados de confluência no ServiceWorker
npm run confluence -- --interfaces=ServiceWorker
# Veja as diferenças aplicadas à sua árvore de trabalho
git diff
# Leia a lista completa de parâmetros que você pode usar em "npm run confluence"
npm run confluence -- --help

Conclusão

Esperamos que os engenheiros de navegador e os desenvolvedores Web consigam se beneficiar com o painel. Experimente e envie sua opinião no projeto do GitHub que hospeda o código.

 Postado por Mark Dittmer, engenheiro de software que trabalha na infraestrutura do ecossistema da Web