Complexidade ruim: uma entrevista com o criador do HTMX, Carson Gross

Carson Gross é o criador do HTMX e do Hyperscript, a mente por trás do The Grug Brained Developer, professor de engenharia de software na Montana State University e coautor de Hypermedia Systems.

Foi um prazer conversar com Carson sobre o ímpeto por trás de projetos como HTMX e Hyperscript, as falhas do REST, por que o JavaScript veio para ficar e muito mais.

Tyson: É difícil escolher por onde começar aqui, então vou escolher o Grug Brained Developer. Eu meio que sinto que poderia simplesmente encaminhar todos para todas as questões relacionadas à programação.

Bruto: Ha, eu agradeço isso. Acho que vale a pena ler para a maioria dos desenvolvedores. Eu meio que direcionei isso para desenvolvedores mais jovens, no entanto. Certamente não é perfeito – difícil de ser quando você usa uma voz de homem das cavernas e tenta ser engraçado – mas acho que a maioria dos conselhos é sólida.

Tyson: É verdade que a maior parte dos problemas de codificação em que me meti foi principalmente resultado de pensar que era inteligente.

Bruto: Sim, acho que todo mundo que já programa há algum tempo já passou por aquele ponto em que você percebe que se aprofundou demais e não consegue mais manter o sistema na cabeça. Não sei se é sempre pensar que você é muito inteligente ou simplesmente não reconhecer quando as coisas começam a ficar muito complicadas. Além disso, a dinâmica social nos empregos tecnológicos pune as pessoas que dizem coisas como: “Uh, isto é muito complicado para mim”.

Tyson: Isso é verdade sobre a atmosfera em torno de admitir que é muito complicado. Certa vez, conversei com um amigo “JavaScript é tão flexível que você pode codificar qualquer coisa”, e ele respondeu: “Haha, isso é conversa perigosa”. Ele estava certo.

Você tem alguma opinião sobre JavaScript como linguagem?

Bruto: Acho que JavaScript é uma boa linguagem de script. Não é uma ótima linguagem de uso geral, na minha opinião. De uma forma um tanto bizarra, parece C++ para mim: ele tem muitos recursos e maneiras de fazer as coisas agora. Por outro lado, o JavaScript tem uma característica inacreditável: está lá, no navegador. E isso a tornará a principal linguagem de script para a web no futuro próximo, na minha opinião.

Tyson: Estou bastante impressionado com o Hyperscript, mas tenho a sensação de que é uma atividade secundária divertida para você. Você poderia nos contar sobre a experiência técnica de implementação do analisador e assim por diante?

Bruto: Claro. Hyperscript é uma linguagem de script que “competiu” com JavaScript como uma opção para scripts front-end. Ele é baseado em HyperTalk, a linguagem de script do HyperCard, e possui recursos que, na minha opinião, proporcionam uma melhor experiência de criação quando você está simplesmente tentando criar scripts em uma página da web. Por exemplo, o tempo de execução do Hyperscript resolve automaticamente as promessas que encontra, para que os criadores de scripts não precisem lidar com elas. Tem uma sintaxe natural, semelhante à do inglês, que algumas pessoas adoram e muitas pessoas odeiam. É definitivamente um projeto apaixonante meu, mas espero levá-lo para 1.0 este ano, após o lançamento do HTMX 2.

No que diz respeito à sua implementação, sim, ele é implementado em JavaScript como um lexer, analisador e tempo de execução baseado em avaliação. Fiquei surpreso ao ver que o tempo de execução do JavaScript é rápido o suficiente para me permitir escapar impune, mas é. Eu não tentaria implementar um minerador Bitcoin em Hyperscript, mas é rápido o suficiente para scripts DOM leves. O analisador e o tempo de execução do Hyperscript estão no limite da complexidade que eu estaria disposto a assumir com o JavaScript.

Tyson: HTML é outra codificação impressionante. Minha introdução ao HTMX foi um dos artigos mais lidos no InfoWorld no ano passado, o que mostra que há muito interesse nele. Este projeto também parece mais sério, na medida em que procura restaurar pelo menos a possibilidade de uma verdadeira arquitetura REST.

Bruto: Sim, foi um ano louco para o HTMX. Para leitores que ainda não ouviram falar, HTMX é uma biblioteca JavaScript que escrevi que permite adicionar atributos, de espírito muito semelhante ao href e action atributos de links e formulários em HTML padrão. Usando esses atributos, você pode acionar solicitações AJAX e, em seguida, substituir partes do DOM pelo HTML com o qual o servidor responde.

Tyson: eu diria que o HTMX estende o vocabulário do bom e velho HTML para cobrir alguns casos de uso modernos, em particular, AJAX. Essa é uma descrição justa?

Bruto: Sim, essa é uma boa maneira de explicar. Às vezes digo que o HTMX “completa o HTML como uma hipermídia”, pois permite que qualquer elemento da página emita uma solicitação HTTP em resposta a um elemento e, em seguida, coloque essa resposta em qualquer lugar do DOM.

Isso provavelmente parece muito simples, e é, mas com apenas uma pequena generalização de HTML você desbloqueia muitos padrões de UX que tradicionalmente eram reservados para JavaScript. Os exemplos incluem rolagem infinita, seções de carregamento lento de uma página e validação do lado do servidor conforme você digita.

Tyson: Devo dizer que pensei que sabia muito bem o que REST significava, mas estive errado por muito tempo. Você aborda como isso aconteceu em seu artigo, Como REST passou a significar o oposto de REST?

