E aqui estamos nós, em 2016, ano que promete para nós, desenvolvedores web. ES6 (ES2015) veio com sua spec finalizada, flexbox com grande suporte pelos browsers, web components com sua spec cada vez mais redonda, e mais um post comparando o pobre Internet Explorer com outro browser. Antes de virar moda, já vou avisar aqui: ano que vem eu que posto!

Há pouco tempo atrás, surgiu um post com título um tanto quanto sensacionalista: Safari é o novo IE. O post gerou muita discussão (muitas delas bem tendenciosas), mas uma coisa foi boa: nos fez questionar. No fim, o Safari não estava tão fora da curva assim, mas agora a Apple sabe que estamos de olho, que queremos que as coisas andem. E isso é bom!

Infelizmente não vivi muito na época de domínio do Internet Explorer (não conheci o Netscape, me julguem). Sim, tive um Positivo com Internet Explorer, que vivia cheio daquelas barras de ferramentas de terceiros, que pra abrir uma página era bater na URL e ir tomar um café, mas isso foi por pouco mais de dois anos, e nessa época eu só ficava nos joguinhos da Miniclip, não produzia nada mesmo. Portanto, o que vou expor aqui é minha visão de como é a realidade dos navegadores hoje, do ponto de vista de um desenvolvedor.

Os Usuários Escolhem Navegar Pelo Chrome

O primeiro ponto, o mais óbvio, é que os usuários do Chrome escolheram ser usuários do Chrome. Eles tiveram que baixar o navegador manualmente, não contaram com a comodidade de já tê-lo instalado em seu Sistema Operacional, que é o caso do IE e Safari (até o Firefox já vem no Ubuntu 14.04). Claro que o Chrome OS é um desses casos, mas convenhamos que ele não se encaixa como um SO convencional.

Desenvolvimento é Diferente de Produção

Assim como beta é diferente de estável. Um serviço em beta, que era o caso do Inbox e Whatsapp Web, que funciona apenas em um navegador é completamente aceitável. Em casos notórios, como os já citados, a comunidade de desenvolvimento já cai em cima, justamente pra evitar esse esquema anti-cross-browser.

O Chrome é geralmente mais utilizado por desenvolvedores por ser um dos primeiros a implementar as specs, mesmo as que ainda estão em draft. Não é pelo fato de ser o Google Chrome, mas pelo fato dele suportar tal API. Além do mais, desenvolver no browser mais utilizado atualmente é compreensível.

Infelizmente, suportar ou não outros browsers é uma decisão de negócio, e se a escolha é suportar um navegador específico (seja Chrome, Firefox, Edge ou Safari), essa é uma decisão bem ruim. A web é muito maior do que esses quatro podem suportar, sem contar que, suportando apenas um deles, uma grande parcela de seus possíveis usuários não será alcançada. É isso que os "Open Web Standards" buscam cumprir, uma plataforma unificada de desenvolvimento, com padrões e APIs bem documentadas, onde a gente possa desenvolver um único código que atenda qualquer user agent (mas a gente sabe que não é assim tão fácil, né?).

Eu, particularmente, uso o Chrome pela sua simplicidade e suas ferramentas de desenvolvimento. Não consigo usar os devtools do Firefox, já tentei e me perco todo naquilo. Não é por isso que não vou testar meus websites nele, a única diferença é que será com uma frequência menor, ou para testar alguma funcionalidade chave. Quem desenvolve para um browser específico, utilizando detecção de browser ao invés de funcionalidade, está fazendo algo muito errado, que vai gerar retrabalho num futuro próximo.

Uso Inadequado de APIs Específicas do Browser

Pesquisando para esse post, descobri que a API de FileSystem, utilizada em todos os exemplos dados pelo Paulo Higa em seu post (exceto o Inbox), não é um padrão W3C:

In April 2014, it was announced on public-webapps that the Filesystem API spec is not being considered by other browsers. For now, the API is Chrome-specific and it's unlikely to be implemented by other browsers and is no longer being standardized with the W3C. Exploring the FileSystem APIs por Eric Bidelman

Ela virou uma API específica para o Chrome. A verdade é que o navegador é sim uma plataforma (vide Chrome OS) e além dessa, existe toda uma lista de APIs específicas, utilizadas pelas extensões e apps. O que nós, desenvolvedores, podemos fazer quanto a isso? Primeiramente, se a API é específica do browser, então o melhor é nem utilizar. Se for uma funcionalidade muito boa, me baseio nas opções que Nolan Lawson escreveu em seu post: eu escolheria desenvolver as funcionalidades com progressive enhancement. Upload de pastas é possível no Chrome mas não no Edge? Então faça um upload em lote no Edge então. Já se a escolha deve ser entre suportar ou não tal feature sem nenhum fallback, então que fiquemos com o upload em lote que funciona em todos os browsers.

A Microsoft agiu errado ao implementar o upload de pastas no OneDrive apenas no Chrome, que suporta isso? Absolutamente não! Se eles têm o tempo e recursos necessários para implementar tanto o upload de pastas onde é suportado e o upload em lote onde não é, que o faça, melhor para os usuários de ambos os browsers. Além disso, não é porque o Chrome suporta essa funcionalidade não endorsada pelo W3C que eles devem implementar também.

Conclusão: Habemus Bom Senso

Não adianta levantar um problema sem sugerir nenhuma solução. Tudo bem que isso está fora de nosso controle—não somos a Google—mas podemos fazer algo quanto a isso. Como desenvolvedores, podemos simplesmente não endorsar essas tecnologias não utilizando-as. Como usuários, podemos fazer como fizemos com o Whatsapp Web, mostrando aos desenvolvedores que isso é feio (isso mesmo, xingar muito no Twitter). Se seu website funciona apenas no Google Chrome, a culpa é sua, não dele.