Eu realmente gosto da vinculação de dados bidirecional declarativa que é ativada por bibliotecas como Knockout, Angular e Ember. Não é apenas a maneira bacana como as coisas são atualizadas automaticamente, ou como ela promove a separação da lógica do comportamento da lógica da visão. O que mais gosto nele não é como ele cria uma maneira totalmente nova de fazer desenvolvimento web, mas como me permite voltar a como costumava fazer as coisas há mais de uma década.
Comecei no desenvolvimento da web nos dias agitados da Web 1.0. No tempo em que as tags <font> eram como você estilizava o texto, e os atributos onclick eram a maneira mais confiável de anexar manipuladores de eventos. Então, CSS e DOM Level2 surgiram e, de repente, a marcação de apresentação e os manipuladores de eventos embutidos se tornaram tabu. Nosso HTML tinha que ser semântico! Os usuários leitores de tela do mundo todo chorariam se usássemos tabelas para layouts. As pessoas seguiam esse dogma com tanto fervor que me lembro de ter visto um desenvolvedor da web com uma tatuagem de três documentos representando a sagrada trindade de Estrutura, Apresentação e Comportamento estampada em suas costas.
Claro que havia razão para essa loucura. Naquela época, os sites eram compostos de centenas de arquivos html estáticos separados. As folhas de estilo CSS externas nos permitiram fazer uma alteração em um único arquivo e afetar todas as páginas do nosso site. Da mesma forma, os arquivos Javascript externos que usavam anexos de eventos discretos permitem que várias páginas compartilhem comportamentos comuns, entre outros benefícios.
No entanto, esse progresso teve um custo. Olhando para um documento HTML, você não poderia dizer o que poderia acontecer se um elemento fosse clicado. Para alterar a forma como um elemento apareceu, você tinha que procurar o seletor CSS que fornecia as regras de estilo para ele em Deus sabe qual arquivo. Alguns IDEs podiam fazer referência cruzada a esses arquivos para você, mas até recentemente mesmo os navegadores não podiam realmente dizer quais manipuladores de eventos foram registrados em qualquer elemento determinado até que o evento fosse disparado. Nossas preocupações eram tão distintas que, para mantê-las, era necessário ter um conhecimento íntimo de três bases de código distintas.
Então as coisas começaram a mudar novamente. Ajax e HTML5 deram ao Javascript do lado do cliente o poder de fazer lógicas cada vez mais complicadas, enquanto o REST tornou os servidores de backend cada vez mais simples de se comunicar. Nós não os chamamos mais de “sites”, nós os chamamos de “aplicativos da web”. Eles são arquivos únicos, e nós minimizamos nosso código e combinamos tudo no mínimo de arquivos possível para economizar um tempo precioso de carregamento.
Comecei a questionar a lógica de colocar CSS arbitrariamente em folhas de estilo externas desde que comecei a usar modelos para construir meus sites. Se eu quisesse mudar o estilo de todo o site, só precisava editar um parcial. Não consegui ver nenhuma razão válida para não usar um atributo de estilo, a menos que o estilo precisasse ser aplicado a vários elementos na página de uma vez, ou se eu precisasse estilizar uma pseudo classe. Mas eu fiz isso de qualquer maneira pelos meus colegas de trabalho.
Mas quando comecei a usar ligações declarativas, era como um copo de chá gelado em um dia quente para ver o Javascript de volta em linha com os elementos nos quais estava atuando. Não é estritamente correto referir-se às associações no Knockout (“diretivas”, como são estranhamente chamadas no Angular) como Javascript. Eles são mais como “regras de comportamento”, e ter o comportamento de minha interface de usuário explicitamente declarado no contexto em que esse comportamento ocorre é uma mudança de jogo!