HTML First

• Se você usar primeiro os recursos nativos que o navegador já oferece, pode reduzir o quanto depende de linguagens e toolchains adicionais ao criar aplicações web
• O React aumentou a confiabilidade do desenvolvimento de UI com padrões como props, state e componentes, mas deslocou o centro da forma de desenvolver de HTML para JavaScript
• Nesse intervalo, W3C, WHATWG, IETF e TC fineC adicionaram milhares de melhorias às linguagens nativas da web, e, à medida que os principais navegadores as integraram, parte das razões para precisar de React enfraqueceu
• Em vez de tentar convencer desenvolvedores satisfeitos com React, HTML First é um movimento que busca oferecer linguagem para que pessoas interessadas em uma abordagem centrada em HTML organizem suas ideias e debatam com colegas
• Está mais próximo de uma preocupação prática: reavaliar se é possível criar software rápido e acessível apenas com as linguagens nativas da web e os recursos do navegador

---

O estilo de desenvolvimento que o HTML First defende

• HTML First prioriza HTML, CSS, JavaScript e os recursos nativos do navegador ao criar software para a web
• O ponto central é reduzir as camadas de abstração adicionadas sobre a plataforma web
  • Linguagens adicionais e toolchains também entram nessas camadas a serem reduzidas
• O objetivo é uma forma de desenvolvimento que coloque no centro os recursos que o navegador já oferece e só adicione ferramentas por cima quando necessário

O desenvolvimento web ficou mais complexo depois do React

• Antes do React, era comum criar interfaces em HTML e complementar com ferramentas como jQuery aquilo que o HTML não oferecia nativamente
  • Exemplos representativos são o envio de requisições assíncronas e a atualização do DOM
• Bibliotecas como React resolveram vários problemas do desenvolvimento web tradicional
  • Os padrões de props e state, que passam dados explicitamente de elementos pais para filhos, reduziram certos tipos de bugs
  • Agruparam UI, estilo e comportamento em componentes, permitindo instalar facilmente no próprio código algo criado por outras pessoas
• Para obter essas vantagens, foi preciso trocar uma forma de trabalho baseada principalmente em HTML por outra baseada principalmente em JavaScript
  • JavaScript é tratado como uma linguagem mais complexa
  • Também foi necessário aprender muitos dos conceitos e das ferramentas introduzidos pelo React
• A indústria aceitou esse compromisso apesar do aumento de complexidade, e esse tipo de biblioteca virou a forma padrão de criar aplicações web
  • Antes do React, quem estava começando aprendia primeiro HTML e CSS, e depois JavaScript
  • Depois do React, o fluxo mudou para aprender primeiro JavaScript e React, e depois o restante

O ponto de reavaliação criado pelas melhorias da plataforma web

• W3C, WHATWG, IETF e TC39 adicionaram milhares de melhorias às linguagens nativas da web enquanto a abordagem do React se espalhava
  • Essas melhorias foram integradas ao Chrome, Safari, Firefox e Edge
  • Muitas delas tratam diretamente de parte dos motivos que levavam as pessoas a usar React
• Com o aumento do custo de desenvolvimento de software e a ampla distribuição das melhorias dos navegadores, cresce o número de pessoas que perguntam se essas camadas adicionais ainda são realmente necessárias hoje
• A ideia de HTML First ainda é minoritária na indústria
• Essa abordagem foca em ajudar pessoas que já têm interesse em desenvolvimento centrado em HTML a consolidar suas ideias e obter linguagem e conceitos para se comunicar com colegas
• A mensagem central é que é possível, prático e razoável criar software web bonito, rápido, fácil de usar e acessível usando principalmente as linguagens e os recursos nativos da web

[GN⁺]

Opiniões no Hacker News

