A API que os navegadores fingem que não existe

Vou te fazer uma pergunta: qual é a API mais estranha do navegador que você conhece?

Se você desenvolve para web, provavelmente pensou no canPlayType(). Aquele método que retorna "talvez", "provavelmente" ou nada — uma resposta vaga enrolada em probabilística. É confuso, admito.

Mas existe outra API que mostra como a web se esforça para nunca quebrar código antigo: History.pushState().

Três parâmetros, um ignorado

Quando você chama pushState(), passa três parâmetros: estado, título e URL. O objeto de estado faz sentido — permite que seu aplicativo restaure informações quando o usuário volta no histórico. A URL é útil para atualizar a barra de endereço sem recarregar a página.

Porém, aquele parâmetro de título? Completamente ignorado. Todos os principais navegadores descartam ele sem piedade.

A questão é: por que ele continua lá?

A história por trás

Em 2008, quando a History API foi criada, alguém teve a ideia de deixar os navegadores definirem um título personalizado para cada entrada no histórico. Funcionaria assim: seu SPA mostraria "Painel" para o usuário, mas o histórico do navegador armazenaria "Relatório de Análises".

Soava razoável na época. Mas os navegadores perceberam rápido que isso criaria situações complicadas — imagine um usuário favoritando uma entrada e o título não corresponder ao que ele vê nas abas.

Em vez de lidar com essa dor de cabeça, os navegadores simplesmente ignoraram o parâmetro. O problema é que muitos sites já tinham construido seus aplicativos esperando três parâmetros. Remover completamente quebraria sites em produção. Torná-lo opcional causaria confusão com chamadas existentes de pushState(state, url).

Então a especificação fez algo elegante: renomeou o parâmetro para unused e documentou que ele não tem efeito nenhum.

O segredo sujo da web

Isso é o segredo sujo da web: priorizamos compatibilidade com o passado acima de quase tudo. A web vai se dobrar (às vezes literalmente) para garantir que código de 2008 ainda funcione nos navegadores de hoje.

Essa filosofia é exatamente por isso que defendemos sites estáticos e tecnologias web comprovadas na NameOcean. Quando você constrói algo que precisa durar — arquivos de mídia, documentação, landing pages — a estabilidade da tecnologia web não é uma limitação; é um recurso.

O mesmo vale para sua infraestrutura

A mesma coisa se aplica quando você escolhe um registrador de domínio ou provedor de hospedagem. Você quer empresas que entendam o jogo de longo prazo. A web não vai a lugar nenhum, e as tecnologias nas quais você constrói hoje devem funcionar daqui a uma década.

Há uma lição aqui para desenvolvedores e startups: às vezes a decisão "errada" se torna permanente não porque seja correta, mas porque muito depende dela. Isso não é um bug na web — é um recurso que mantém milhões de sites funcionando suavemente.

A próxima vez que encontrar uma API peculiar ou parâmetro descontinuado, lembre-se: alguém, em algum lugar, tomou uma decisão anos atrás, e agora está cravada na fundação da web. Respeite a estranheza. Ela mantém as coisas funcionando.