Tecnologia / Artigos / A Web /
Meu problema com a Web

Cléber

![foggy-forest-black-and-white.jpg](/files/172) *Photo by [Paolo Chiabrando](https://unsplash.com/@chiabra) on [Unsplash](https://unsplash.com/s/photos/mistery)* --- Ainda pretendo fazer a devida introdução a, no mínimo, "que diabos é, afinal, a Web", já que percebo que muitas pessoas não sabem dizer exatamente a diferença entre "a internet" e "a Web" (ou mesmo que "Web" se escreve com letra maiúscula, ao contrário de "internet"). Mas por agora basta dizer que a pilha que começa no HTTP e termina num navegador renderizando HTML com CSS e executando Javascript é, numa visão bem geral, uma definição boa o bastante para se entender este artigo. Já faz alguns anos que tenho demonstrado aqui e ali minha insatisfação com o que a Web representa. Certamente eu entendia que algo estava muito errado, mas foi apenas mais recentemente que o conjunto de noções esparsas começou a criar conexões em minha mente e uma ideia razoavelmente coesa começou a se formar a respeito do que, afinal, está errado. Por outro lado, a ideia de como podemos consertar as coisas, admito, ainda está em processo de formação. O problema da Web, já digo sem delongas, é que **a Web saiu das mãos do programador comum**. E pior: isso aconteceu há décadas, mas muito pouca gente parece ter percebido. Legiões de legiões de desenvolvedores, hoje, desenvolvem software **para** a Web, mas são pouquíssimos que realmente programam **a** Web. Exércitos incontáveis de usuários-de-algumas-ferramentas foram formados, enganados pensando que estariam usando uma "plataforma" "aberta", quando não há, realmente, muita diferença entre ser dependente de um navegador para entregar seu software e ser dependente de uma IDE. Hoje é a Web quem domina os desenvolvedores. Reflita a respeito desse fato: **a Microsoft tentou lançar um novo navegador e desistiu**. A Web é um monstro tão absurdo que nem mesmo uma gigante tecnológica como a Microsoft consegue domá-lo. A coisa absolutamente fugiu do nosso controle (ou seja: do controle de nós, os desenvolvedores de software), inclusive a ponto de os navegadores sequer conformarem-se a qualquer tipo de especificação, mas aderir ao que chamam de *living standards*, o que torna o desafio de implementar um novo ainda mais complicado. Acha que estou exagerando? Bem, o navegador Web **Firefox** tem cerca de **10 milhões de linhas de código**. E é extremamente interessante fazer a comparação com o kernel de sistema operacional **Linux**, que passou das **15 milhões**, porque alguém há de achar que isso faz com que o tamanho do navegador seja "aceitável", mas é importante lembrar que as 15 milhões de linhas do Linux **não são** executadas simultâneamente. Veja: na árvore do kernel tem suporte para **todo tipo de harware**, basicamente. Conta-se todos os módulos de todos os protocolos, **todos** que são suportados, e em nossos computadores normalmente rodamos uma fração **mínima** disso. É muito possível que o kernel que roda "laptops afora" tenha **bem menos** que 10 milhões de linhas de código, enquanto o Firefox, pelo contrário, tem se livrado de protocolos antigos (eu lembro quando caiu o suporte a Gopher) e adotado novos que, no geral, absolutamente **estarão** rodando constantemente enquanto seus usuários navegam Web afora com ele. **Um dia a Web foi um protocolo**. Hoje ela é uma pilha de software com opções limitadíssimas de escolha. Lembremos dos tais *living standards*: **a Web que temos hoje é puramente implementação**. E por ser pura implementação, ninguém mais conseguirá implementar um novo navegador (e, por favor entenda: envelopar WebKit numa carcaça nova **não é** o que quero dizer com "criar um novo navegador"). "*Mas os navegadores são open source*", alguém dirá. "*Nada impede que você altere o que bem entender!*". Nada mesmo? Comecemos pelo item "monstruosidade". Por qual das 10 milhões de linhas de código eu deveria começar? Consegue imaginar que, começando da `int main` deve haver pelo menos uns mil caminhos possíveis para seguir? Ademais, atacando alguns pontos fundamentais de um navegador moderno, como tentar desabilitar qualquer tipo de "banco de dados" que possa ser usado pelos Websites, chega-se no quê? Provavelmente em um "navegador manco". E navegadores mancos já temos em abundância -- se puséssemos todos numa mesma sala, a propósito, o resultado será bem parecido com a cena de Alien 4 em que Ripley encontra seus *clones falhados*. Certos problemas, inclusive, são fundamentais a ponto de serem praticamente impossíveis de resolver. Requisições de recursos inter-domínios, por exemplo. Isso não deveria existir! "*Mas então teria muito desperdício*". Exato. A questão não é sobre como solucionar o problema. A questão é sobre o problema em si. Nós não deveríamos **precisar** requisitar recursos entre domínios! Nesses últimos dias implementei, veja você, um cliente de **Gopher**. A soma do tempo de fazer tudo, inclusive a GUI, nas horas vagas durante a semana, provavelmente seria o equivalente a dois dias de trabalho ou menos. E não é um cliente "porquinho". Meu cliente Gopher é tão bom de usar que agora é meu cliente favorito. De longe. Calcule isso: se alguém me contratasse para criar um cliente de Gopher, gastaria **menos de R$ 2.000,00**. É claro que é um protocolo simples, **e é exatamente essa a questão**. A discussão toda deu-se a respeito dos navegadores? Ora, podemos também falar sobre os próprios protocolos: **HTML é XML**. Você faz ideia de quão complicado é implementar um renderizador que identifique apenas `h1` quando esse nó pode estar enterrado em tantos níveis de insanidade XMLística quanto o autor da página queira? "*Mas tudo bem, isso dá liberdade para o autor*", você pode estar pensando. Mas o que é o HTML, afinal? Nasceu para fazer o quê? Não era para publicar conteúdos científicos? Me pergunto se era, tão logo a Web nasceu, realmente necessário esse nível todo de complexidade para meramente definir-se um simples cabeçalho. "*Mas é só XML. Temos bibliotecas para cuidar disso*". Okay. Por falar em bibliotecas (ignorando minha extrema irritação por ouvir um "argumento" que começa com *é só*), você já viu quantas linhas de código tem a `libxml2`? Não? Pois eu te digo: ``` ─────────────────────────────────────────────────────────────────────────────── Language Files Lines Blanks Comments Code Complexity ─────────────────────────────────────────────────────────────────────────────── C 119 283569 24768 46914 211887 55332 C Header 73 34879 3213 4651 27015 487 XML 901 127922 2446 2459 123017 0 XML Schema 157 6023 540 0 5483 0 ... ─────────────────────────────────────────────────────────────────────────────── Total 1682 555829 34883 55809 465137 57207 ─────────────────────────────────────────────────────────────────────────────── ``` **Só de C tem mais de 300 mil**. São 70MB de repositório de código. HTTP, admito, é em sua essência razoavelmente simples. **Exceto quando não é**. Se tudo girasse em torno do formato básico de requisições, tudo bem. Mas há a pletora de *headers*. E *query params*. E *Basic auth* (que deveria descansar em paz, mas tem empresa até hoje **incentivando** seu uso em APIs muito recentes). E *cookies*. Não é curioso que o funcionamento essencial de boa parte de nossos sistemas de autenticação **dependa basicamente da boa-vontade do cliente em implementar *cookies* corretamente**? Ah, e temos também os *WebSockets*, agora. Ou HTTP/2, você escolhe. E não bastasse as escolhas questionáveis do Berners-Lee, ainda tem os malucos que vão além e tentam empurrar HATEOAS para todo mundo. E código de terceiros rodando na sua máquina sem você ter sequer a chance de saber antecipadamente que isso acontecerá. A ponto de ser **esperado** que código de terceiros não-verificado consuma os recursos que você detém. Código Javascript. Nem comento. E, como se não pudesse ficar pior, a Web não somente tornou-se implementação como também é uma implementação **desenhada por comitê**. Sabemos bem quão ruim isso pode ser. Entre os "revoltados", como eu, é comum encontrar-se uma história comum: "*comecei a desenvolver para Web, mas a minha impressão foi de que é uma enorme bagunça*". Muitos ainda o fazem a contragosto, apenas para ganhar o pão de cada dia. **Deve haver um jeito melhor.** --- O resumo de tudo, no fim das contas, é o seguinte: 1. A Web não é protocolo, mas implementação. 2. A implementação é gigantesca. 3. O desenho é por comitê. 4. Os protocolos essenciais já nasceram com problemas. 5. Javascript. Talvez você a essas alturas esteja pensando: "*bom, não é um pensamento assim tão coeso quanto eu esperava*". Talvez seja porque os problemas são diversos e em diversos níveis afetando diversos atores ao mesmo tempo. Sobre possiveis soluções: eu mesmo cheguei a criar um pequeno protocolo, mas hoje percebo os erros cruciais que cometi com ele. Protocolos alternativos, como o *Gemini* tem surgido, mas ainda acho que sofrem de mal semelhante, a respeito do que pretendo comentar nos próximos capítulos dessa série. Parabéns por aguentar ler até aqui. Até o próximo artigo!

Curti

30 visitantes curtiram esse Item.

Anterior: Artigos / XFCE: quase como o Lada | Próximo: Artigos / Diretrizes de Desenvolvimento