• Gosto da ideia aqui, mas, sinceramente, os exemplos são fracos
  O exemplo da parte “quando possível, defina estilos e comportamentos como atributos HTML inline” parece que não funcionaria de fato e, se você quiser adicionar mais estilos, a estrutura vira apenas um parâmetro de string passado para ClassList.add ficando cada vez maior
  Pessoalmente, acho button:active { background: green; } muito mais fácil de ler, mas o autor parece considerar isso complicado por causa da abordagem de “localidade do comportamento” (Locality of Behaviour)
  Concordo com a ideia de “se precisar de uma biblioteca, use uma que aproveite atributos HTML, em vez de ser centrada em JavaScript ou em uma sintaxe customizada”, mas o “on input put me into #output” do exemplo recomendado é mais estranho do que a biblioteca dada como mau exemplo, e parece que JavaScript sem framework já seria suficiente
  Como exemplo de “prefira HTML ‘cru’ a camadas ocultas que compilam para HTML”, ele diz para não usar os helpers de tags ERB do Rails, mas esses helpers cuidam de muita coisa que ficaria bagunçada se escrita diretamente em templates mínimos. O exemplo ignora partes realistas como IDs DOM únicos, tags do Turbo e iteração

  • A parte “quando possível, defina estilos e comportamentos como atributos HTML inline” também me incomodou
    Estilização e comportamento devem ser separados, e a conexão entre os dois por meio de referências é a única coisa que faz sentido em uma escala significativa
    Tecnicamente, dá para colocar todas as conexões de banco de dados SQL e SQL hardcoded de uma aplicação Python em um único arquivo enorme, mas isso é uma prática ruim; esse princípio me parece parecido

• Esta parte é confusa: “se precisar de uma biblioteca, use uma que aproveite atributos HTML, em vez de ser centrada em JavaScript ou em uma sintaxe customizada”
  Mas ele mostra _hyperscript [0] como exemplo recomendado. Isso é uma biblioteca centrada em sintaxe customizada, e apenas coloca, dentro de atributos HTML, scripts de uma linguagem nova que é preciso aprender. Não sei se é sério
  [0] https://hyperscript.org

  • Parece que isso foi escrito como uma lista de dicas para promover hyperscript
    Os exemplos também são bem fracos. A solução pura, ou seja, só a primeira dica, funciona igualmente bem
  • Concordo. O exemplo de colocar uma frase de DSL obscura como valor em um atributo chamado _ parece realmente estranho e confuso
    Eu preferiria usar uma instrução em JavaScript puro dentro de um onclick explícito ou outro atributo de evento, para dar para entender imediatamente o que está acontecendo
  • Seguindo o conselho do autor, Alpine.js teria sido uma recomendação melhor, pois usa atributos HTML e JavaScript intuitivo
  • hyperscript está relacionado ao HTMX, então parece haver pessoas tentando promovê-lo, mas, na minha opinião, ele está mais para um brinquedo interessante
  • Talvez o autor tenha trocado o exemplo recomendado com o não recomendado