Você se importaria de destilar para os leitores a diferença entre REST conforme pretendido e REST conforme é comumente implementado?

Bruto: *risos* Bem, não estamos mudando a forma como a indústria usa o termo REST. Hoje, esse termo significa “APIs JSON sobre HTTP” e é isso que provavelmente significará para o resto de nossas carreiras.

No entanto, não era isso que REST significava originalmente. Em vez disso, REST era uma descrição de como a World Wide Web funcionava (sua arquitetura de rede) antes da existência das APIs JSON; apenas links e formulários que geram interações por meio de um navegador. O termo DESCANSAR veio de uma famosa dissertação de Roy Fielding, e ele definiu uma série de restrições às quais um sistema RESTful precisa estar em conformidade.

Hoje, a maioria das APIs JSON chamadas “RESTful” não atendem a essas restrições. Ainda mais hilário, um site estático simples com algumas páginas HTML vinculadas entre si faz satisfazer todas essas restrições. Portanto, alguém que cria um site estático simples é, em algum nível, um engenheiro “REST” melhor do que pessoas com títulos sofisticados de engenheiro de API JSON “RESTful” em seus currículos.

A linguagem não vai mudar, mas acho que vale a pena entender o significado original do termo e, em particular, o que é chamado de interface uniforme restrição do REST para realmente entender por que a web é tão flexível.

Tyson: Não tenho aulas de programação desde o início do milênio. Você ainda usa livros? Estou brincando. (Eu penso.)

Como é ser professor de programação? Posso pegar o CSCI 468 de você?

Bruto: Ha! Bem, se você quiser fazer 468, que é a aula de compiladores que eu ensino, você pode simplesmente ler Crafting Interpreters, de Bob Noystrom, e obter cerca de 50% dele. Nosso alvo é a JVM com bytecode no back-end e, para ser honesto, isso não é tão interessante, a menos que você seja um grande especialista em Java.

Eu gosto de ensinar. Definitivamente, há desvantagens: o salário é uma droga e há burocracia para lidar. Mas há muitas vantagens e gosto de levar os alunos ao ponto onde eles sentem que podem programar por conta própria.

Tyson: Sim, definitivamente sou um cara de Java.

Então, isso está voltando um pouco ao tópico REST, mas de uma perspectiva mais elevada. Você é coautor de Hypermedia Systems, que defende que a forma como a web é projetada fornece uma arquitetura de aplicação sobre a qual podemos construir, se olharmos corretamente.

Bruto: Definitivamente, e o HTMX tenta desenvolver essa arquitetura de rede aprimorando o HTML como hipermídia, em vez de substituir a arquitetura original por uma nova, ou seja, APIs de dados JSON de formato fixo. No livro, tento delinear a natureza sistêmica do funcionamento adequado da hipermídia. Por exemplo, por muito tempo, não percebi o quão importante era o cliente hipermídia (por exemplo, navegadores) para que a interface uniforme funcionasse corretamente. Você realmente precisa ter um sistema completo – hipermídia como HTML, um protocolo de rede como HTTP, servidores hipermídia e clientes hipermídia – para fazer tudo funcionar conforme planejado.

Tyson: Para encerrar, gostaria de resumir tudo o que é importante em alguns comentários curtos e divertidos, mas você já fez isso. Tento encontrar coisas das quais discordo na filosofia do grug, mas não consigo. Complexidade de expressão, fechamentos, dizer não… grug tem bons conselhos para todos esses tópicos.

Mas estou curioso para saber o que Grug sente sobre o padrão de visitantes. Já usei e achei que deu certo. No final, o projeto não foi lançado, mas o código era sólido. Diga-me o que há de errado com o padrão de visitantes.

Bruto: Sim, não sou 100% contra o padrão de visitantes, apesar do que diz o ensaio do grugbrain. (Em geral, não sou 100% a favor ou contra nada no desenvolvimento de software.) No entanto, muitas vezes penso que é melhor codificar operações diretamente em uma árvore, em vez de ter outra coisa secundária que execute operações na árvore. Às vezes isso mistura um pouco as preocupações, mas não me importo com isso neste caso.

Por exemplo, no Hyperscript, os elementos da árvore de análise possuem os métodos eval definidos e são definidos diretamente no local em que são analisados. Isso mistura preocupações, mas acho que acrescenta clareza ao programa, porque quando você quiser entender como, por exemplo, funciona o comando “wait”, você pode ir a um lugar e ver como ele é analisado e avaliado. Acho isso muito útil.

Tyson: Por que sabemos que a complexidade é ruim para nós, mas somos atraídos por ela mesmo assim?

Bruto: Bem, mais uma vez, acho que há pressões da indústria em jogo aqui. O software é uma indústria brutal e parecer pouco inteligente pode prejudicar gravemente a sua carreira. Isso significa que todos nós sentimos pressão para demonstrar que somos inteligentes e também para não admitir que o código de outra pessoa é confuso ou parece muito complicado para nós. Em muitos círculos, “sofisticado” é elogio e “burro” é crítica.

Entendo essa dinâmica e simpatizo com os engenheiros que sentem essas pressões. Esta é uma das razões pelas quais sugiro que os engenheiros seniores que têm uma posição segura numa organização de engenharia devem muitas vezes proclamar em voz alta que as coisas lhes parecem demasiado complicadas se, de facto, o fazem. Isso também permite que os engenheiros mais jovens expressem suas preocupações e alivia essas pressões organizacionalmente, pelo menos até certo ponto.