• Entendo a intenção. Usar os recursos nativos do HTML é limpo e simples
  Mas isso não era prático há 10 anos e ainda não é. Também não sinto que algo como htmx seja especialmente melhor do que soluções mais pesadas como React
  A pergunta que sempre faço quando vejo essa abordagem é a mesma. Como ficam dropdowns, seleção múltipla e seletores de data? Os seletores de data existem em todos os navegadores? Sim. A aparência e o comportamento são consistentes entre navegadores? Não. Dá para igualar com estilização? Também não
  Seleção múltipla é parecida. Exigir Shift/Ctrl+clique para selecionar vários itens é completamente inviável do ponto de vista da experiência do usuário. O elemento padrão ainda funciona assim e não dá para mudar. Não só a seleção múltipla, mas também elementos comuns de seleção têm aparência péssima e, em geral, são difíceis de alterar
  Há um motivo para cada novo framework ganhar esses componentes de terceiros. É porque os elementos nativos não são suficientes. É o mesmo motivo pelo qual, mesmo com a página de Array da MDN ganhando recursos nativos a cada ano, 90% dos meus projetos ainda dependem de lodash. Está melhor do que há 10 anos, mas ainda é insuficiente

  • Pensando rapidamente só no seletor de datas, sites são projetados para os usuários
    Usuários podem usar navegadores diferentes, mas é provável que um mesmo usuário use o mesmo navegador em todos os sites que visita
    Então, na minha opinião, é mais importante que o seletor de datas seja consistente entre todos os sites dentro de um mesmo navegador do que consistente entre todos os navegadores em um único site. Claro, se recursos customizados forem necessários, a história muda
  • Quando você diz “exigir Shift/Ctrl+clique para selecionar vários itens é completamente inviável do ponto de vista de UX”, quer dizer que seleção múltipla não deve ser feita assim? Se for isso, fico curioso sobre como deveria ser
    Quando quero selecionar 10 ou 15 itens consecutivos em uma lista, no momento não conheço uma UI melhor do que Shift+clique
  • “A aparência e o comportamento são consistentes entre navegadores? Não” — isso é curioso quando se lembra que, antigamente, look and feel nativo era considerado requisito essencial para apps de desktop
    Eu preferiria muito que os componentes de UI de todos os sites seguissem o look and feel nativo do navegador, tirando o design específico do site, em vez de cada um reinventar seu próprio estilo idiota. Claro, os navegadores precisam se importar em deixar isso bonito
  • Pela discussão restante, o elemento input é famoso por ter modos de interação que variam bastante entre navegadores, enquanto a maioria dos outros elementos HTML tem um comportamento representativo bem definido

• Concordo com a maioria dos argumentos, mas este texto parece um pouco contraditório. Porque recomenda Tailwind e, ao mesmo tempo, diz para “evitar etapas de build”
  Distribuir recursos enormes de CSS/JS também contraria o princípio de inclusão. Há muita gente sem internet rápida ou um computador suficientemente potente

  • Hoje não uso Tailwind, mas, na minha experiência, Tailwind não fazia distribuir recursos enormes de CSS/JS
    Na verdade, não conheço nenhum JavaScript do lado do cliente que o Tailwind emita. Minha última experiência foi com a 2.x, então não tenho certeza se algo mudou
    Quanto ao tamanho do CSS, minha experiência também foi o oposto, e a saída do Tailwind costumava ser bem menor do que CSS escrito à mão
    Claro que não sou contra CSS puro, mas também é pelo menos igualmente fácil fazer uma bagunça com ele
  • Criei uma biblioteca de CSS atômico que não precisa de etapa de build. Se alguém quiser, está aqui. Claro, dando spoiler, ninguém quer: https://casscss.github.io/cass/
  • O Deno Fresh usa Twind para evitar a etapa de build: https://twind.dev/
    Mas, se bem me lembro, ele não oferece todos os recursos que o Tailwind completo oferece. No geral, foi frustrante que o Fresh seja, na prática, muito construído sobre Preact e Twind, sem deixar isso claro de forma honesta, e que primeiro seja preciso aceitar essas bibliotecas
  • O Tailwind tem uma CLI independente que pode ser usada como etapa de build
    Concordo em parte que é um pouco estranho recomendá-lo no contexto deste texto, mas a etapa de build pode ser extremamente minimalista, e também é bom que o resultado ainda seja CSS que dá para inspecionar
    Uso Tailwind no meu site pessoal, e todo o resto é HTML puro. Rodar a CLI em modo watch enquanto escrevo estilos não me incomoda muito
  • Como opções sem build, duas são boas: hospedar diretamente o CDN do Tailwind v3 ou usar https://github.com/gnat/css-scope-inline
    Ambas são surpreendentemente rápidas e fazem parsing de mais de 10.000 itens

• É interessante na teoria ou em exemplos simples, mas eu gostaria de ver projetos grandes que aplicaram isso e que diferença isso realmente fez
  Os objetivos no começo do texto são ótimos, mas fiquei um pouco decepcionado com os conselhos em si. Não dá para ver muito bem como funcionariam fora de situações muito básicas, e muito menos como alcançariam esses objetivos
  Sou a favor de aproveitar ao máximo a plataforma web e totalmente a favor de reduzir a complexidade tanto quanto possível. Mas sou muito cético de que esses princípios consigam isso; pelo contrário, parece que podem até aumentar a complexidade ao criar várias formas de fazer a mesma coisa
  Dizendo de boa-fé, só por esta lista não dá para saber se esses princípios foram realmente testados na prática ou se apenas se presumiu que funcionariam como esperado

  • Não entendo por que uma boa prática precisa necessariamente ser boa para projetos grandes
    Pergunto sinceramente. As pessoas levantam esse argumento com frequência, e eu nunca entendi
    Do meu ponto de vista, 95% da web são projetos de pequeno a médio porte. A maioria das tecnologias deveria se concentrar nisso. Use soluções simples para projetos simples e adicione complexidade depois
  • Tentei promover um front-end no estilo HTML first no trabalho, mas, quando contratamos desenvolvedores front-end comuns, eles basicamente não entendiam e queriam transformar tudo em divs e deixar o VueJS controlar toda a lógica e o conteúdo
    Uma coisa meio objetiva que perdemos foi acessibilidade. Como links foram ingenuamente reimplementados como divs com listeners de evento de clique, não dá para navegar pela maior parte do site com o teclado
    Isso é bem preocupante. Quando a regulamentação chegar, vamos correr desesperados para recuperar o que jogamos fora
    Ainda assim, concordo em parte que é difícil encontrar exemplos famosos de sites “HTML first”. Eu acredito nisso, mas ainda não vi um caso realmente bem executado. Só que o motivo pode estar puramente na educação. Quando o HTML ficou poderoso, a formação de desenvolvimento front-end já estava profundamente consolidada em torno de frameworks
  • Para um desenvolvedor front-end mais novo que o jQuery, começar um projeto seguindo este conselho seria uma boa oportunidade de aprender por que usamos coisas como etapas de build e como o desenvolvimento antes do HMR era penoso
    Não parece que o autor tenha realmente feito isso em um projeto com mais de duas pessoas e suporte a 99% dos navegadores existentes. Além disso, parece que nem executou o próprio código. Talvez seja porque minha tela não seja saborosa, mas onlick não é um handler de div
  • Esquecemos uma lição antiga. Backend first era um mecanismo de defesa contra pessoas que acreditam apenas no que veem e não confiam em especialistas
    Se você cria um produto que parece funcionar, mas na realidade não funciona, elas não entendem. Então você é empurrado para o caminho de prometer demais e entregar de menos
    Uma das vantagens menos conhecidas dos testes unitários é permitir que o código que a gestão não consegue ver receba mais garantia de qualidade antes de ser conectado. Eles estreitam aquele intervalo estranho entre a primeira tela aparecer e o lançamento
  • Concordo
    Em 1999, criei meu primeiro site com HTML puro, CSS e JS puro, e o hospedei no Geocities
    Depois disso, criei sites e apps com PHP/WordPress/Yii/Laravel, Ruby/Rails/Sinatra/Jekyll, React/Typescript e ClojureScript
    Hoje React, componentes TSX, CSS-in-TS, Effects e Context parecem um lar confortável. Finalmente sinto que temos uma linguagem de programação completa para a web/front-end. Uma linguagem criada explicitamente para o front-end sobre princípios modernos como programação funcional e reativa
    Só agora dá para fazer desenvolvimento de software. O HTML, CSS, JS puro e PHP de antes eram praticamente hacking. Rails era bom para full-stack, mas não brilhava no front-end
    Quando a stack web também estiver pronta para apps, vou pular os frameworks. Por enquanto, admito que talvez ela seja suficiente para sites

• Desisti este ano. Ficou impossível continuar brigando com os monstros React, Vue e Angular, com bundlers, transpilers e todo tipo de tranqueira que vem junto
  Node e npm jogam na sua cara que até um projeto criado há poucos segundos tem “7 vulnerabilidades graves e 8 críticas”. É preciso baixar milhares de arquivos, e no meio deles pode até haver coisas como um wrapper de valor booleano
  Acho que, para mim, acabou a época em que o servidor backend em Python também servia o frontend

  • Indigne-se! Enfureça-se contra a máquina!
    Na verdade, nem você nem ninguém precisa mesmo desse inchaço pesado de frontends JavaScript. É só dizer não
    Sirva páginas leves pelo backend ou pelo cache e, se for realmente necessário, faça as partes elegantes com CSS
    Você terá tempos de renderização rápidos e acessibilidade global
  • Aperte o botão de escape. Boa parte do que há de bom na Web está no Phoenix LiveView. Dá para criar sites responsivos e atraentes sem as maluquices de React/Node
    Mas, sendo sincero, os exemplos deste texto são estranhos. Não entendo por que escrever tags puras manualmente em vez de usar os helpers de formulário do Phoenix, que geram erros e vários recursos convenientes automaticamente. Entendo o espírito
  • Dá para fazer. É só experimentar htmx

• O argumento central parece ser que o usuário deve conseguir apertar View Source e entender o que está acontecendo. Para um site, concordo
  Para uma webapp, pelo menos uma com mais de 50 linhas, é bem provável que você queira usar uma linguagem com tipos. Tecnicamente, até dá para usar .js com anotações de tipo em comentários especiais e o compilador TypeScript junto, mas não achei muito agradável
  Antigamente eu era bem atraído por essa ideia, e é triste que hoje a maioria dos sites seja um bloco de HTML ilegível em uma única linha. Há beleza e elegância em distribuir tudo como um único arquivo HTML, sem dependências. Basta 1 requisição de rede
  No fim, acabei criando um “sistema de build” para facilitar a edição, mas o meu sistema de build é cat. O resultado é um software autocontido e portátil em um único arquivo legível por humanos
  No mesmo espírito, a coisa mais legal do desenvolvimento Web é que você consegue criar seu primeiro programa interativo usando só o Notepad e um navegador padrão. Basta arrastar o arquivo HTML para o navegador. Parece mágica
  Adendo: descobri uma vantagem inesperada do HTML autocontido. O software fica imune à podridão de bits. Abri um projeto antigo no Web Archive e os arquivos JS externos não tinham sido arquivados. Triste. Já este carrega bem, porque todo o JS está dentro do HTML. Vitória
  https://web.archive.org/web/20210508133239id_/https://andai....
  Isto é uma homenagem ao antigo SodaPlay Constructor. Não consegui criar o editor. Fiquem à vontade para ver o código-fonte

  • Sou cético quanto a essa parte. Hoje há muitas formas de olhar “por trás da cortina” nos painéis de desenvolvedor
    Há visualização do DOM, aba de rede, visualização de heap e recurso embutido para deixar JavaScript mais legível
    Claro que “ver o código-fonte” ainda é importante, mas tenho dúvidas se essa importância ainda é absoluta como o pessoal do HTMX diz
  • “Há beleza e elegância em distribuir tudo como um único arquivo HTML, sem dependências. Basta 1 requisição de rede”
    Agora que temos URLs data:, isso ficou ainda mais fácil. Também é útil para evitar os problemas de URLs file://, que nem exigem servidor HTTP
  • Adendo: há uma proposta para estender o JavaScript com anotações de tipo, o que pode permitir executar diretamente no navegador um “subconjunto bem grande” do TypeScript. Bom!
    https://github.com/tc39/proposal-type-annotations
  • Não acho que o autor esteja defendendo um sistema de arquivo único. Em vez disso, ele não quer dizer, mas

• “Localidade do comportamento” é uma regra definida de forma muito frouxa. É só chamar com um novo nome algo que contraria a separação de interesses.
  Chamar CSS de ação assustadora à distância também é exagerado demais. Há bons princípios, mas a argumentação é bem fraca, e poderia ter sido expressa de forma muito mais simples.

  • Do ponto de vista de quem vem de uma organização C# com interfaces demais, vejo isso como uma reação natural a sistemas excessivamente abstraídos.
    Se “trocar um botão vermelho e saltitante por um botão azul e trêmulo” exige seguir um labirinto de 3 a 7 interfaces e classes para descobrir qual classe precisa de uma nova implementação e o que pode ser reutilizado, algo que parecia uma mudança de 10 minutos vira meia jornada xingando mentalmente o compilador ou o desenvolvedor anterior.
    Claro, abstrações são necessárias, mas também deve haver uma forma de agrupar o comportamento em um só lugar para que não seja preciso mexer em 6 arquivos para alterar um componente.
    https://htmx.org/essays/locality-of-behaviour/#conflict-with...
  • Tailwind também é uma etapa de build e tem igualmente muita “ação assustadora à distância”. Se não tivesse, as pessoas simplesmente usariam CSS inline.
    Ao usar Tailwind, você está confiando que uma biblioteca de terceiros vai abstrair a especificação de CSS para você e que essa quase-especificação abstraída será respeitada conforme a configuração de build.
  • Se “localidade do comportamento” é uma regra definida de forma frouxa, a separação de interesses não é também?
    O que deve ser separado? Ao longo de quais linhas dividir? Como essas linhas são definidas? Quando faz sentido extrair um interesse para outra classe, framework, marcação etc.? Quando é melhor mantê-lo junto?
    A resposta é: “depende da situação”.
    Se nada for separado, vira espaguete; se tudo for separado ao máximo, sempre e em qualquer lugar, o resultado é código superabstraído tão difícil de manter quanto espaguete.
  • O objetivo principal declarado é “ampliar muito o conjunto de pessoas capazes de trabalhar em uma base de código de software web”. Isso é bem diferente de conselhos voltados a programadores em geral.
    Se os padrões funcionam bem, customização não é obrigatória. Por isso, ganhos de eficiência com CSS e afins ficam atrás da simplicidade.
  • O problema é multidimensional.
    Se virmos HTML como uma linguagem de documento/apresentação, não dá para negar a estilização. CSS acrescenta não só estilização, mas também animações.
    De todo modo, CSS também pode ser visto como programação orientada a aspectos.
    O verdadeiro problema descrito aqui é a falta de boas ferramentas que atravessem linguagens e frameworks.

• Faz sentido depender de frameworks mais simples quando possível. Mas a ideia de eliminar a etapa de build chega perto de ser uma piada completa.
  Torne a etapa de build mais eficiente e, se necessário, não a inclua em produção.
  Também não entendo por que deveríamos priorizar adicionar atributos ao HTML. Estamos criando documentos e hospedando-os como um site? Em que outro mundo isso é preferível? CSS não é difícil de navegar; pelo contrário, deveríamos incentivar práticas melhores de CSS.
  Scripts de frontend podem embaralhar a estilização, mas, se você não precisar disso, simplesmente não dependa desse método. É mais fácil colocar estilos em um documento de estilos do que inserir atributos com JavaScript, então isso já é óbvio.
  Parte dos conselhos no estilo “use só o que precisa” faz sentido e é evidente. Mas o resto é confuso ou abertamente absurdo. Também não entendo por que se presume que poder copiar uma página HTML inteira seja algo bom. Sinceramente, não me importo; mesmo que eu não consiga ver o HTML de algumas páginas, já existem literalmente milhões de recursos para aprender HTML.
  No geral, fico coçando a cabeça.

  • Boa parte disso é uma reação ao culto à complexidade no setor de desenvolvimento web.

• Este texto inteiro é um antipadrão e um mau conselho. Parece escrito por alguém que nunca passou pelas dores de crescimento de construir um site complexo.
  No começo, nós também criávamos sites assim, mas eles começaram a quebrar por causa de efeitos colaterais, nomes de classes conflitantes e observabilidade interna ruim, e então o React veio nos salvar.
  O padrão desejado é aprimoramento progressivo, e a saída deve ser HTML limpo e comprimido, com JavaScript reforçando isso. Ou seja, é necessária uma etapa de build. É exatamente o oposto do conselho deste texto.

  • Criar sites com React também tem armadilhas, e usar React significa introduzir muita complexidade.
    Se você já não usa NodeJS no backend, é melhor evitar ReactJS até que ele seja realmente necessário.