Eu esperava um carro rápido. Não esperava um carro com dez bocais de propulsão a ar comprimido, usando tecnologia derivada da SpaceX, e um sistema de sucção embaixo capaz, segundo Elon Musk, de puxar até 2 G. Na demonstração, a Tesla anunciou zero a 60 milhas por hora, quase 97 km/h, em 0,81 segundo. Não divulgou o protocolo da medição.

Era esse o futuro que eu queria ver.

A demonstração inteira está na transmissão oficial da Tesla. A Road & Track mediu e descreveu as manobras, e a TechCrunch detalhou as três versões: Performance com aerodinâmica ativa e sucção, Thrust com propulsores traseiros, Rocket com sistema de propulsão de dez bocais e apenas um assento.

Claro, o que vimos foi um protótipo numa demonstração controlada. A Tesla prevê iniciar a produção em 2028, e a versão Rocket não está aprovada para uso em vias públicas. Ainda assim, um carro de verdade saiu do chão, girou e pousou. Eu assisti a isso ao vivo do meu escritório. Foi espetacular.

Enquanto Musk faz foguetes pousarem e carros voarem, eu estava fazendo um trabalho bem mais mundano e pequeno: mexendo nos meus sites.

Seis sites em cerca de um dia

Antes do evento da Tesla, eu passei o dia inteiro redesenhando seis sites:

• Akita’s AI Lair, agora combinando com o visual do meu livro novo, Competente o Suficiente;
• ai-memory;
• ai-jail;
• a newsletter The M.Akita Chronicles;
• o arquivo da newsletter;
• e este blog, AkitaOnRails.com.

Todos começaram com variações daquele tema padrão que o Claude faz. Fundo escuro, gradiente roxo ou azul, fonte sans enorme, cartões arredondados, brilho atrás de alguma coisa. Funciona. Também ficou tão comum que hoje você bate o olho e reconhece “site feito pelo Claude” antes de ler o título.

Eu já tinha tentado pedir designs diferentes pro Claude. Ele trocava a cor, movia os cartões e entregava a mesma gramática visual. Publiquei algumas telas e o resultado da mudança no Twitter. Eu não sou web designer e, por um tempo, aceitei o “funciona”. Ontem cansei.

Alguém me sugeriu o Stitch, do Google. É uma ferramenta experimental do Google Labs que transforma instruções e imagens em interfaces editáveis e código de front-end. A primeira versão foi apresentada em 2025 em cima do Gemini; a versão atual virou uma tela de design com agente, protótipos e exportação de um DESIGN.md que outros agentes conseguem seguir.

Criei a conta, peguei o token da API e comecei a trabalhar. O Stitch gerava direções visuais. Claude Code e Codex levavam essas direções pros repositórios reais, adaptavam os componentes, corrigiam responsividade, trocavam imagens, ajustavam SEO, testavam e faziam deploy. Quando a cota de um acabava, eu continuava com o outro.

Os seis sites saem de cinco repositórios. Olhando todos lado a lado, uma coisa ficou clara: o Stitch responde muito melhor quando recebe uma metáfora concreta, o público e o que aquele produto precisa comunicar. O ai-memory virou um arquivo de memória. O ai-jail, uma prisão cinematográfica. O AI Lair adotou uma feira mundial dos anos 1950 e 1960, puxada pela capa do meu livro. A newsletter virou uma transmissão noturna, e este blog, um arquivo editorial. Cinco identidades diferentes em vez de cinco variações do mesmo gradiente do Claude.

O protótipo bonito é a parte fácil. O trabalho só termina quando a linguagem visual chega às páginas internas, ao artigo, ao leitor do livro, ao e-mail, às páginas legais, aos estados de erro e ao celular. Foi isso que os agentes fizeram nos repositórios. No ai-memory, por exemplo, a verificação cobriu 102 páginas em seis idiomas, nos temas claro e escuro, em desktop e celular. No The M.Akita Chronicles, o mesmo design precisou funcionar na inscrição, no arquivo, no detalhe de newsletter, no podcast e no template do e-mail. Um mockup do Stitch não resolve nada disso sozinho.

Foram várias rodadas de protótipos em cada site. Algumas ficaram horrorosas. Outras tinham uma ideia boa cercada de decisões ruins. Eu mandava descartar, preservar uma parte, misturar com outra tentativa e recomeçar. Código ficou barato, então não existe motivo pra se apaixonar pela primeira versão.

O resultado não vai ganhar prêmio de design. Um designer profissional ainda encontraria centenas de coisas pra melhorar. Eu mesmo sei que consigo avançar se gastar mais alguns dias. Só que ficou muito melhor do que estava e, por enquanto, está competente o suficiente.

Seis sites existentes redesenhados, responsivos, com SEO, geração e substituição de imagens, ajustes de HTML, CSS e JavaScript, teste e deploy em produção. Uma pessoa. Cerca de um dia. Um ano atrás, esse pacote seria trabalho de semanas ou meses.

Vamos manter a proporção: são sites pequenos, a maioria landing pages e páginas de conteúdo. Ninguém vai recriar o conjunto inteiro de páginas e sistemas da Amazon.com em um dia. O experimento mostra quanto trabalho repetitivo já saiu da frente, dentro de um escopo que uma pessoa experiente consegue entender e revisar. Projetos grandes continuam grandes, cheios de regras privadas, integrações antigas, estados estranhos e decisões que não cabem num prompt.

Até o primeiro proofreading pode ser automatizado

No mesmo processo eu mandei agentes revisarem os sites como leitores diferentes. Não era correção gramatical. Eu queria saber o que uma pessoa entenderia nos primeiros segundos, onde ficaria perdida, qual promessa pareceria suspeita e se conseguiria completar uma tarefa sem já conhecer o produto.

No ai-jail, usei duas sessões isoladas. Uma assumiu o papel de um engenheiro cético que aprova todos os prompts e nunca tinha ouvido falar do projeto. A outra era gerente de oito desenvolvedores, sem ser engenheira, tentando decidir se deveria aprovar a ferramenta na empresa. No ai-memory foram três: um engenheiro aprendendo ferramentas de IA, uma gerente avaliando um piloto e um pai sem experiência com agentes, preocupado com AGI e empregos. Cada um leu o site sem ver o relatório dos outros.

Qualquer pessoa consegue fazer o mesmo. Suba a aplicação localmente ou abra um deploy de preview, comece sessões novas e dê a cada agente uma tarefa concreta. Um prompt básico pode ser assim:

Abra este site em desktop e celular: [URL].

Você é [perfil], conhece [contexto] e nunca viu este produto.
Seu objetivo é [decisão ou tarefa concreta].

Navegue como essa pessoa. Não leia código nem documentação interna antes.
Registre:
- o que entendeu nos primeiros dez segundos;
- o que acha que o produto faz e para quem serve;
- onde não soube qual era o próximo passo;
- promessas contraditórias, absolutas ou difíceis de acreditar;
- termos que o site usa antes de explicar;
- problemas de leitura, teclado, contraste, toque e responsividade;
- o que impediria você de testar, comprar ou aprovar.

Para cada achado, mostre a página e a evidência visível.
Separe bug factual, problema de uso e preferência subjetiva.
Não proponha redesign geral. Sugira a menor mudança que resolve o problema.

Eu prefiro três sessões independentes a uma mesa-redonda de agentes. Se um lê o relatório do outro, começa a concordar por inércia. Depois uma sessão separada consolida os pontos repetidos, descarta gosto pessoal e confere cada afirmação contra o código e a documentação do produto. A revisão pode apontar que uma frase está errada; ela não tem autoridade pra inventar a frase correta.

Os resultados mais úteis costumam cair em quatro grupos: posicionamento, ordem da informação, caminho até a primeira ação e confiança. Testes automáticos tradicionais continuam cuidando de link quebrado, contraste, acessibilidade, overflow e estado de erro. A persona mostra que o botão tecnicamente acessível apareceu cinco telas depois de onde a pessoa precisava dele.

No proofreading do ai-jail, os dois perfis concordaram que o site demorava pra mostrar o risco concreto e falava cedo demais como documentação de engenheiro. A ameaça de uma página envenenada foi puxada pra logo depois do hero. Entraram as seções “O que muda no primeiro dia” e “Para quem precisa aprovar isto”, com custo operacional, limites e as chaves que uma empresa realmente expõe. A revisão também encontrou uma afirmação tecnicamente errada repetida em várias páginas: a rede não fica inteiramente desligada por padrão. O host da própria API do agente e, no Linux, os registries continuam acessíveis. Esse tipo de leitura também encontra bug de documentação.

O relatório do ai-memory encontrou permissões descritas de formas contraditórias, promessas de privacidade absolutas demais e a explicação básica soterrada por features avançadas. Na segunda rodada, os perfis perceberam que a instrução de acesso remoto mandava usar HTTP antes de exigir TLS, que um curl sem autenticação prometia a resposta errada e que escolhas importantes apareciam tarde demais no celular. O guia de coleta saiu de aproximadamente 4.364 pixels do topo pra 1.617; os caminhos pra indivíduo ou equipe, de 5.300 pra 2.489. Isso é uma melhoria objetiva nascida de leitura simulada.

No redesign do AI Lair, a revisão para leitores novos reorganizou o caminho de entrada. Uma revisão seguinte deixou explícito que o meu setup com vários agentes e dois monitores é uma configuração madura, não requisito pra começar. Uma pessoa, um projeto e um agente bastam. Também surgiu um roteiro de piloto pra gerente: tarefa reversível, dado não sensível, critério de aceitação, prazo, orçamento e medição. A auditoria seguinte encontrou ARIA inválido e uma animação que escondia o texto de abertura de tecnologias assistivas; a correção levou o axe-core de quatro violações sérias pra zero.

Personas simuladas ainda ficam muito abaixo de feedback humano. Carregam os mesmos vícios dos modelos, podem concordar com o prompt e nunca sentem a irritação de quem perdeu vinte minutos, nem assumem o risco de colocar o próprio cartão de crédito. Os relatórios servem como hipóteses. Um usuário real sempre encontra o caso que eu, o agente e a suíte de testes não imaginaram.

Só que antes do primeiro usuário existir, a alternativa costuma ser nenhuma revisão. Duas ou três leituras independentes já pegam promessa contraditória, jargão sem explicação, informação enterrada e fluxo que só faz sentido pra quem escreveu. Rodar essas leituras custa pouco e deixa o produto menos burro antes de chegar em gente de verdade.

HTML nunca foi programação

Durante anos eu vi gente fazendo uma ginástica danada pra defender que “HTML é linguagem de programação” e, portanto, quem escreve HTML é programador.

HTML é marcação: descreve a estrutura de um documento. CSS descreve apresentação. Isso tem valor, exige conhecimento e pode ficar terrivelmente complexo. Complexidade acidental não transforma marcação em programação.

E não há vergonha nenhuma nisso. Comecei a fazer sites nos anos 1990. Recebia um layout feito no Photoshop e transformava aquilo em HTML. Recortava imagens, montava tabela, ajustava pixel, abria em vários navegadores, voltava e tentava de novo. Foi trabalho honesto e pagou minhas contas.

Também era um trabalho basicamente mecânico: copiar, colar, ajustar, olhar, repetir. Exatamente a categoria que computadores deveriam automatizar.

Hoje eu ainda escolhi direção visual, descartei propostas ruins, decidi o que cada site precisava comunicar e reconheci quando o resultado estava bom o suficiente. Os agentes fizeram o serviço braçal. É assim que deveria ter sido há anos.

A bolha atrasou a automação

Durante boa parte dos anos 2010, os juros americanos ficaram perto de zero. Dinheiro barato irrigou fundos, startups e empresas grandes. Contratar mais gente era fácil, e o mercado absorvia qualquer quantidade de trabalho manual disfarçado de engenharia.

Juro baixo não explica sozinho a expansão da tecnologia, mas uma área em recorde de contratação tem pouco incentivo pra eliminar o próprio trabalho repetitivo. Se você consegue colocar mais cinquenta pessoas pra montar tela, coloca mais cinquenta pessoas pra montar tela.

Quem assistiu às minhas palestras em eventos de tecnologia nos anos 2010 deve lembrar de Restrição == Inovação. O nome correto era com dois sinais de igual mesmo. Apresentei essa palestra na DevConf 2019, os 83 slides estão no meu SlideShare, e eu já tinha escrito a mesma tese em 2013, em “Restrições são libertadoras: menos é mais”.

É a velha máxima: a necessidade é a mãe da invenção. Restrição obriga a escolher. Escolha obriga a priorizar. Quando o caminho convencional não cabe no dinheiro, no prazo ou na capacidade disponível, alguém precisa encontrar outro caminho. É daí que costuma sair inovação de verdade.

Dinheiro financia pesquisa cara, compra equipamento e dá tempo pra experimentar. Sobra de dinheiro sem pressão por resultado faz outra coisa: esconde ineficiência com força bruta. Não precisa automatizar, simplificar nem descobrir uma solução melhor enquanto ainda der pra contratar mais gente e aumentar a planilha. Abundância demais transforma problema técnico em despesa operacional e empurra a decisão difícil pra depois.

Eu repeti esse aviso no começo de 2026: a bolha de programação conseguiu substituir eficiência por volume. A restrição voltou quando o dinheiro barato acabou. Coincidentemente, os agentes chegaram na mesma hora e deram às empresas uma maneira prática de automatizar o trabalho mecânico que elas passaram uma década escalando com contratação.

Foi assim que a gente passou uma década recriando o mesmo painel administrativo e chamando de inovação. Toda semana aparecia a próxima salvação do front-end: React, Angular, Vue, Svelte, outro bundler, outro framework em cima do framework. São ferramentas úteis em seus contextos, mas nenhuma atacava a pergunta óbvia: por que um ser humano ainda está escrevendo à mão a milésima variação do mesmo formulário?

O estouro da bolha de contratação em 2022 encerrou a festa. No fim daquele ano, o ChatGPT levou modelos de linguagem ao público. GPT-2, só pra corrigir a cronologia, tinha saído em 2019. Quatro anos depois do ChatGPT, programação agêntica virou ferramenta normal de trabalho.

Qualquer tarefa que consiste em copiar padrão, adaptar exemplo, rodar, olhar o erro e tentar de novo já está no alcance desses agentes. Front-end é o alvo mais visível porque acumulou uma quantidade absurda desse trabalho. O resto da programação não está protegido por alguma aura mística. Tem muito back-end que é CRUD, cola entre APIs e configuração repetida. Também será automatizado.

Pra mim, ótimo. Programar nunca foi digitar código. Programar é fazer um computador executar algo útil.

VS Code é o novo cartão perfurado

Eu escrevi exatamente sobre isso em abril, em “VS Code é o novo Cartão Perfurado”.

Por décadas, a interface entre intenção e computador mudou. Primeiro você ligava fios e chaves. Depois perfurava cartões. Depois escrevia Assembly, C, linguagens de alto nível, frameworks e configuração. Cada geração olhou pra anterior e automatizou uma camada de trabalho manual.

Ninguém em sã consciência defenderia hoje que operar uma perfuradora de cartões era a essência da ciência da computação. Era a interface disponível. Digitar cada tag e cada regra de CSS no VS Code também era a interface disponível.

Agora eu descrevo a intenção, mostro referências, avalio o resultado e mando o agente corrigir. Ainda preciso entender como navegador, rede, cache, acessibilidade, semântica, responsividade e SEO funcionam. Sem fundamento eu nem saberia dizer se o agente entregou uma solução ou uma bomba-relógio bonita. O teclado perdeu importância; julgamento ganhou.

Hoje, todos os modelos Tier A que eu testo, de Claude a Kimi, conseguem executar com confiabilidade o trabalho mecânico de front-end que apareceu nesses seis projetos. Eu consigo afirmar, sem hesitar, que qualquer tarefa de front-end que só transforma uma decisão já tomada em código é automatizável. Eles não inventaram seis designs brilhantes sozinhos, porém nenhum precisou que eu escrevesse manualmente o flexbox, o breakpoint ou o componente que já expliquei.

Isso cobre uma parcela enorme do trabalho, mas deixa justamente a parte de maior valor. Alguém ainda precisa conhecer os prós e contras do framework, entender o browser, escolher a arquitetura, perceber quando a biblioteca está sendo usada contra o seu desenho e descobrir por que uma solução aparentemente correta quebra numa combinação específica de aparelho, idioma, estado e dado real. O agente escreve o código; um profissional experiente dá direção, limita o estrago e assume o resultado.

Front-end continua existindo. O excesso de trabalho mecânico e de gente contratada só pra executar receita pronta é que perde valor. Um ótimo profissional de front-end consegue dirigir agentes e entregar muito mais do que entregava sozinho. Um profissional mediano que passou anos confundindo digitação de componente com engenharia vai disputar menos vagas. O mercado fica menor e mais seletivo, com os melhores profissionais produzindo mais. A meta continua a mesma de sempre: chegar perto do topo, onde julgamento e experiência ainda fazem diferença.

E isso não para no browser. Escolha o framework: Android com Flutter ou Kotlin, iOS com Swift e SwiftUI, desktop com Rust/Tauri, Flutter, C# ou Electron. Em geral, agentes modernos conhecem os componentes, as ferramentas de build, os testes e as peculiaridades dessas plataformas. Ainda precisam de direção, feedback e verificação, exatamente como no front-end web. A parte mecânica já é automatizável.

Eu testei isso nos meus próprios projetos pequenos e abertos. O FrankYomik tem um cliente Flutter pra Android e Linux, além do servidor e da extensão. O Frank Sherlock é um app desktop em Rust/Tauri que gera AppImage pra Linux, DMG pra macOS e instalador .exe pra Windows. Também fiz o Frank Karaoke em Flutter pra Android e o FRANK MANGA+ em Rust/Tauri pra desktop. Há vários outros no meu GitHub.

Nenhum deles saiu perfeito no primeiro prompt. Flutter e Tauri me deram trabalho, especialmente nos primeiros projetos. Confiável quer dizer que o agente consegue avançar, receber uma correção, criar testes, corrigir o que quebrou e chegar num aplicativo funcional sem eu assumir a digitação braçal. Depois de testar web, Android e desktop em stacks diferentes, estou muito satisfeito com o resultado. O padrão se repete: trabalho mecânico virou trabalho de agente.

Às duas da manhã eu tinha agentes fazendo os últimos ajustes neste blog sem perder o ritmo. É disso que eu preciso.

Quando a web ainda não sabia o que era

No auge da bolha da Internet, designers de carreira estavam criando sites. A web ainda não tinha decidido como uma página deveria funcionar, então havia espaço real pra experimentar. Era feio muitas vezes, pesado quase sempre, mas tinha criação acontecendo.

O iPhone abriu outra janela em 2007. De repente tudo precisava caber numa tela pequena, responder ao toque e funcionar sem mouse. Vieram anos de experimentação até o mercado formar uma gramática razoavelmente estável de navegação, gesto, formulário e conteúdo.

Hoje ninguém precisa redescobrir um menu, uma lista, um checkout ou uma página de artigo. Os padrões estão documentados, milhões de exemplos estão públicos e os modelos viram mais interfaces do que qualquer pessoa conseguiria estudar durante a vida.

O trabalho mais valioso continua existindo: entender o produto, a pessoa que vai usá-lo, as restrições e o que merece aparecer primeiro. O trabalho de converter uma decisão pronta em centenas de linhas previsíveis virou candidato perfeito à automação.

Empregos desaparecem. Outros aparecem

O mundo nunca ficou parado pra preservar uma função.

Operadores de cartão perfurado digitavam dados e programas em papel. Telefonistas conectavam chamadas fisicamente. Datilógrafos mantinham escritórios funcionando. Linotipistas montavam linhas de metal quente pra imprimir jornais. A tecnologia reduziu ou eliminou essas ocupações em escala. A lista atual de profissões em maior declínio do Bureau of Labor Statistics ainda inclui digitadores, datilógrafos e operadores de telefonia. Ninguém propõe voltar a elas pra proteger emprego.

Ao mesmo tempo apareceram trabalhos que uma pessoa de 1926 nem conseguiria nomear: desenvolvedor mobile, SRE, designer de experiência, criador de vídeo pra Internet, especialista em nuvem, engenheiro de machine learning. A própria web matou trabalho antigo e abriu uma indústria inteira.

A história real é menos limpa do que a caricatura. A OIT mostra que a tecnologia costuma automatizar tarefas sem necessariamente eliminar ocupações inteiras. Algumas funções encolhem, outras mudam e trabalhos novos aparecem. Esse consolo estatístico não resolve a vida de quem ficou obsoleto hoje. A pessoa precisa reagir antes que a média da economia reaja por ela.

Compare 2026 com 1926, três anos antes do crash de 1929. Parece outro planeta, embora um século seja muito pouco na escala da história. Não existe contrato garantindo que a sua função atual sobreviva aos próximos dez anos, muito menos aos próximos quarenta.

E como um júnior ganha experiência agora?

Vai ficar mais difícil. A escada antiga começava com alguém pagando um iniciante pra montar tela simples, corrigir CSS e copiar componente. O agente faz boa parte disso mais rápido e barato. Empresa nenhuma tem obrigação de preservar trabalho ineficiente como programa de treinamento.

O iniciante vai ter que construir a própria escada com projetos reais e problemas pelos quais ele seja responsável. Isso inclui ler o código que o agente gerou, quebrar e consertar, estudar documentação e código-fonte, escrever testes e contribuir com projetos abertos. O agente dá a qualquer estudante acesso a uma quantidade de prática que antes exigia uma equipe. Quem usar isso só pra gerar código que não entende vai continuar júnior por muito tempo.

O mercado vai premiar quem fizer esse esforço extra. Sempre premiou. Quando alguém pergunta como o júnior vai ganhar experiência sem as tarefas fáceis, muitas vezes a pergunta escondida é outra: “como eu consigo um salário melhor sem passar pelo trabalho difícil de ficar bom?” A vaga fácil, com salário crescente e pouca cobrança, foi uma distorção da bolha. Adaptar-se inclui aceitar que a entrada ficou mais competitiva.

Minha carreira nunca ficou no mesmo lugar

Comecei com multimídia e sites estáticos. Depois trabalhei em agência digital, consultoria enterprise, integração de SAP, startups, vídeo, educação e, agora, IA. No Akitando sobre SAP, eu conto parte dessa fase em que precisei aprender um mundo completamente diferente do que fazia antes.

Atravessei o crash das pontocom, a crise de 2008 e o fim da bolha de juro zero. Sobrevivi porque nunca tratei a minha função do momento como identidade permanente. Continuei estudando, acumulando experiência e mudando de direção.

Uma carreira produtiva não deveria consistir em repetir a mesma tarefa mecânica por décadas. Se o seu valor depende de o mercado continuar pagando alguém pra empurrar tag e pixel à mão, o problema não começou com a IA. O problema foi apostar que o presente seria eterno.

Muita gente entende “estar preparado” como estudar o mínimo necessário pra vaga aberta hoje. Essa é a receita mais rápida pra ficar obsoleto. Faça o trabalho de curto prazo, mas estude além dele. Aprenda as coisas que parecem inúteis agora. Fundamentos, sistemas operacionais, redes, bancos de dados, negócio, economia, história. Você não sabe qual combinação vai salvar sua carreira daqui a cinco anos.

Eu passei anos falando disso no Akitando. Reveja as playlists Eu Avisei e Que curso devo fazer??. Se tiver que começar por um vídeo, comece pelo Guia DEFINITIVO de Aprendendo a Aprender. Curso nenhum salva quem ainda terceiriza o próprio aprendizado.

O mundo não tem falta de oportunidade. A maioria das pessoas sente que nunca recebe uma porque está sempre despreparada quando ela aparece. Quando a oportunidade pousa na sua frente, já é tarde pra começar a preparação.

Portanto, eu não vou lamentar que o pacote desses seis sites pequenos, que antes tomaria semanas ou meses, tenha cabido em cerca de um dia. Estou feliz pra cacete. Ganhei tempo pra pensar no que construir, experimentar mais e jogar fora versões ruins sem desperdiçar semanas de vida.

Hoje eu vi um carro girar no ar e pousar. Em cerca de um dia, coloquei seis sites com visual novo em produção sem escrever a maior parte do HTML e CSS. O futuro que eu queria não chegou perfeito, barato nem distribuído igualmente. Mas chegou o bastante pra eu trabalhar com ele.

Aceite o que acabou. Estude o que vem depois. E esteja pronto antes da próxima oportunidade aparecer.

E não deixe de assinar minha nova newsletter The M.Akita Chronicles!

–

Existe uma obsessão no mercado de que frontend = React. Ou Vue. Ou Svelte. Ou o framework da semana. E se eu te disser que é possível ter um frontend moderno, responsivo, com dark mode, email-compatible, multi-plataforma — sem uma única linha de JavaScript framework?

Não estou falando de sites estáticos dos anos 2000. Estou falando de Tailwind CSS v4 no Rails, Hugo com tema Hextra pro blog, e templates de email que funcionam do Gmail ao Outlook 2016. Tudo no mesmo projeto, com um desenvolvedor.

Tailwind CSS v4: O Fim do CSS Artesanal

Eu tenho uma confissão: CSS sempre foi minha kryptonita. Não porque é difícil — mas porque é imprevisível. Você muda um margin-top e quebra o layout de uma página que nem tocou. Cascata, especificidade, herança — é um campo minado.

Tailwind resolve isso da forma mais pragmática possível: classes utilitárias direto no HTML.

<div class="flex items-center gap-4 p-6 bg-white dark:bg-gray-800
            rounded-xl shadow-sm border border-gray-200 dark:border-gray-700">
  <img class="w-12 h-12 rounded-full" src="/images/avatar.jpg">
  <div>
    <h3 class="font-semibold text-gray-900 dark:text-gray-100">Título</h3>
    <p class="text-sm text-gray-500 dark:text-gray-400">Descrição</p>
  </div>
</div>

“Mas isso é inline style com passos extras!” — Não, não é. É um sistema de design com constraints. Você não escolhe “margin: 17px” — você escolhe m-4 (16px) ou m-5 (20px). Esse constraint force consistência visual sem precisar de um design system documentado em 40 páginas.

E o Tailwind v4, que veio com o Rails via tailwindcss-rails, tem uma mudança fundamental: CSS-first configuration. Acabou o tailwind.config.js. Tudo é CSS:

@import "tailwindcss";

@theme {
  --color-brand: #8b5cf6;
  --font-sans: "Inter", system-ui, sans-serif;
}

Menos um arquivo de config. Menos um passo de build. Mais simples.

Dark Mode: Respeite Seu Usuário

Uma coisa que me irrita profundamente é site que ignora preferência de tema do sistema operacional. O usuário configurou dark mode no OS — respeita.

Com Tailwind, dark mode é trivial:

<body class="bg-white dark:bg-gray-900 text-gray-900 dark:text-gray-100">

O dark: prefixo aplica o estilo quando o sistema operacional está em dark mode (via prefers-color-scheme: dark). Não precisa de JavaScript. Não precisa de toggle. Não precisa de cookie. Funciona.

Mas “funciona” é o mínimo. O desafio real é manter consistência entre dezenas de componentes. Toda cor que você usar precisa de uma variante dark:. Todo background, todo texto, toda borda.

O truque: crie convenções e siga. Background principal? bg-white dark:bg-gray-900. Texto primário? text-gray-900 dark:text-gray-100. Texto secundário? text-gray-500 dark:text-gray-400. Bordas? border-gray-200 dark:border-gray-700. Com 4-5 pares definidos, 90% dos componentes ficam cobertos.

Hugo + Hextra: Blog Sem Banco de Dados

O blog do projeto roda Hugo com o tema Hextra. Hugo é um gerador de sites estáticos escrito em Go — absurdamente rápido. Rebuild completo em <500ms mesmo com dezenas de páginas.

O que torna o Hextra especial é que ele é um tema de documentação adaptado pra blog. Sidebar de navegação, search integrado, table of contents — tudo pronto. E customizável via layouts parciais:

layouts/
├── _partials/
│   ├── custom/
│   │   └── head-end.html          # Injeta analytics, fonts, CSS customizado
│   └── section-box.html           # Partial compartilhado (DRY, veja abaixo)
├── blog/
│   └── home.html                  # Homepage customizada
├── newsletters/
│   └── single.html                # Template de newsletter individual
├── podcast-transcripts/
│   └── list.html                  # Listagem de episódios
└── shortcodes/                    # 17 shortcodes — componentes sem JS
    ├── podcast-turn.html          # Balão de fala no transcript
    ├── akita-comment.html         # Comentário do Akita
    ├── marvin-comment.html        # Comentário do Marvin
    ├── history-timeline.html      # Timeline de eventos históricos
    ├── market-ticker.html         # Tabela de tickers financeiros
    ├── market-map.html            # Mapa FinViz S&P 500
    ├── subscribe-cta.html         # Call-to-action de inscrição
    ├── score.html                 # Badge de relevância (high/medium/low)
    ├── holidays.html              # Feriados e datas comemorativas
    ├── ref-stories.html           # Links de referência
    ├── book-downloads.html        # Links de download do livro
    ├── hacker-news.html           # ┐
    ├── anime-ranking.html         # │ Section boxes — delegam para
    ├── youtube-digest.html        # │ section-box.html (ver abaixo)
    ├── world-events.html          # │
    ├── market-news.html           # │
    └── qa.html                    # ┘

Cada tipo de conteúdo tem seu template. Newsletters têm sidebar de navegação e seções visuais. Transcrições de podcast têm player embutido e formatação de diálogo. O mesmo conteúdo Markdown é renderizado de formas diferentes dependendo do type no frontmatter.

Shortcodes: Componentes Sem JavaScript

Hugo shortcodes são o equivalente a componentes React, mas sem build step:

<!-- layouts/shortcodes/podcast-turn.html -->
{{ $speaker := .Get "speaker" }}
{{ $isAkita := eq $speaker "akita" }}

<div class="podcast-turn" style="display: flex; {{ if $isAkita }}flex-direction: row{{ else }}flex-direction: row-reverse{{ end }};">
  <img src="/images/{{ $speaker }}.jpg"
       style="width: 40px; height: 40px; border-radius: 50%;">
  <div class="bubble {{ if $isAkita }}akita-bubble{{ else }}marvin-bubble{{ end }}">
    {{ .Inner | markdownify }}
  </div>
</div>

No Markdown, o autor escreve:

{{< podcast-turn speaker="akita" >}}
Então, vamos falar sobre o que aconteceu essa semana no mundo tech...
{{< /podcast-turn >}}

E o Hugo renderiza um balão de chat estilizado, com avatar, alinhamento correto, e markdown processado. Zero JavaScript. Zero framework. HTML + CSS + template logic.

DRY com Partial Compartilhado

Com 17 shortcodes, duplicação vira problema rápido. Sete deles — os “section boxes” que envolvem seções da newsletter (Hacker News, Anime, YouTube, etc.) — têm a mesma estrutura visual: ícone, título, borda colorida, conteúdo Markdown. Só mudam a cor e o label.

A solução é um partial compartilhado que recebe parâmetros:

<!-- layouts/partials/section-box.html -->
<div class="section-box {{ .class }}">
  <div class="section-box-header">
    <span>{{ .icon }}</span> {{ .label }}
  </div>
  <div class="section-box-content">{{ .content | markdownify }}</div>
</div>

E cada shortcode vira uma linha:

<!-- layouts/shortcodes/hacker-news.html -->
{{ partial "section-box" (dict "class" "hacker-news" "icon" "&#128274;" "label" "The Hacker News" "content" .Inner) }}

É o equivalente Hugo de herança de componentes: um partial polimórfico parametrizado por dict. O CSS em custom.css define cores por classe (.hacker-news, .anime-ranking, etc.) com variantes light/dark. Resultado: 7 shortcodes que antes tinham HTML duplicado agora são 7 linhas + 1 partial + CSS.

Mas tem um pegadinho crucial: shortcodes são exclusivos do Hugo. O mesmo conteúdo que vai pro blog também vai por email. E email não entende shortcodes.

O Desafio: Mesmo Conteúdo, Dois Renders

Aqui está o problema central de frontend nesse tipo de projeto: o mesmo arquivo Markdown precisa funcionar em dois contextos completamente diferentes.

No blog (Hugo):

• Shortcodes funcionam (\{\{< subscribe-cta >\}\})
• CSS com classes (Tailwind, Hextra)
• Dark mode via prefers-color-scheme
• Imagens responsive
• Layout flexível

No email (Rails → Amazon SES):

• Shortcodes são texto morto — precisam ser removidos
• CSS deve ser inline (muitos clientes de email ignoram <style>)
• Dark mode? Esqueça pra 80% dos clientes
• Imagens com URLs absolutas e tamanho fixo
• Layout com <table> (sim, em 2026)

A solução: dois pipelines de renderização independentes. O conteúdo Markdown é a source of truth. O Hugo transforma pra web. O Rails transforma pra email. Cada um com suas regras.

No lado do Rails, o serviço MarkdownToHtml precisa:

1. Processar Markdown padrão
2. Converter \{\{< shortcode >\}\} em HTML equivalente ou removê-los — via um hash de SHORTCODE_PATTERNS que mapeia cada shortcode a uma regex + template inline com CSS
3. Aplicar tema (light/dark baseado na preferência do assinante)
4. Injetar CSS inline pra compatibilidade de email clients
5. Reescrever URLs de imagem pra absolutas

É mais trabalho que parece. Cada shortcode precisa de um equivalente email-safe. Avatares de comentário precisam de URLs absolutas. Seções com background colorido precisam de <td style="background-color:..."> ao invés de classes CSS.

Email HTML: O Pior Frontend do Mundo

Se você acha que cross-browser compatibility é difícil, tente cross-email-client compatibility. O Outlook 2016 renderiza HTML usando o engine do Microsoft Word. Sim, Word. Não é piada.

As regras de sobrevivência:

1. Layout com <table>. display: flex? grid? Não existem no Outlook.
2. CSS inline em todo elemento. <style> tags são ignoradas por vários clients.
3. Sem margin em imagens. Use padding na <td> pai.
4. Fonts web não funcionam. Use font stack: font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', sans-serif;
5. Temas são preferência do assinante, não detecção automática — muitos email clients não suportam prefers-color-scheme.

O template de email do projeto é um ERB que recebe variáveis de tema:

<td style="padding: 8px 28px; color: <%= @theme[:text] %>;
           background: <%= @theme[:card_bg] %>;">
  <%= raw @content %>
</td>

O tema define todas as cores:

THEMES = {
  light: {
    text: "#1a1a1a",
    card_bg: "#ffffff",
    link_color: "#7c3aed",
    # ...
  },
  dark: {
    text: "#e6edf3",
    card_bg: "#161b22",
    link_color: "#a78bfa",
    # ...
  }
}

Cada assinante escolhe seu tema na hora de se inscrever. O email é renderizado com as cores corretas pra aquela pessoa. Sem media queries, sem detecção automática — porque email clients não suportam de forma confiável. É mais simples dar a escolha pro usuário.

Paleta de Cores: HSL e a Ciência por Trás das Escolhas

“Mas como vocês escolheram essas cores?” — Não foi no olhômetro. Existe uma ciência por trás, e ela se chama HSL (Hue, Saturation, Lightness).

A maioria dos desenvolvedores pensa em cor como hex (#e8eef8) ou RGB (rgb(232, 238, 248)). São formatos de máquina — úteis pra renderizar, inúteis pra projetar. Quando você olha #3b50a2 e #c93030 lado a lado, não tem como saber intuitivamente se vão funcionar juntas. São só números.

HSL resolve isso. Em vez de misturar canais de luz (Red, Green, Blue), você descreve cor em termos humanos:

• Hue (matiz): a posição no círculo cromático, de 0° a 360°. Vermelho = 0°, verde = 120°, azul = 240°.
• Saturation (saturação): quão “viva” é a cor. 0% = cinza, 100% = cor pura.
• Lightness (luminosidade): quão clara ou escura. 0% = preto, 100% = branco.

Com HSL, você controla cada dimensão independentemente. E é aí que entra a construção da paleta.

Passo 1: Distribuir Matizes no Círculo Cromático

A newsletter tem 8 tipos de seção, cada uma com cor própria. Pra que todas “pertençam” visualmente ao mesmo projeto, os matizes são distribuídos uniformemente no círculo de 360°:

Oito matizes espaçados ao redor do círculo. Não é aleatório — é a mesma lógica de uma paleta policromática em teoria das cores. Quando os matizes são equidistantes, o olho humano percebe harmonia mesmo com cores completamente diferentes. É o mesmo princípio que artistas usam com um círculo cromático de 12 cores desde o século XVIII.

Passo 2: Fixar Saturação e Luminosidade por Camada

Aqui está o truque que faz tudo funcionar junto. Cada “camada” visual (background, texto, borda) tem saturação e luminosidade fixas — só o matiz muda:

Tema claro:

• Backgrounds: ~92-95% luminosidade, saturação moderada. Com luminosidade tão alta, mesmo saturações diferentes resultam em cores pastel com peso visual parecido — nenhuma seção “grita” mais que outra.
• Texto: ~15-20% luminosidade. Escuro o suficiente pra garantir ratio de contraste >7:1 contra o background claro (acima do mínimo WCAG AAA de 7:1).
• Bordas: ~45-55% luminosidade. O acento cromático — visível mas não dominante.

Tema escuro:

• Backgrounds: ~10-12% luminosidade. Profundidade uniforme — todas as seções têm a mesma “escuridão”.
• Texto: ~80-85% luminosidade. Claro o suficiente pra ratio de contraste >6:1 no fundo escuro.
• Bordas: mesma faixa de luminosidade que no tema claro — funcionam como acento nos dois contextos.

Na prática, isso significa que gerar a variante dark de qualquer cor é mecânico: mantém o matiz, inverte a luminosidade. Background que era 94% vira 11%. Texto que era 18% vira 83%. Não é design — é aritmética.

Passo 3: Verificar Contraste (WCAG)

Cores bonitas que ninguém consegue ler não servem pra nada. O padrão WCAG (Web Content Accessibility Guidelines) define ratios mínimos:

• AA: 4.5:1 pra texto normal, 3:1 pra texto grande
• AAA: 7:1 pra texto normal, 4.5:1 pra texto grande

Os backgrounds claros com ~95% luminosidade contra texto com ~20% luminosidade dão ratio >7:1 — WCAG AAA. Os backgrounds escuros (~11%) contra texto claro (~82%) dão >6:1 — confortavelmente WCAG AA, próximo de AAA.

Isso não é por altruísmo. Email com baixo contraste é mais difícil de ler, gera menos engajamento, e em casos extremos é sinalizado por filtros de acessibilidade de email clients.

O Resultado

Quando você abre a newsletter e vê a seção do Hacker News (roxa), seguida pelo YouTube (vermelha), seguida pelo Anime (azul) — elas parecem “do mesmo projeto” apesar de cores completamente diferentes. Isso é o HSL trabalhando: matizes diferentes, mesma saturação, mesma luminosidade. O olho percebe coerência sem saber explicar por quê.

E a melhor parte: adicionar uma seção nova é trivial. Escolhe um matiz que não está ocupado no círculo, aplica as mesmas regras de saturação/luminosidade por camada, e a nova seção automaticamente “pertence” ao design existente.

# O comentário no código resume as regras:
# - Hues evenly spaced: blue 210, green 140, sepia 35, amber 45, royal 225, purple 270, red 0, teal 180
# - Light backgrounds: ~95% lightness, ~25% saturation
# - Light text: ~20% lightness (>7:1 contrast ratio on light bg)
# - Dark backgrounds: ~10-12% lightness
# - Dark text: ~80-85% lightness (>6:1 contrast ratio on dark bg)
# - Borders: ~45-55% lightness

Seis regras. Oito matizes. Dois temas. 100% determinístico. Nenhuma decisão subjetiva de “acho que esse azul fica bonito” — é sistema de design derivado de propriedades geométricas do espaço de cor HSL.

HTML Bem Formado: O Filtro de Spam que Ninguém Te Conta

Tudo que descrevi acima — tables, CSS inline, font stacks — resolve o problema de renderização. Mas tem um segundo motivo pra seguir essas regras que a maioria dos desenvolvedores ignora: provedores de email analisam a qualidade do seu HTML pra decidir se é spam.

Gmail, Outlook, Yahoo — todos passam o HTML do seu email por heurísticas antes de mostrar pro usuário. HTML malformado é um dos sinais clássicos de spam. Faz sentido: spammers não testam templates. Eles cospem HTML quebrado gerado por ferramentas de mass-mailing baratas. Se seu email parece output de spammer, vai ser tratado como spam.

Os sinais que disparam filtros:

1. Tags não fechadas ou mal aninhadas. Um <div> que abre e nunca fecha, ou um </td> antes do </tr>, é flag imediata. Provedores esperam HTML que parse sem erros — não HTML “que o browser conserta”.
2. Ratio imagem/texto desbalanceado. Email que é basicamente uma imagem gigante com pouco texto? Spam clássico. Provedores querem ver texto real — não texto dentro de imagens. A regra de ouro é manter pelo menos 60% texto, 40% imagem.
3. Atributo alt ausente em imagens. Além de acessibilidade, alt vazio ou ausente é sinal de descuido — e descuido correlaciona com spam. Toda <img> precisa de alt descritivo.
4. CSS que esconde conteúdo. display: none, visibility: hidden, font-size: 0, texto da mesma cor que o background — são técnicas clássicas de keyword stuffing. Mesmo que você use legitimamente pra responsive email, o filtro não sabe a diferença.
5. HTML excessivamente pesado. Email com 500KB de HTML levanta suspeita. Mantenha leve — o conteúdo real raramente precisa de mais de 100KB de HTML.
6. Links com texto que não corresponde ao href. <a href="https://site-real.com">https://site-falso.com</a> é phishing textbook. Mesmo discrepâncias sutis (domínio no texto diferente do domínio no link) são penalizadas.

O ponto que conecta tudo: as mesmas práticas que fazem email renderizar corretamente no Outlook são as que mantêm seus emails fora do spam. Tables com estrutura limpa? HTML bem formado. CSS inline em cada elemento ao invés de hacks com <style>? Sem CSS escondido. Imagens com dimensões explícitas e alt text? Conteúdo legítimo.

Não é coincidência. Provedores de email calibraram seus filtros observando o que spammers fazem — e spammers fazem exatamente o oposto de HTML email bem construído. Quando você segue as melhores práticas de compatibilidade, de graça você também está sinalizando legitimidade pros filtros de spam.

A lição prática: trate o HTML do seu email como se fosse um documento XML. Valide, teste, e garanta que todo tag abre e fecha na ordem certa. Use ferramentas como Email on Acid ou Litmus pra testar em múltiplos clients — eles também reportam problemas de spam scoring. E resista à tentação de copiar templates prontos da internet sem validar — muitos são um desastre de HTML malformado que passa despercebido no Gmail mas faz o Outlook ter um ataque cardíaco e faz o filtro de spam do Yahoo te marcar como suspeito.

RSS Feeds: O Frontend Esquecido

Um detalhe que desenvolvedores web ignoram: RSS é um frontend. Podcasts no Spotify e Apple Podcasts são consumidos via RSS. O feed precisa de:

• XML válido (parsers de podcast são rígidos)
• Metadata completa (título, descrição, duração, tamanho do arquivo)
• URLs de imagem que realmente funcionam (Spotify valida)
• Cover art com dimensões mínimas (1400×1400 pra Spotify)
• GUIDs únicos por episódio

Hugo gera RSS automaticamente, mas o template padrão não tem os campos que plataformas de podcast exigem. Um template customizado com tags iTunes é necessário:

<itunes:duration>{{ .Params.duration_seconds }}</itunes:duration>
<itunes:image href="{{ .Params.cover_image | absURL }}"/>
<enclosure url="{{ .Params.audio_url }}"
           length="{{ .Params.file_size }}"
           type="audio/mpeg"/>

A Filosofia: Conteúdo Primeiro, Framework Nunca

O padrão que emerge de todo esse setup é: o conteúdo é soberano. Markdown com frontmatter YAML é o formato universal. Cada frontend (blog, email, RSS, podcast player) consome o mesmo conteúdo e renderiza do seu jeito.

Não existe “componente React que busca dados de uma API”. Existe um arquivo Markdown que é lido por quem precisar. Isso é radicalmente simples — e radicalmente poderoso. Trocar o blog engine de Hugo pra outro? Muda os templates, o conteúdo fica igual. Trocar o provedor de email de SES pra Sendgrid? Muda o mailer, os templates ficam iguais.

É o Unix philosophy aplicado a frontend: cada ferramenta faz uma coisa bem feita, conectadas por um formato universal (Markdown + YAML).

Conclusão

Você não precisa de React pra ter frontend moderno. Tailwind v4 te dá design system com constraints, dark mode nativo, e zero JavaScript. Hugo te dá um blog absurdamente rápido com templates flexíveis. ERB com CSS inline te dá emails que funcionam em qualquer client.

O investimento real é entender as restrições de cada plataforma e construir pipelines de renderização pra cada uma. Não é aprender o framework da moda que vai morrer em 18 meses.

No final das contas, a melhor abstração de frontend é nenhuma. HTML, CSS, e Markdown. Simples, debugável, e vai funcionar daqui a 10 anos.

Descrição no YouTube

Este episódio vai testar a paciência de vocês. Desta vez quero explorar um pouco os diversos assuntos que são associados com a tal carreira de “Front-End” no mundo de desenvolvimento Web.

Se já começaram a estudar o assunto devem ter visto que existe uma infinidade de sopas de letrinhas, coisas como SASS, CSS, React, Vue, e muito mais. Por que existem tantas letrinhas assim? Quais escolher?

Obs: eu fico falando “Webpacker” o tempo todo mas na verdade é “Webpack” sorry :-)

Links:

• History of Web Fonts: (https://thehistoryoftheweb.com/web-fonts/)

• A brief history of CSS until 2016 (https://www.w3.org/Style/CSS20/history.html)

• Responsive Web Design: Media Queries (http://blog.chrismaxwell.com/responsive-web-design-media-queries)

• Front-End Developer Handbook 2018 (https://frontendmasters.com/books/front-end-handbook/2018/)

• Eloquent JavaScript (https://eloquentjavascript.net/)

• Mastering Regular Expressions (http://shop.oreilly.com/product/9780596528126.do)

• Juliana Negreiros (https://github.com/juunegreiros/utilities) - página cheia de boas referências.

Script

Olá pessoal, Fabio Akita

Estamos no quarto episódio desta série, semana passada começamos com algumas coisas básicas do Developer Roadmap onde eu discuti porque saber Git e aprender Linux de verdade são as duas coisas mais importantes pra começar. Mas eu me lembrei no caso de Linux que eu disse que tinha duas formas, você aprender do jeito difícil que é instalar e configurar uma distro como Arch Linux num ambiente virtualizado como Virtualbox. Ou aprender do jeito ultra difícil, que eu esqueci de mencionar no final do episódio, e que é instalando direto como sistema operacional principal da sua máquina! Sim, vai ser bem difícil se for sua única máquina e você só tiver acesso ao site do Arch Wiki pelo celular. Mas vai por mim, hoje tá bem fácil porque a gente fazia essas coisas nos anos 90 só confiando que tinha tudo certo nos disquetes e sem internet pra baixar alguma coisa caso tivesse esquecido, e Wikis sequer haviam sido inventados, aliás, Google não tinha sido inventado. Então considere que hoje tá muito fácil e instale Arch Linux como seu sistema operacional principal. Se conseguir fazer isso sozinho, você está no caminho certo.

No episódio de HOJE vamos falar sobre um dos assuntos mais desnecessariamente complicados da carreira de programador Web, o guarda-chuva que chamamos de Front-end. Porém, em vez de seguir o Roadmap, neste episódio vou fazer uma longa tangente hoje. Aliás, vai ser um dos meus episódios mais longos, então não deixem de dizer nos comentários se preferiam que eu tivesse quebrado esse episódio em duas partes ou se nesses casos está ok ser longo mesmo.

Se você está entrando hoje no mercado de front-ends vai esbarrar em dezenas de letrinhas, coisas como Sass, Vue, React, Angular, Ember, Bootstrap, Npm, Yarn, Webpacker, Flow, TypeScript, Dart, BEM, SMACSS, PWAs, SPAs, RAIL, e por aí vai. Eu entendo porque alguém que está iniciando os estudos agora vai ficar extremamente confuso sobre por onde começar. E como sempre o melhor jeito de entender como começar é do começo.

(…)

A tangente que eu me referi é que eu vou fazer o contrário da maioria dos tutoriais ou guias que falam de front-end. Em vez de dizer logo de cara o que eu acho que você devia estudar, eu pessoalmente acho mais fácil explicar porque aquelas sopas de letrinhas existem e daí vocês mesmos podem começar a chegar em algumas conclusões. A história do front-end é a própria história da Web e algumas coisas que você tem hoje só fazem sentido no contexto dos anos 90 ou dos anos 2000, sem saber disso você meio que tem que engolir como as coisas são sem entender porque. No fim do episódio eu espero que vocês tenham muito mais perguntas do que neste momento.

A estrutura mais simples que você precisa ter na cabeça é a seguinte: quando você abre um navegador e digita um endereço tipo https : // meusite.com.br ele vai fazer dezenas de operações mas no mínimo ele precisa primeiro traduzir o domínio num endereço IP, e quem faz esse trabalho inicial é o tal servidor de DNS ou Domain Name Server que você já deve ter ouvido pelo menos o nome, pra onde a configuração de rede do seu computador está apontando. DNS é como se fosse uma lista telefônica, traduzindo nomes pra números.

Agora é tarefa da tal rede, roteadores, provedores, conectar seu navegador a um servidor. A internet funciona porque todas as pontas falam o mesmo formato de mensagens e trafegam de uma determinada maneira, que é o que chamamos de protocolo, e o padrão que nos interessa é o famoso TCP/IP. Por agora só entenda que com o endereço ele encontra o servidor certo no mundo. Bem em resumo estamos falando de um programa ou aplicação que é um cliente de TCP ligando a um servidor TCP, que fica escutando no que chamamos de uma porta. Todo servidor web que serve páginas HTML é um programa que quando você carrega ele se liga a uma porta, que é representado por um número que vai de 1 a mais de 65 mil.

A convenção é que um servidor Web ouve conexões na porta 80. Um servidor SSH ouve na porta 22. Um servidor Web também escuta na na porta 443 quando recebe requisição de conexão segura via HTTPS, e muitos servidores de desenvolvimento como Node.js, Rails ou Java ouvem em portas como 3000 ou 5000 ou 8080, respectivamente. Não há nada de mágico nesses números, são arbitrários e foram escolhidos anos atrás e por isso é só uma convenção, mas na prática, qualquer número de porta serve, contanto que exista alguma coisa “escutando” nessa porta.

Nesse minuto de explicação eu simplifiquei bastante. Na faculdade você faria exercícios simples de escrever um programinha que escuta numa porta e outro que conecta nessa porta. É assim que começa a nascer a semente de um servidor web e de um navegador. Agora o que é o servidor Web mais simples de todos? Ele simplesmente lê um arquivo da máquina e serve esse arquivo. O endereço completo que você digita no navegador se chama URL ou Universal Resource Locator que é composto pelo protocolo, pelo domínio e pelo caminho de um arquivo, no caso mais simples. Então antigamente você veria endereços como esse http://sitedafaculdade.edu/~jose/arquivo.html

E esse til jose, se você estudou Linux como eu disse no episódio anterior, vai saber que é um atalho pro diretório /home/jose. E é assim que você faz o servidor web mais simples de todos e, como hoje em dia sabemos, o mais bugado em termos de segurança porque se ele traduz direto da URL pra um caminho de arquivos no seu sistema operacional, sem nenhuma checagem, você poderia ficar tentando achar maneiras de vasculhar todos os arquivos do usuário, mesmo os que ele achou que não seriam servidos publicamente. E fazíamos isso mesmo antigamente pra achar brechas.

E quando o navegador, que é um exemplo de um programa que é cliente de TCP, recebe esse arquivo.html agora ele traduz as marcações pra elementos visuais. E como existe o elemento que chamamos de LINK que é o onde “A” significa anchor ou âncora e href é hypertext reference, nasce o conceito de hipertexto onde um texto possui links pra outros textos. No começo ninguém estava interessado em visual, simplesmente em disponibilizar textos linkando com outros textos. E assim nasce a tal World Wide Web ou WWW. É um conceito que nasceria naturalmente dados esses elementos que eu mencionei até agora, era inevitável.

Nada foi mais disruptivo no mundo de desenvolvimento de stylesheets do que o advento do SASS em 2007. Sim, faz 8 anos, e sim, estou exagerando, CSS 3 foi bem mais disruptivo, mas vocês entenderam! A menos que eu esteja enganado foi quando se entendeu também que era possível transformar uma linguagem tosca (CSS 2) em algo bem mais trabalhável, foi o início do uso do conceito de transpilers para Web.

Por todos esses anos o Sass, escrito em Ruby, serviu seu propósito muito bem, mas sabemos que ele é um dos calcanhares de aquiles quando fazemos deployment de projetos Ruby. Em paralelo se iniciou uma reimplementação em C (libsass) para tornar o Sass não dependente de Ruby (agnóstico de linguagem) e com performance mais adequada.

O pessoal de Node e outras linguagens já usa o libsass em pacotes como o node-sass. É hora do filho pródigo retornar à sua casa. Para usar em projetos Ruby on Rails precisamos fazer o seguinte:

Atualizar o arquivo Gemfile e trocar sass-rails por sassc-rails:

gem 'sassc-rails'

Rodar o bom e velho bundle install e adicionar um arquivo chamado .buildpacks à raiz do seu projeto:

https://github.com/djmattyg007/heroku-buildpack-sassc.git#1.1.0
https://github.com/heroku/heroku-buildpack-ruby.git#v137

Então execute a seguinte linha de comando:

heroku config:add BUILDPACK_URL=https://github.com/ddollar/heroku-buildpack-multi.git

O conceito é simples: todo container do Heroku é configurado através de uma buildpack (que controla os fluxos de compilação e lançamento). O Heroku escolhe o padrão correto para sua aplicação. O que fizemos acima foi substituir por um Custom Buildpack. Uma das alternativas seria fazer um fork do buildpack de Ruby e adicionar o libsass. Por outro lado já existe um buildpack só com o libsass e podemos criar um slug com duas buildpacks usando a buildpack “heroku-buildpack-multi” criada pelo @ddollar.

Ou digamos que gostaríamos de rodar uma aplicação Ruby mas queremos ter dependências de Node ou Python para executar alguma coisa específica durante o deployment, basta adicionar outras buildpacks ao arquivo .buildpacks.

Enfim, com isso vamos conseguir reduzir consideravelmente (depende da quantidade de stylesheets que você tem no seu projeto) o tempo de cada deployment.

Asset Management é um problema praticamente todo resolvido no mundo Rails desde Fevereiro de 2009 (nós basicamente criamos o conceito). Mesmo assim, ainda temos que ouvir afirmações sem sentido como “precisamos consertar ou substituir o Asset Pipeline” e então nascem coisas como “requirejs-rails” ou receitas de como desabilitar o Sprockets e usar outras coisas. Em resumo: não faça isso.

Até eu fico sem paciência para participar dessas discussões porque, no final do dia, o que precisamos é da solução mais simples que funciona e podemos confiar. E sem mais delongas eu elejo a combinação ModuleJS e Rails-Assets como as melhores opções.

Antes de continuar vou assumir que você pelo menos leu (ou já conhece) os seguintes assuntos:

• Asset Pipeline para Iniciantes
• Asset Pipeline para Iniciantes - Parte 2
• Rails Assets

Para ilustrar a solução vamos direto a um pequeno exemplo. Se for algo pequeno, podemos ficar tentados a colocar tudo no app/assets/application.js, como por exemplo:

Foo = {
  hello: function() {
    return "Hello";
  },

  world: function() {
    return "World";
  }
}

Bar = {
  helloWorld: function() {
    return Foo.hello() + " " + Foo.world();
  }
}

$(function() {
  $('body').append('<p>' + Bar.helloWorld() + '</p>');
})

Isso vai simplesmente adicionar um parágrafo escrito “Hello World” na página. A idéia é um exemplo bem trivial para que a técnica fique clara, mas obviamente imagine isso em algo mais complicado.

A primeira coisa que gostaríamos de fazer é separar esse código. Talvez quebrar em arquivos como app/assets/javascripts/foo.js e app/assets/javascripts/bar.js. Então vamos direto ao assunto e adicionar o ModuleJS diretamenta à nossa Gemfile:

# Gemfile
source 'https://rails-assets.org'
# ...
gem 'rails-assets-modulejs'

Depois de instalar com o bom e velho bundle install. Modificamos o app/assets/javascripts/application.js para carregar a dependência:

//= require jquery
//= require jquery_ujs
//= require modulejs
//= require_tree .

Isso foi o que eu já expliquei no meu post mais antigo sobre Rails Assets. Se a biblioteca que você quer tem um pacote Bower, ele pode ser automaticamente encapsulado numa gem de Rails Engine como uma gem feita manualmente. E se não tiver como pacote Bower aí não tem jeito: baixe os arquivos e jogue num diretório em vendor/assets para mantê-la estática dentro do projeto, mas o ideal é que você não deixe bibliotecas javascript vendorizados.

Para começar a refatoração do javascript acima, vamos começar quebrando os objetos ‘Foo’ e ‘Bar’ em dois arquivos:

// app/assets/javascripts/foo.js
modulejs.define( 'foo', function() {
  return {
    hello: function() {
      return "Hello";
    },

    world: function() {
      return "World";
    }
  }
})

// app/assets/javascripts/bar.js
modulejs.define( 'bar', [ 'foo' ], function(Foo) {
  return {
    helloWorld: function() {
      return Foo.hello() + " " + Foo.world();
    }
  }
})

Veja que não precisamos mais das constantes ‘Foo’ e ‘Bar’, apenas devolver o corpo do hash com as funções. No módulo ‘bar’, declaramos que precisamos do módulo ‘foo’ (em um array) e passamos como parâmetro do construtor com o nome antigo da constante ‘Foo’, daí internamente o código se mantém exatamente o mesmo. E já que estamos modularizando, vamos adicionar um módulo que encapsula a chamada principal:

// app/assets/javascripts/main.js
modulejs.define( 'main', ['bar', 'jquery'], function(Bar, $) {
  return {
    start: function() {
      $('body').append('<p>' + Bar.helloWorld() + '</p>');
    }
  }
})

Como pode ver acima, o módulo ‘main’ vai depender do ‘bar’ (definido em ‘bar.js’) e também de um ‘jquery’ que ainda não existe, então vamos criar um genérico modules.js para encapsular o jQuery assim:

// app/assets/javascripts/modules.js
modulejs.define( 'jquery', function() {
  return jQuery;
});

Veja que podemos fazer a mesma coisa para qualquer outra biblioteca. Damos um nome em string, no caso ‘jquery’, que o ModuleJS vai conseguir encontrar depois e retornamos a classe principal, só isso.

Para finalizar no arquivo original application.js chamamos esse novo ‘main’ assim:

$(function() {
  var app = modulejs.require('main');
  app.start();
})

Pronto! Tudo isolado e com as dependências todas controladas. A grande vantagem de fazer desta forma é que no cabeçalho do application.js podemos continuar declarando as dependências com o require_tree . pois não importa a ordem dos arquivos, apenas a chamada principal do módulo ‘main’.

Pronto, não precisamos de RequireJS, podemos continuar usando o Asset Pipeline que vai gerar os arquivos minificados como o Rails sempre fez e com o mínimo de dependências que podem causar conflitos difíceis de rastrear depois. Vá adicionando seus pacotes preferidos de Bower diretamente na Gemfile e continue usando apenas um sistema de gerenciamento de dependência que sabemos que funciona: Bundler.

Do ponto de vista puramente técnico é muito simples entender o que é um “Web Component”. Ele é o conjunto de 4 tecnologias de navegadores web.

• Custom Elements
• HTML Imports
• Templates
• Shadow DOM

Colocando em ordem de importância, eu resumiria da seguinte forma:

• Custom Elements - permite criar tags diferente dos canônicos como “body”, “input” e evitar o classes-hell ou div-hell onde tudo é um punhado de divs dentro de divs criando os horrendos macarrões de tags. A idéia é encapsular tudo dentro de tags simples e mais fáceis de manusear.
• Shadow DOM - para o fator encapsulamento, precisamos primeiro conseguir eliminar o sangramento de estilos e comportamentos por tudo que existe numa página. Shadow DOM permite criar trechos de nós de elementos de DOM que são independentes e isolados entre si, onde o estilo de um trecho não interfere com outro. Somente o Chrome e Firefox mais novos suportam isso. WebKit/Safari deixou de suportar a implementação incompleta que tinham (mas talvez voltem) e o IE, para variar, nunca nem tentou implementar isso. Para funcionar na maioria dos navegadores existem projetos como o Polymer/Platform e X-Tag para servir como “polyfill” para navegadores legados.
• Templates - como o nome diz, para criar componentes dinâmicos, é importante ter trechos de DOM inertes, diferentes de somente uma string, para conseguir manipular e instanciar conforme necessário. Por exemplo, linhas de uma tabela dinâmica. Existem várias bibliotecas de templates, como Mustache, mas para Web Components funcionar, era importante ter um padrão.
• HTML Imports - e uma vez tendo um trecho de DOM isolado, com estilos e comportamentos independentes de outros componentes, agora precisamos empacotar isso. E para isso servem esses imports que basicamente é um arquivo HTML que declara os arquivos CSS e Javascript que ele depende, e o HTML Import sabe como carregar tudo de uma vez. Aqui fica uma das minhas maiores preocupações - que vou tentar explicar mais para o fim.

Existem já dezenas de artigos e documentação de como é um Web Component, como construir um do zero e onde encontrar componentes. Não é foco deste artigo explicar os detalhes técnicos de um Web Component.

Por si só, devo dizer que são tecnologias interessantes que todo bom nerd gosta de brincar. Porém não deveria ser novidade que só porque alguma coisa é tecnicamente interessante, por si só, não garante absolutamente nada. A principal pergunta é: “o que eu ganho com isso?” Antes de responder a essa pergunta, toda tecnologia é somente uma solução procurando um problema.

Infelizmente nem eu, nem ninguém, temos como prever o futuro, então neste artigo quero avaliar qualquer proposta baseado no que temos no presente, relembrar o passado e o que isso pode representar no curto prazo. O longo prazo deixo para os profetas e quem gosta de apostar em loteria. Então vou tentar quebrar alguns dos grandes problemas do desenvolvimento Web que temos hoje.

O Problema do HTML/CSS macarrônicos

A forma de desenhar uma página Web mudou bastante nos últimos 20 anos. As tecnologias básicas ainda são as mesmas: HTML 5 para estruturar um documento. CSS 3 para estilizar os elementos nesse documento. Javascript para adicionar comportamento. Acho que a esta altura todos já sabemos que devemos separar estilização/apresentação da estrutura e conteúdo. Também sabemos que não devemos nem usar tabelas para tudo e nem usar divs com float para tudo.

Passamos pela era da Web Semântica e Web Responsiva. Quando os navegadores implementaram tables no Netscape Navigator 1.1 e IE 2.0 em 1995 e 1996 ainda não se falava em acessibilidade e semântica apareceriam a partir de 1997 com o HTML 3.2. Estávamos criando a Web e usando ao mesmo tempo, como hoje as implementações apareciam antes de se ter uma especificação mais geral. A W3C é lenta não é de hoje.

Acho que a evangelização de Responsive Web também merece um “rant” mas fica para outro artigo.

Mesmo assim ainda somos reféns de códigos como deste exemplo de tabs do framework Bootstrap:

<ul class="nav nav-tabs" role="tablist">
  <li class="active"><a href="#">Home</a></li>
  <li><a href="#">Profile</a></li>
  <li><a href="#">Messages</a></li>
</ul>

E vejamos um trecho para tabs mas usando um web component do novíssimo Polymer/Paper:

<paper-tabs selected="0" selectedindex="0" id="paper_tabs">
  <paper-tab id="tab_home" active>Home</paper-tab>
  <paper-tab id="tab_profile">Profile</paper-tab>
  <paper-tab id="tab_messages">Messages</paper-tab>
</paper-tabs>

Esse é o resultado da primeira tecnologia de Web Components: Custom Elements. De fato isso acrescenta uma clareza enorme. No primeiro exemplo o que temos é:

"Uma lista não ordenada com classes nav e nav-tags e dentro delas itens de lista."

Se você souber o que são as classes “nav” e “nav-tabs” vamos saber que se trata de uma lista de tabs. No caso do exemplo do Paper podemos ler claramente:

"Um conjunto de tabs, implementado com Paper."

Isto é um exemplo pequeno mas imaginando como páginas Web são complexas, tirar a ambiguidade de para que servem cada conjunto de tags numa árvore infinita de tags é muito importante. Perdemos muito tempo em tentativa e erro de retirar pedaços e tentando inserir outros pedaços no meio da árvore de HTML e decifrando nomes de classes CSS.

Na prática, sem ter Custom Elements para tornar as tags mais amigáveis, outra forma é encapsular a inicialização usando um marcador simples numa tag HTML (como uma classe CSS ou ID) e ativar o resto via Javascript. É como todo plugin JQuery funciona. Um exemplo simples é como encapsulamos o Google Maps com o plugin Gmap3 do JQuery:

<div id="my-map"></div>
<script>
$("#my-map").gmap3({
    map:{
      address:"Cupertino, CA",
      options:{
        zoom:4,
        mapTypeId: google.maps.MapTypeId.SATELLITE,
        mapTypeControl: true,
        mapTypeControlOptions: {
          style: google.maps.MapTypeControlStyle.DROPDOWN_MENU
        },
        navigationControl: true,
        scrollwheel: true,
        streetViewControl: true
      }
    }
  });
</script>

E outro exemplo com a alternativa com o Web Component Google-Map (lembrando que esta versão é mais simples do que o plugin Gmap3):

<google-map latitude="37.77493" longitude="-122.41942" fitToMarkers>
  <google-map-marker latitude="37.779" longitude="-122.3892"
      draggable="true" title="Go Giants!"></google-map-marker>
  <google-map-marker latitude="37.777" longitude="-122.38911"></google-map-marker>
</google-map>

Estamos movendo parte do que faríamos via Javascript de volta ao HTML. Mas somente isso não é suficiente e já sabemos disso. A tecnologia de “Cascading Style Sheet versão 3”, comumente conhecida como CSS 3 até hoje permanece arcaica. Felizmente inventamos uma forma de tornar os malditos macarrões de CSS gerenciáveis. Agradecimentos são devidos à Hampton Catlin, um grande rubista que - em 2007 - inventou a linguagem de script SASS, que é um “super-set” de CSS e gera CSS 3, adicionando variáveis, nesting, partials, import, mixins, extensão/herança, operadores.

SASS foi a primeira linguagem de pré-processamento que acelerou a idéia da possibilidade de novas formas de gerenciar assets Web como CSS. Depois dele vieram LESS e toda uma gama de frameworks e bibliotecas como Singularity, Bourbon Neat, Susy, Zurb Foundation, Compass. Foi uma pena terem escrito o Twitter Bootstrap original em LESS em vez de SASS, mas acho que o projeto LibSass (SASS escrito em C) ainda não existia. Mas pelo próprio exemplo acima fica claro porque você deveria escolher outro framework em vez de Bootstrap.

Porém SASS não foi a primeira vez que alguém criou um pré-processador para a Web. Provavelmente a primeira foi a Wiki Markup implementada junto com o primeiro Wiki, o WikiWikiWeb de Ward Cunningham em 1995. Depois disso ainda tivemos o MediaWiki da Wikipedia até chegarmos atualmente a pré-processadores de HTML como Markdown, que praticamente usamos sem pensar em comentários de Github.

No mundo Rails já tentamos melhorar o HTML também, com pré-processadores como o HAML (do próprio Catlin) ou outros mais recentes como Slim. Mas nesse caso ainda não estamos melhorando o HTML tão drasticamente como SASS faz com CSS, por isso ainda não há uma boa alternativa e Custom Elements é o mais próximo de uma boa alternativa neste momento.

Estou trazendo estes pontos porque Web Components não declara nenhum pré-processador de CSS como padrão, por convenção. Assumimos CSS 3 puro. Não é um problema, mas se estamos falando de reuso, atualmente a melhor forma é usando mixins de SASS encapsuladas em bibliotecas como Compass ou Bourbon.

O Problema do Sangramento de Estilos e Comportamentos

Este é um dos aspectos mais irritantes de desenvolvimento front-end depois da compatibilidade de navegadores: como organizar as milhares de linhas de CSS? (seja ele puro, escrito em SASS ou LESS).

Antes de continuar, se nunca ouviu falar de CSS Anti-patterns, leia a respeito antes. E também que todos já pelo menos ouviram falar nas diversas metodologias para organizar CSS (OOCss , SMACSS, BEM). Eu honestamente não usaria ACSS e me foram dados bons argumentos para preferir BEM.

Essa introdução foi somente porque também não sou ainda um bom desenvolvedor front-end mas até aqui é o mínimo para começar. Vamos assumir que já passamos desses pontos também. Meu raciocínio começa pelo seguinte caso de uso: “quero criar CSS para um elemento visual, composto de diversos tags, e que não deve se deformar aleatoriamente por estilo de fora e nem deformar outros elementos ao redor.” Seria o caso de um Widget ou o que poderia ser um “Web Component”, ao pé-da-letra.

Passamos anos fazendo Widgets. As duas grandes formas são usando um iframe com postMessage() ou zerar os estilos de um trecho do DOM com Cleanslate e garantir que você está isolando seu CSS e Javascript usando namespaces e torcendo pra acidentalmente não sobrar nada global no meio do caminho ou outro desenvolvedor sobrescrever o que você fez.

Isso mudou em 2012 quando surgiu a implementação de Shadow DOM. Os novos elementos do HTML 5 como “audio” ou “video” ou “range” foram criados dessa forma em muitos navegadores. Em resumo mencionamos que uma página Web é uma árvore de tags, essa árvore que chamamos de Document Object Model ou “DOM”. Imagine se pudéssemos isolar um trecho de nós, uma sub-árvore, que não fosse influenciada pelos estilos externos e cujos estilos internos não “vazassem” para fora. Para isso criamos um novo elemento, um “ShadowRoot” que delimita uma sub-árvore isolada e independente e que, para todos os propósitos, não aparece no DOM principal, mas tem sua própria raíz de DOM isolada. Esse é o conceito.

No momento deste artigo, somente o Chrome a partir da versão 25 (hoje no 35), o Firefox a partir da versão 31 (hoje no 30) e Ópera versão 15 (hoje no 22) suportam Shadow DOM. A Apple retirou o suporte do WebKit em fevereiro. A Microsoft sequer considerou começar a implementar ainda.

Shadow DOM não é obrigatório para criar Custom Elements, mas é um recurso interessante e importante para atingir o objetivo de componentes Web independentes e isolados que não precisem recorrer a recursos como reiniciar o CSS de uma sub-árvore com artifícios como Cleanslate. De qualquer forma, seja via as convenções listadas acima e outras, ou seja via Shadow DOM, hoje temos como criar um nível razoável de isolamento e facilidade de manutenção. O problema é que isso não é inerente a HTML 5 e CSS 3, mas uma camada acima que não tem um consenso geral ainda.

O Problema de Reusar Elementos

Num mundo onde fazíamos praticamente tudo via server-side, esse era um problema praticamente resolvido. Seja com Rails e ERB/HAML/Slim, seja com templates de Django, seja com Blade em Laravel, seja com Razor em Asp.Net. Porém hoje temos aplicações mistas, onde deferimos muita lógica para a camada do navegador usando mais Javascript. Em vez de devolver pedaços prontos de HTML, agora devolvemos dados semi-estruturados em JSON e deixamos o Javascript criar os elementos no DOM.

Significa que no navegador temos um conjunto de dados e precisamos de uma forma de declarar os elementos de DOM onde vamos aplicar esses dados antes de instanciar o trecho no DOM. Do mundo Ruby surgiu uma das formas mais populares, Mustache, criado pelo co-fundador do Github, Chris Wanstrath. Depois outro rubista, Yehuda Katz, trouxe outra alternativa com o Handlebars. A idéia geral é criar um elemento “script” e dentro dela colocar templates usando a notação do Mustache. Então um Javascript pode pegar o conteúdo string dessa tag script e criar o elemento no DOM depois de mesclar com os dados que quiser.

Está claro que estamos fazendo uma “gambiarra” elegante. A parte não tão elegante é ter que injetar HTML usando “innerHTML”, mas funciona muito bem. O outro problema é controlar manualmente coisas como imagens e javascripts que um elemento pode precisar mas antes dele ser usado, ou seja, talvez sem necessidade. Para isso precisamos controlar via Javascript.

Na definição de Web Components foi criado um novo elemento para resolver alguns desses problemas, o “template”. Sua definição é bem recente, de fevereiro de 2014. Serve basicamente o mesmo propósito de colocar um template dentro de uma tag “script” mas em vez de ser somente um string injetável ele realmente é uma sub-árvore de DOM “inerte”, que podemos manipular os nós via Javascript antes de ativá-lo ao inserir no DOM principal.

Por não ser mais um trecho de texto, perdemos a função do Mustache e do Handlebar de facilmente mesclar dados e inclusive ter alguma lógica como condicionais e loops. Em vez disso precisamos manipular os nós via javascript, fazendo coisas como:

t.content.querySelector('img').src = 'logo.png';

Em vez de ter:

<img src="{{minha-imagem}}" alt="great image">

Neste caso de templates eu diria que demos 2 passos pra trás e 1 para frente. Provavelmente dentro de um “HTML template” vamos precisar ter um Mustache para completar o processo? Admito que não acompanho a especificação mas pelo pouco que vi até agora não me parece que a especificação W3C de HTML template resolve o problema que bibliotecas como Mustache, Handlebars ou HTMLBars resolvem hoje.

E não estou nem mencionando sobre Binding. Pelo que entendi isso não está na especificação, mas implementado em projetos como o Google MDV que agora está integrado ao Data Binding e Event Mapping do Polymer como TemplateBinding.

O Problema de Reusar “Componentes”

Definindo “Web Components” como, um conjunto de HTML, CSS, Javascript que funciona em independência e isolamento, finalmente sobra o problema de “empacotar” esse conjunto. E agora entra a nova especificação de HTML Imports de Julho de 2014.

Na prática, um HTML Import é nada mais do que um arquivo HTML “normal” com links para outros arquivos como stylesheets, imagens, javascripts e outros assets. Novamente, não vou descrever todos os detalhes e para aprender mais leia o artigo Why imports?.

Atualmente, se precisamos usar algum conjunto desses, como um componente de Bootstrap, por exemplo, precisamos manualmente linkar para os stylesheets na ordem correta e fazer algo como:

<head>
  <link rel="stylesheet" href="bootstrap.css">
  <link rel="stylesheet" href="fonts.css">
  ...
</head>
<body>
  ...
  <script src="jquery.js"></script>
  <script src="bootstrap.js"></script>
  <script src="bootstrap-tooltip.js"></script>
  <script src="bootstrap-dropdown.js"></script>
</body>

Com HTML Imports podemos fazer simplesmente:

<head>
  <link rel="import" href="bootstrap.html">
</head>

O problema imediato de algo como Web Components é que qualquer pequena página pode ter rapidamente dezenas de Imports, cada import requerendo outros arquivos e potencialmente triplicando ou mais a quantidade de chamadas pela rede. Quando tivermos algo melhor como HTTP 2.0 ou outro processo de pipelining e multiplexing como com o protocolo SPDY talvez não tenhamos que nos preocupar com isso, mas com o HTTP 1.1 que temos hoje precisamos ainda pensar em como economizar ao máximo chamadas de rede para pedir assets.

O mundo Rails trouxe pela primeira vez uma implementação de um processo completo e automatizado para concatenar e minificar stylesheets, javascript e sprites com o Sprockets que Sam Stephenson - também criador do Prototype - iniciou em fevereiro de 2009 (obviamente os componentes que podem ser usados pelo Sprockets, como compressor, já existiam). Finalmente o Sprockets foi adicionado ao Rails 3.1 lançado em Agosto de 2011 como “Asset Pipeline”.

Hoje em dia o Sprockets continua sendo uma das opções mais completas e outros frameworks correram para criar suas próprias versões, como o “connect-assets” para Node.js, diversas receitas para Grunt e Gulp) e opções para Grails, Cassette/ASP.NET MVC, Pipeline Django.

No mundo de Web Components foi imediatamente criado o projeto Vulcanize ou no caso do mundo Rails podemos adicionar o processo ao próprio Sprockets com o projeto Emcee, que foi o tema do meu post anterior. A idéia é pegar os HTML imports e concatená-los num único arquivo, incluindo tornar os links para stylesheets e javascripts externos como trechos inline num único HTML. Nem o Vulcanize e nem o Emcee atualmente minificam seus conteúdos, no entanto.

Note que imports é apenas uma parte do problema. Nem vamos entrar no problema de gerenciamento de versões (problema que projetos como Bower, NPM, Bundler no Ruby, PHP Composer, NuGet, Gradle, Pip, etc foram criados para resolver). O que acontece com componentes que dependem de versões específicas de outro componente? E bibliotecas internas como JQuery que um componente pode precisar? Ainda não sei o que acontece nesses casos.

Web Components é uma “Revolução”?

Tudo isso dito, vamos revisar:

• Podemos criar conjuntos de tags isolados com Shadow DOM, com seus próprios estilos e comportamentos que não vazam e não automaticamente herdam estilos e comportamentos do DOM principal, a técnica é usar Shadow DOM (ou uma das formas antigas com Cleanslate, criação de elementos com Javascript, IFrame)
• Podemos definir trechos inertes de HTML que podem ser instanciados via Javascript para dentro do DOM. Com projetos como TemplateBinding recuperamos algo como HTMLBars e podemos mesclar dados com o template. A técnica é usar HTML template e Polymer (ou uma das formas antigas com Mustache, Handlebars, HTMLBars).
• Uma vez definido nosso “widget” ou “componente”, podemos encapsulá-lo dentro de uma embalagem mais amigável usando Custom Elements (ou uma das formas antigas como plugins de JQuery fazem com Javascript para encapsular).
• E uma vez montado o Widget/Componente podemos empacotar tudo num único HTML Import para podermos resusar facilmente dentro de outros HTML (em vez da forma antiga de declarar manualmente os arquivos de dependência)

Vocês devem ter notado que do ponto de vista de um desenvolvedor que apenas consome tais componentes/widgets, o processo em si é uma melhoria mas não é tão diferente quanto utilizar plugins de JQuery. De fato é uma passo adiante, oficializando o que antes era “gambiarra” em alguma coisa um pouco melhor (Custom Elements em vez de Javascript, Shadow DOM em vez de IFrame, HTML Template em vez de string em tag Script).

E aqui vem o maior desafio ao conjunto de tecnologias de Web Components: ele é definitivamente melhor. Só que não é disruptivo. Ao usuário final, o que ele “vê” e “interage” numa página web no navegador será exatamente idêntico. Significa que o usuário final tem muito pouco a se beneficiar da tecnologia. Portanto ele não é o público-alvo.

O público-alvo é o desenvolvedor front-end que, em vez de buscar um plugin JQuery - por exemplo - vai buscar um Web Component e a forma de utilizá-los não será muito diferente. Como ele não tem a motivação de melhorar muita coisa a seu público-alvo, ele tem muito pouco incentivo para mudar sua forma de trabalho.

O raciocínio é simples: quero colocar um Carrossel na minha página. Existem centenas, Jssor Slider, jCarousel, Slick - the last carousel you’ll ever need. E para Web Components? Pelo menos no momento deste artigo só encontrei o Polymer-ui-carousel, que não chega aos pés dos antecessores. Qual você acha que o desenvolvedor front-end vai escolher?

Existem dois repositórios de componentes públicos (aliás, não entendi porque existem dois, um projeto como esse não ganha nada nascendo já fragmentado): o Component Kitchen com cerca de 276 componentes e o Custom Elements com 327 componentes. Como todo repositório inicial, a maioria deles não é de grande serventia. São mais demonstrações e provas de conceito. Sinceramente, alguém se dar ao trabalho para fazer um componente de Pokémon tem que ser só um tech-demo. É inútil. E você pode contar com coisas redundantes e/ou desnecessárias como botões de Facebook, gravatar, botão de Github, coisas que um AddThis já tem resolvido. Claro, não quero ser injusto e dizer que Web Components não tem utilidade só porque a primeira geração de componentes não é interessante. Essas coisas levam tempo para amadurecer, como qualquer tecnologia.

Para que a estratégia funcione ou a tecnologia em si é disruptiva - o que acabamos de ver que não é, é apenas evolutiva -, ou é necessário um pacote completo para ser candidato a “killer-app”. Voltamos ao que disse antes sobre uma solução procurando um problema. Sem um verdadeiro killer-app-blockbuster é muito difícil conseguir tração e coesão de um ecossistema. No caso do Ruby isso foi o Rails. No caso do Go parece que é o Docker. No caso do Node foi o halo-effect do Google Chrome evoluindo o V8.

Para isso o Google criou o Polymer/Paper que define um conjunto coeso e visualmente integrado (via filosofia gráfica e interativa do Material Design que, assumindo que “pegue”, também tem a vantagem de dar ao usuário final um “eye-candy” que justifique sua adoção). É uma proposição “tudo ou nada”, embora você possa pegar pedaços dela, a intenção é fazer aplicações/sites usando inteiramente o Polymer.

O projeto Polymer é ambicioso e somente uma corporação como o Google poderia fazer algo assim tão rápido (dado que metade das especificações de tecnologia de Web Components como HTML Imports e HTML template são deste ano de 2014). Ao contrário do que deveria parecer, a arquitetura não é simples e com o pouco suporte de navegadores a única estratégia é criar Polyfills, implementações (“quasi”-completas) para tudo que navegadores “legados” mas que muita gente usa como IE abaixo de 10, Safari e Mobile Safari. Para isso serve o Polymer/Platform.

Só que já passamos do ponto de somente usar plugins JQuery, agora migramos para a era dos one-page-apps via Javascript que consome endpoints REST que retornam JSON. Estamos falando somente do ponto de vista de componentes, mas uma aplicação é maior do que isso. Para quem vem do mundo ASP.NET MVC, Rails, Django, falamos muito sobre o conceito “Web MVC” (Model-View-Controller) ou mais corretamente, MVC Model-2 da Sun, definido para J2EE.

Muitos nem sabem que usam outro modelo, o MVP (Model-View-Presenter) presente em ASP.NET (antigo), Window.Forms, GWT (Google Web Toolkit, lembram? Também do Google!). E, finalmente, também da Microsoft chegamos ao MVVM (Model View View Model), uma evolução de MVP com MVC2, mais conhecido pelos seus conceitos de Data Binding 2-way de elementos do DOM com models puxados via Javascript. Agora temos a categoria que vocês já devem ter conhecido com Knockout.js, Angular.js, Ember. Estamos falando de mais do que o jeito MVP de arrastar componentes a um canvas e adicionar eventos de callback, mas um framework completo que lida com Models, Views, Rotas.

O Yehuda Katz escreveu sobre integrar o Ember com Web Components em Maio e ele explicita muitos detalhes que vale a pena ler a respeito. Segundo esta thread no Google Groups, parece que o projeto Angular 2.0 deve também se integrar com Web Components e Polymer. Quando estes projetos e outros frameworks se unirem ao esforço Polymer provavelmente vamos ver o real valor dos Web Components.

Polymer é o projeto principal. Web Components é o conjunto de mecanismos, o meio para atingir esse objetivo. E é um problema clássico de ovo e galinha: os navegadores diferentes de Chrome precisam se equiparar e seguir a vontade do Google. Os polyfills, via Polymer/Platform e Mozilla X-Tag vão suprir o que falta (Mutation Observers, Shadow DOM, etc) como o JQuery fez no passado. Mas para os navegadores tracionarem nessa direção os desenvolvedores precisam entrar no barco, e para isso somente um pacote completo como Polymer/Paper e, se possível, aliado a frameworks como Ember e Angular podem fazer isso acontecer, e não pequenos componentes-demonstração.

A História se Repete

Já vimos essa história acontecer antes. Durante o Browser Wars muitos apenas vão se lembrar que a Microsoft conspirou ativamente para destruir a Netscape, culminando no processo que quase quebrou a Microsoft em 3 no ano 2000 e a consequência final que foi a sobra do amaldiçoado Internet Explorer 6 que, apesar de ter sido um excelente navegador em sua era, ele não deveria nunca ter durado mais de uma década em uso.

Muitos talvez não lembrem que isso também gerou muitas novas tecnologias, para listar algumas:

• O Internet Explorer 3.0 foi o primeiro navegador a implementar o CSS 1.
• O Internet Explorer 4.0 foi quem expôs o DOM e criou o DHTML, Dynamic HTML, com Dynamic Styling e manipulação de elementos do DOM via Javascript
• O Internet Explorer 5.0 foi quem trouxe a semente do Ajax com o componente proprietário XMLHTTP e a técnica de buscar conteúdo de forma assíncrona com iframes usada no Outlook Web Access, dando origem ao XMLHttpRequest

O período negro pós-2000 da Microsoft culminou no fracasso do Windows Vista e consequente sobrevida à la The Walking Dead tanto do Windows XP quanto do IE 6. O Google pegou o bastão de onde a Microsoft largou. O Core Business do Google é o AdWords. Controlar as plataformas Web faz parte da estratégia e o navegador continua sendo importante, porque ele é o novo sistema operacional desta geração, seja desktop ou mobile. Esqueçam Windows vs OS X vs GNU/Linux.

Outra tecnologia Microsoft que foi esquecida foi a primeira verdadeira tentativa de componentizar a Web. Foi com HTML Components do fim de 1998. Nessa época ainda estávamos tentando dominar drag-and-drop de elementos com DHTML e começando a brincar com as possibilidades de fazer requisições sem precisar recarregar a página.

Se olhar esta página de APIs Legadas da Microsoft teremos:

• Legacy DOM - substituída, claro, pelo DOM mais moderno
• IE Architecture/Active X - substituído por Silverlight, Flash, ainda Applets e widgets
• Browser Extensions - ainda temos extensions mas nenhum padrão
• DHTML Behaviors e DHTML Data Binding - são os novos Web Components
• Filters and Transitions - que até hoje temos browser-specific com modificadores como -moz ou -webkit, CSS 3
• Vector Markup Language (VML) - que é o atual SVG e HTML 5 Canvas

Não estou querendo dizer que é tudo mérito da Microsoft. A intenção é apenas explicar - para quem começou a usar a Internet na era pós-Browser Wars e pós-Crash das Dot-coms que Web Components não surgiu do nada, ela é o próximo passo lógico da evolução dos browsers e arquitetura Web.

Para o próprio Google essa não é a primeira vez. A primeira vez foi com GWT (Google Web Toolkit), que nasceu em 2006. Esse foi o auge dos frameworks MVC back-end que facilitavam desenvolvimento de aplicações Web usando Ajax. Foi a era pós-J2EE onde surgiram Rails, Django e outros Rails/Django-like como CakePHP, Grails.

Depois veio a era back-end assíncrono, desenterrando o problema C10K de 1999 de Dan Kegel, use case de Web Sockets (chat, APIs) que começa com Scala, vai para Node.js, chega em GoLang, Elixir. Novamente, não veio do nada, foi o próximo passo evolutivo depois do próprio Erlang, Twisted, Tornado, Java NIO/Netty, etc.

Em paralelo o Google investiu no Chrome e para isso precisou investir em Javascript e tornar o V8 algo realmente usável. Milhares de homens-hora e milhões de dólares depois, temos uma engine realmente performática. Com isso o mundo Javascript cresceu exponencialmente. Uma tecnologia que já se imaginava dominada na década de 90 ganhou nova roupagem e uma segunda chance. Com isso a arquitetura MVC2 evoluiu para um híbrido, com frameworks MVVM no client-side.

Portanto é natural evoluir do mindset GWT para Angular.js e eventualmente para Web Components/Polymer. E é onde estamos agora. Note que estamos sempre circulando os conceitos de MVC-clássico, MVC Model-2, MVP e agora MVVM, todos patterns originados do lendário MVC de Trygve Reenskaug do Smalltalk-80. Lembrando que já experimentamos programação orientada a componentes antes: foi a década de 90, que imaginou uma revolução ao usar componentes reusáveis para tornar o processo de programação meramente um jogo de arrastar blocos. Isso ficou conhecido como RAD (Rapid Application Development), que deu origem a toolkits e IDEs. Foi o conceito que deu origem a PowerBuilder, Visual Basic, Delphi, Swing. E a evolução na direção de ferramentas CASE (Computer Aided Software Engineering). Achávamos que poderíamos criar diagramas (UML) e as ferramentas gerariam o código-fonte para nós. Já ouviu falar disso? Pois é, não deu muito certo. O Visual Studio de hoje ainda tem suporte a isso (yikes).

A diferença são as ondas da moda: na década de 90 ainda estávamos definindo o que era possível e, pelo bem ou pelo mal, o que a Microsoft inventou realmente foi revolucionário porque não havia precedente. A era pré-Bolha trouxe o MVC2 para o desenvolvimento Web com Web Objects e J2EE. O advento do Ajax e aplicações dinâmicas trouxe de GWT a Rails. E agora a era da Renascença do Javascript trouxe o MVVM e Web Components.

Não sei o que vem depois daqui, mas depois de organizar a informação histórica espero que mais alguém tenha insights do que vem pela frente. O que acham que Web Components realmente pode trazer que já não vimos com GWT e anteriores?

O @jcemer publicou hoje um ótimo post explicando isso do ponto de vista de um front-end full-time, colocando em perspectiva.

Em resumo, o Rails trás um mecanismo fantástico chamado Asset Pipeline. Ele tem diversas funções, em particular otimizar os assets dos projetos Rails, compilando fontes de Sass ou Less para CSS. Depois concatenando todos os CSS, JS em um único arquivo. Depois minificando (com Uglify) para diminuir seu tamanho. Em particular com Sass ele ainda pode concatenar sprites em uma única imagem também. Enfim, o pacote completo para otimizar assets ao máximo.

Se você ainda não conhece sobre esse recurso, não deixe de ler meu tutorial.

Só que à medida que um projeto precisa ter várias bibliotecas CSS, JS, etc o processo pode ficar chato. Principalmente porque em alguns casos precisa manualmente modificar os paths dentro de seus fontes.

Um dos problemas é que o Asset Pipeline vai juntar todos os arquivos em um único, colocando timestamp no nome. E aí os paths não vão funcionar a menos que usem o helper asset_path ou asset_url. Por isso acabamos usando rubygems feitas manualmente como o bootstrap-rails.

E isso leva a outro problema: atualizações. Primeiro, os autores originais lançam uma determinada biblioteca Javascript. Podemos manualmente fazer o download dos fontes e “vendorizá-los” no projeto. Ou, se você utilizar o Bower podemos esperar sair esse novo pacote e atualizar com o Bower. Ou, se estivermos usando uma Rubygem, podemos esperar sair a nova gem e atualizar com Bundler.

Então, vamos separar tudo e usar Bower pra gerenciar bibliotecas de front-end e usar Bundler para gerenciar gems de back-end e todo mundo fica feliz? Não é tão fácil assim já que muitas gems - ActiveAdmin como um bom exemplo - já dependem de bibliotecas de front-end encapsuladas em rubygems como temos neste trecho da gemspec:

...
s.add_dependency "bourbon"
s.add_dependency "jquery-rails"
s.add_dependency "jquery-ui-rails"
...

Já que temos duas comunidades tendo exatamente o mesmo trabalho: no Bower alguém vai atualizar pacotes de jquery; na Rubygems alguém vai ter que atualizar também. Então, porque não otimizar isso e apenas um deles atualizar. Nesse caso vamos aproveitar - e colaborar - para deixar as do Bower sempre atualizadas.

Será que existe uma forma, então, de converter um pacote Bower para um pacote Rubygems? E este é o problema que o Rails Assets se propõe a tentar resolver. Seguindo exatamente o mesmo exemplo do site deles, colocaremos na Gemfile de nossos projetos Rails desta forma:

source 'https://rubygems.org'
source 'https://rails-assets.org'

gem 'rails'

group :assets do
  gem 'sass-rails'
  gem 'uglifier'
  gem 'coffee-rails'
  gem 'rails-assets-bootstrap'
  gem 'rails-assets-angular'
  gem 'rails-assets-leaflet'
end

A primeira diferença é um novo source. E isso é importante pois não vai poluir o repositório de Rubygems com gems que são meros ‘stubs’.

A segunda diferença são as gems prefixadas seguindo o padrão “rails-assets-[nome do pacote Bower]” que, obviamente, foram feitas desta forma para não conflitarem com as que já existem no Rubygems.org. Se isso funcionar significa que a antiga gem “bootstrap-rails” poderá ser descontinuada e passamos a usar a “rails-assets-bootstrap”, e assim por diante.

Se uma determinada gem ainda não existir, o processo vai demorar um pouco porque o Rails Assets vai baixar o pacote do Bower, modificá-la, encapsulá-la como uma Rubygem e publicar no seu repositório. Mas quanto mais gente usar com mais bibliotecas, mais rubygems já estarão prontas para baixar imediatamente.

Para o Asset Pipeline continua a mesma coisa. No mesmo arquivo app/assets/javascripts/application.js teríamos igual:

//= require_self
//= require bootstrap
//= require angular
//= require leaflet
//= require_tree .
//= require_tree shared

E no app/assets/stylesheets/application.css teríamos também igual:

/*
 *= require_self
 *= require bootstrap
 *= require leaflet
 *= require_tree .
 *= require_tree shared
 */

As rubygems que encapsulam bibliotecas front-end não são apenas por causa do Asset Pipeline, além disso elas também podem conter generators para facilitar a criação de alguma estrutura de diretórios ou arquivos de configuração específicos. Mas mesmo nesse caso podemos separar em duas coisas: uma sendo só os fontes originais e uma segunda gem que depende da primeira com ferramentas ou outros extras como generators.

Conclusão

Para Rubistas a primeira vantagem mais óbvia é o seguinte: não precisamos misturar dois workflows de dependência, uma com Bower (ou manualmente) e outra com Bundler. Podemos continuar apenas com Bundler. Lembrando que se pacotes Bower não forem vendorizados no projeto Rails ainda teríamos que manter esse processo com Bower na integração contínua - adicionando o comando no .travis.yml, por exemplo; e também teríamos que ter no deployment. Idealmente, não deveríamos ter que vendorizar bibliotecas. Isso sem contar que se usar Bower num projeto Rails e usar Heroku, precisa de um outro buildpack para funcionar. Ou seja, o Bower adiciona muito mais complexidade do que somente ter que rodar mais um comando “install” em desenvolvimento. Ambientes de teste, produção, tudo fica um pouco mais complicado, e desnecessariamente.

Além disso, quem colaborava mantendo a rubygems de um “bootstrap-rails”, por exemplo, pode continuar a dedicar seu tempo atualizando diretamente o pacote equivalente do Bower e deixar essa fonte única sempre atualizada, o que pode ser um reforço ao Bower e aos não-rubistas que a utilizam.

E com isso também não precisamos ter gems de stubs poluindo o Rubygems.org. Ou seja, “se” funcionar será uma situação ganha-ganha para todo mundo. Porém nem tudo são flores. Como uma das idéias do Rails Assets é modificar o fonte para adicionar os asset-paths corretos, quer dizer que podem existir situações onde patterns automáticos não peguem, ou existam ambiguidades que precisem ser resolvidos manualmente. Então, das duas uma: ou colaboramos com o Rails Assets para adicionar os patterns que faltam, se for possível; ou criamos um passo no workflow do Rails Assets que permitam modificações manuais. Ainda não sei, precisamos ver quais são esses cenários e como corrigí-los. Mas isso não elimina os pontos positivos descritos anteriormente.

O melhor a fazer: testar e experimentar. O projeto é open source, você pode colaborar mandando Pull Requests ou mesmo reportando Issues e ajudando a evoluir. Se a idéia for furada - o que não me parece - vamos saber rapidamente - e voltamos ao mesmo problema de antes, mas pelo menos esta é uma proposta de solução muito interessante que vale a pena ser explorada mais a fundo.

Se quiser ver como essa aplicação se comporta de verdade, eu subi uma versão numa conta free do Heroku, então clique aqui e veja.

Nesta Parte 2 vamos continuar com as seguinte seções:

• Seção Bônus: Markdown
• Seção Bônus: Twitter Bootstrap
• ActiveAdmin e Globalize 3
• Rotas Internacionalizadas
• Conclusão

Seção Bônus: Markdown

Outra coisa que quero demonstrar no caso de um aplicativo “estilo” gerenciador de conteúdo (CMS) é o cache do HTML que queremos gerar. Neste exemplo defini que o atributo Article#body terá texto no formato Markdown. Poderia ser qualquer outro formato como Textile, Creole, MediaWiki ou o qualquer outro que gere HTML. É uma forma de simplificar o processo de edição do conteúdo sem precisar de um editor WYSIWYG mais complicado como um bootstrap wysihtml5.

Uma boa engine para converter Markdown em HTML é o RDiscount (olhe também a gem Tilt, ambos do Ryan Tomayko). Novamente, apenas adicione a seguinte gem no Gemfile:

gem 'rdiscount'

Usá-lo é muito simples:

RDiscount.new("texto em **markdown**.").to_html #=> **markdown**

O erro mais comum é adicionar essa lógica no controller, algo como isso:

class ArticleController < ApplicationController  
 def show  
    article = Article.find(params[:id])
    @html = RDiscount.new(`article.body).to_html  
 end  
end

Isso acarreta um processamento de conversão para cada requisição de cada usuários à mesma página. É exatamente o tipo de cenário que queremos otimizar o quanto antes. A melhor forma, nesse tipo de cenário de conversão, é gravar a versão convertida junto com a original. Por isso na migration do model Article já criamos com a coluna body e também body_html. Então só precisamos adicionar um simples callback no model:

class Article < ActiveRecord::Base  
 attr_accessible :body, :body_html, :slug, :title, :locale, :translations_attributes  
 …  
 before_save :generate_html  
 …  
 def translations_attributes=(attributes)  
 new_translations = attributes.values.reduce({}) do |new_values, translation|  
 translation.merge!("body_html" => RDiscount.new(translation["body"] || "").to_html )  
 new_values.merge! translation.delete("locale") => translation  
 end  
 set_translations new_translations  
 end  
private  
 …  
 def generate_html  
 self.body_html = RDiscount.new(self.body).to_html  
 end  
end  

Isso foi simples. Agora não precisa adicionar nada no controller e na view basta chamar diretamente o conteúdo cacheado:

<%= raw @article.body_html %\>  

Observe também o método raw: como estamos adicionando HTML vinda de model na view, o Rails, por padrão, vai considerar esse conteúdo “perigoso” e irá escapá-lo. Não é o que queremos, queremos mesmo que o HTML seja mesclado, para isso precisamos expôr nossa intenção explicitamente dizendo que queremos o HTML “crú” (raw). Leia mais sobre essa funcionalidade no Guia Oficial.

Em particular o método translations_attributes= merece atenção. Por causa da forma como o Globalize3 lida com a associação de traduções, ao tentarmos simplesmente adicionar massivamente múltiplas traduções, ele não executa corretamente os before_filter para cada linguagem, acaba apagando items que não são a localização configurada atualmente e grava somente um ítem em vez de gravar massivamente múltiplos. Isso particularmente quebra a funcionalidade de ActiveAdmin que vamos discutir mais abaixo.

Para consertar isso, sobrescrevemos o método de assinalação em massa forçando o uso do método set_translations do Globalize3. Além disso também já criamos a versão HTML do campo body e gravamos de uma vez, isso porque a versão de cache do HTML no fundo é uma “tradução” e por isso não vai na tabela principal articles mas sim na implícita article_translations.

Seção Bônus: Twitter Bootstrap

Essa é completamente fora do escopo deste artigo, mas como meu código no Github está utilizando, vou apenas listar como instalei. Para quem não conhece, o Twitter Bootstrap é um conjunto de stylesheets e javascripts para estilizar rapidamente seu site, justamente para casos como este, onde o design não é importante, é basicamente um protótipo e eu queria algo menos feio do que não colocar nada. Existem diversas gems derivadas que utilizam o bootstrap, mas para o básico podemos começar adicionando as seguintes gems no Gemfile:

group :assets do  
 …

# See <https://github.com/sstephenson/execjs#readme> for more supported runtimes  
 gem 'therubyracer', :platforms => :ruby  
 gem 'less-rails'  
 gem 'twitter-bootstrap-rails'  
end  

Agora podemos começar a instalar os arquivos estáticos para a aplicação:

rails g bootstrap:install application fluid  

E depois podemos adicionar as views estilizadas para cada recurso da sua aplicação:

rails g bootstrap:themed Articles  

Neste ponto, ele vai criar vários arquivos desnecessários que podemos apagar e precisamos customizar bastante. Não vou copiar todo o fonte das views no arquivo, então faça o clone deste projeto no Github e aprenda lendo o código que está em app/uploads e app/views. Compare com os arquivos gerados pelo geradores acima e o que foi modificado.

Um dos pontos importantes a lembrar quando lidamos com plugins de javascript, arquivos CSS, é não deixar sobrando require_tree . sem que você saiba para que serve. Leia meu artigo sobre Assets Pipeline para Iniciantes.

No caso do layout principal note que adicionei bloco de .navbar para o menu principal no topo. Adicionei o yield onde os outros conteúdos vão se encaixar dentro de um .container e temos uma área de botões no rodapé num bloco .form-actions. Um cuidado sobre esta gem é que no arquivo que ele cria em app/uploads/stylesheets/bootstrap_and_overrides.css.less ele define margens no elemento body que são desnecessários, apenas remove essas definições logo no começo do arquivo.

Note também que no meu Github todas as views de Devise que mencionamos anteriormente já estão estilizadas com o bootstrap (por isso que na seção que mencionamos sobre Devise eu faço um git checkout 0ff207… para fazer download das views traduzidas mas que ainda não tinham sido estilizadas). Agora você pode voltar ao diretório do meu projeto, fazer git checkout master e realizar a mesma cópia dos arquvos para pegar as views estilizadas.

Um lembrete para menus é criar itens que saibam em que controller/action estamos e desabilitar o link da página atual, um exemplo é o que fiz de exemplo nesta aplicação. No arquivo app/helpers/application_helper.rb temos:

module ApplicationHelper  
 …  
 def navigation_links  
 links = []  
 options = params[:controller] == "welcome" ? { class: "active" } : {}  
 links << content_tag(:li, link_to(t("hello"), welcome_path), options).html_safe

options = params[:controller] == "articles" ? { class: "active" } : {} 
links << content_tag(:li, link_to(t("articles.title"), articles_path), options).html_safe 
links << content_tag(:li, link_to(t("admin.title"), admin_dashboard_path)).html_safe content_tag(:ul, links.join("\n").html_safe, class: "nav") 
end

end  

E no layout em app/views/layouts/application.html.erb colocamos:

<%= t("site_name") %\>](#)\<%= navigation_links %\>

ActiveAdmin e Globalize 3

O ActiveAdmin é um excelente projeto para termos rapidamente um módulo simples de administração que consegue expôr as operações de CRUD de um model, incluindo suas validações e até elementos como upload de imagens (caso esteja usando CarrierWave, por exemplo). Por usar por baixo formtastic, customizar seus formulários também não é complicado. Instalar é simples, coloque na Gemfile:

…  
group :assets do  
 gem 'jquery-ui-rails'  
 …  
end  
…  
gem 'jquery-rails'  
gem 'activeadmin'  
gem 'ActiveAdmin-Globalize3-inputs'  
…  

Execute o comando:

rails g active_admin:install  

Uma dica para que o Assets Pipeline não falhe em produção. Precisamos declarar explicitamente os assets do ActiveAdmin. Adicione no config/application.rb:

config.assets.precompile += %w(active_admin.js active_admin.css)  

Agora adicione em app/admin quaisquer models que precise expor. Leia a documentação do ActiveAdmin no site deles mas como exemplo, para customizar a tabela de listagem do model Article (index) e também a página visualização de um único artigo (show), podemos escrever em app/admin/articles.rb:

ActiveAdmin.register Article do  
 index do  
 column :id  
 column :slug  
 column :title

default_actions end 
  show do |article| attributes_table do 
    row :slug I18n.available_locales.each do 
      |locale| h3 I18n.t(locale, scope: ["translation"]) div do 
        h4 article.translations.where(locale: locale).first.title 
        end 
      div do 
        article.translations.where(locale: locale).first.body_html.html_safe 
      end 
    end 
  end 
  active_admin_comments 
end

O bloco show é o mais interessante. Aqui estamos usando diretamente a associação translations que o Globalize 3 adicionou ao nosso model para buscar explicitamente o conteúdo de uma localização, em vez de puxar o que o model nos der automaticamente baseado na localização. Assim colocamos ambos os conteúdo uma embaixo do outro de uma só vez.

Mas e para editar os conteúdos de ambas as localizações? Para isso colocamos além do ActiveAdmin o ActiveAdmin-Globalize3-inputs e as gems de JQuery (porque vamos precisar do elemento de “Tabs”).

Esse módulo vai utilizar as funcionalidades do ActiveRecord de accepts_nested_attributes_for para receber no mesmo formulário HTML os atributos das associações. Para isso garanta que seu modelo app/models/article.rb tem o seguinte:

class Article < ActiveRecord::Base  
 attr_accessible :body, :body_html, :slug, :title, :locale, :translations_attributes  
 …  
 translates :title, :body, :body_html  
 accepts_nested_attributes_for :translations  
 …  
 class Translation  
 attr_accessible :locale, :title, :body, :body_html  
 end

def translations_attributes=(attributes) 
    new_translations = attributes.values.reduce({}) do 
      |new_values, translation| translation.merge!("body_html" => RDiscount.new(translation["body"] || "").to_html ) 
      new_values.merge! translation.delete("locale") => translation end 
      set_translations new_translations end …
end

Isso faz o modelo aceitar mass assignment do atributo translations_attributes, usamos o accepts_nested_attributes_for para que os helpers de formulário saibam como gerar os elementos para os atributos da associação. Uma coisa estranha pode ser o fato de estarmos sobrescrevendo a classe Article::Translation. Acredito que é um bug do Globalize 3, e sem essa modificação o mass assignment iria falhar.

Precisamos também adicionar o JQuery UI para o ActiveAdmin. Basta alterar o arquivo app/uploads/stylesheets/active_admin.css:

// Active Admin CSS Styles  
@import "active_admin/mixins";  
@import "active_admin/base";  
@import "jquery.ui.tabs";  

E também o arquivo app/uploads/javascripts/active_admin.js:

//= require active_admin/base  
//= require jquery.ui.tabs  

Finalmente, precisamos alterar novamente o arquivo de configuração app/admin/articles.rb para adicionar o seguinte:

ActiveAdmin.register Article do  
 …  
 form do |f|  
 f.input :slug  
 f.globalize_inputs :translations do |lf|  
 lf.inputs do  
 lf.input :title  
 lf.input :body

lf.input :locale, :as => :hidden end end f.buttons end

end  

Atributos não internacionalizados como slug ficam fora, mas o resto vai dentro do bloco globalize_inputs passando o nome da associação, nesse caso translations. E dentro de cada sub-formulário precisamos de um campo escondido com a localização desse sub-formulário em particular, para isso temos o campo locale como hidden.

Vale lembrar que o ActiveAdmin suporta internacionalização também. Neste aplicativo escolhi não adicionar esse suporte. É o cenário onde um único administrador controla ambas as linguagens. Mas se você tiver a situação onde cada equipe em cada país cuida da sua própria linguagem, talvez queira adicionar este suporte.

Finalmente, como explicamos na seção sobre Markdown, para que o ActiveAdmin consiga dar POST de várias traduções ao mesmo tempo, no mesmo formulário, usando a capacidade de assinalamento em massa e accepts_nested_attributes_for, temos que sobrescrever o método translations_attributes= pois simplesmente inserir os novos registros de tradução na associação não vai funcionar, o Globalize3 vai filtrar essa lista e só vai gravar o registro da localização atual. Mas forçando o uso to método interno do Globalize3, set_translations, conseguimos gravar múltiplas traduções ao mesmo tempo.

Rotas Internacionalizadas

Deixei por último uma das coisas mais interessantes nesta aplicação. Para efeitos de SEO também queremos que as URLs sejam traduzidas. Ou seja, queremos que as seguintes URLs todas apontem para o mesmo lugar:

/users/sign_in  
/en/users/sign_in  
/pt-BR/usuarios/login  

Existem algumas gems que fazem isso, a primeira que esbarrei se chama “i18n_routing”, mas não consegui fazê-la funcionar, acredito que tenha bugs ainda. Se procurar mais vai acabar encontrando a translate_routes mas ela está obsoleta e dois outros forks passaram a atualizá-la. Uma é a route_translator, que eu não testei porque parecia ter pouca atividade. A que escolhi usar se chama rails-translate-routes. Para adicionar ao projeto, edite seu Gemfile:

gem 'rails-translate-routes'  

Depois de executar o comando bundle precisamos editar o arquivo config/routes.rb que controla todas as rotas. Neste estágio, ele deve ter o seguinte conteúdo:

I18nDemo::Application.routes.draw do

#1. rotas para active admin  
 ActiveAdmin.routes(self)  
 devise_for :admin_users, ActiveAdmin::Devise.config

#1. rotas de autenticação do Devise  
 devise_for :users

#1. rotas pra artigos  
 resources :articles

  #1. pagina principal  
 get "welcome/index", as: "welcome"  
 root to: 'welcome#index'  
end  

O que queremos agora é traduzir todas as rotas públicas, incluindo as do Devise. Porém, como explicado antes, no caso do ActiveAdmin estamos no cenário onde não precisamos de telas de administração traduzidas. Então devemos modificar o arquivo para ficar assim:

I18nDemo::Application.routes.draw do  
 devise_for :users  
 resources :articles  
 get "welcome/index", as: "welcome"  
 root to: 'welcome#index'  
end

ActionDispatch::Routing::Translator.translate_from_file(  
 'config/locales/routes.yml', {  
 prefix_on_default_locale: true,  
 keep_untranslated_routes: true })

I18nDemo::Application.routes.draw do  
 ActiveAdmin.routes(self)  
 devise_for :admin_users, ActiveAdmin::Devise.config  
end  

Uma dica é que o bloco de rotas depois do método #draw pode ser dividido. Isso é importante porque as rotas definidas antes do método #translate_from_file serão traduzidas, e as definidas no bloco abaixo (onde colocamos o ActiveAdmin), não serão.

Este código diz que vamos colocar as traduções no arquivo config/locales/routes.yml. Então criamos esse arquivo com o seguinte conteúdo:

en:  
 routes:  
pt-BR:  
 routes:  
 welcome: bemvindo  
 new: novo  
 edit: editar  
 destroy: destruir  
 password: senha  
 sign_in: login  
 users: usuarios  
 cancel: cancelar  
 article: artigo  
 articles: artigos  

O bloco en.routes fica vazio porque como nossa aplicação está toda em inglês, por padrão, as rotas são em inglês. Agora no bloco pt-BR.routes basta colocarmos as palavras que queremos traduzir, seja ela nome de controller, de action, de resource, e a gem fará o resto. Se executarmos o comando rake routes depois de termos isso configurado, teremos:

…  
article_pt_br GET /pt-BR/artigos/:id(.:format) articles#show {:locale=>"pt-BR"}  
 article_en GET /en/articles/:id(.:format) articles#show {:locale=>"en"}  
GET /articles/:id(.:format) articles#show  
PUT /pt-BR/artigos/:id(.:format) articles#update {:locale=>"pt-BR"}  
PUT /en/articles/:id(.:format) articles#update {:locale=>"en"}  
PUT /articles/:id(.:format) articles#update  
DELETE /pt-BR/artigos/:id(.:format) articles#destroy {:locale=>"pt-BR"}  
DELETE /en/articles/:id(.:format) articles#destroy {:locale=>"en"}  
DELETE /articles/:id(.:format) articles#destroy  
welcome_pt_br GET /pt-BR/bemvindo/index(.:format) welcome#index {:locale=>"pt-BR"}  
 welcome_en GET /en/welcome/index(.:format) welcome#index {:locale=>"en"}  
GET /welcome/index(.:format) welcome#index  
 root_pt_br /pt-BR welcome#index {:locale=>"pt-BR"}  
 root_en /en welcome#index {:locale=>"en"}  

Já se perguntou sobre a necessidade de usar rotas nomeadas como new_article_path em vez de digitar direto /articles/New? Este é um motivo, a mesma rota nomeada vai levar em consideração o parâmetro implícito de localização e nos dar a URI traduzida correta sem que você precise alterar mais nada em nenhuma parte da aplicação! Win-win.

Precisamos que a aplicação reconheça o parâmetro locale que virá dentro do hash params que já conhemos. Vamos colocar um before_filter no /app/controllers/application_controller.rb:

class ApplicationController < ActionController::Base  
 protect_from_forgery

before_filter :set_locale before_filter :set_locale_from_url 

private 

def set_locale 
  if lang = request.env['HTTP_ACCEPT_LANGUAGE'] 
      lang = lang[/^[a-z]{2}/] 
      lang = :"pt-BR" 
  if lang == "pt" end 
    I18n.locale = params[:locale] || lang || I18n.default_locale end
end  

Agora podemos ir em http://localhost:3000/en/articles ou http://localhost:3000/pt-BR/artigos e vamos chegar no mesmo local. Basta colocarmos na aplicação links para podemos trocar de linguagem em qualquer página que estivermos. Para isso usaremos o helper url_for que usará os parâmetros correntes para gerar o link correto da página atual. Precisamos adicionar em app/helpers/application_helper.rb:

module ApplicationHelper  
 def language_links  
 links = []  
 I18n.available_locales.each do |locale|  
 locale_key = "translation.#{locale}"  
 if locale == I18n.locale  
 links << link_to(I18n.t(locale_key), "#", class: "btn disabled")  
 else  
 links << link_to(I18n.t(locale_key), url_for(locale: locale.to_s), class: "btn")  
 end  
 end  
 links.join("\n").html_safe  
 end  
 …  
end  

E podemos colocar, neste exemplo, na área de rodapé da aplicação. Então adicionamos ao app/views/layouts/application.html.erb:

…

<%= language_links %\>

Ambientes de Desenvolvimento e Produção

Agora entenda uma regra básica:

• toda URL que você passar ao Rails é analisada pelo sistema de roteamento, que você configura em config/routes.rb
• a exceção é tudo que estiver no diretório public, graças ao middleware Rack::Static.

Ou seja, se você pedir por http://localhost:3000/uploads/application.js isso nem vai passar pelo Rails porque, como vimos na listagem do diretório public/uploads acima, esse arquivo existe lá e, portanto, será servido diretamente.

Por isso a recomendação, depois do último exercício com pré-compilação é apagar tudo:

rm -Rf public/uploads

–

Desta forma, quando você subir o servidor Rails no ambiente padrão de desenvolvimento, a mesma URL irá passar pelo Rails, pelo Asset Pipeline, e processará o arquivo app/uploads/javascripts/application.js. Assim, toda vez que fizer modificações e recarregar a página no navegador, você verá as mudanças imediatamente. Se estivesse précompilado, veria a versão antiga, sem as modificações novas.

A compilação em tempo real só acontece em desenvolvimento pois, obviamente, é um processo lento. Em produção, ninguém em sã consciência vai alterar nenhum arquivo direto em servidor de produção, portanto é importante ter tudo précompilado em public/uploads para economizar o aplicativo Rails do trabalho.

Outra coisa importante, os arquivos de assets que se chamam “application”, são automaticamente compilados. Mas digamos que você tem um stylesheet que não vai carregar no layout principal, mas só em algumas outra seções, digamos que se chame special.css, ou seja, precisamos encontrá-lo em http://localhost:3000/uploads/special.css, criamos nesta estrutura:

app  
 assets  
 stylesheets  
 special.css

Porém, se reexecutarmos o rake task assets:precompile novamente, verá que esse arquivo não aparece em public/uploads. Recapitulando, arquivos “application” são automaticamente usados na précompilação. Todo asset declarado nesses manifestos, será usado dentro dos arquivos minificados “application”. Agora, para adicionar arquivos extras, precisamos declará-los manualmente em config/application.rb, adicionado uma linha assim:

config.assets.precompile += %w(special.css)  

Colocar tudo no “application” e carregar esse arquivo no layout principal para que toda página tenha tudo? Ou separar CSS e JSS que é necessário seção a seção do site? Não tenho uma regra rígida. Se a aplicação não for tão grande assim, provavelmente centralizar tudo em “application” é a saída mais simples de gerenciar. Porém se a aplicação for ou muito grande, ou se determinada seção é relativamente mais pesada em JS que as demais, por exemplo, talvez valha a pena gerenciar assets em separado, usando a configuração acima.

Agora sim, se executar a task de precompile novamente, teremos algo como:

special-f7bf76f875ce5c9edd0075eaea3f6140.css  
special-f7bf76f875ce5c9edd0075eaea3f6140.css.gz  
special.css  
special.css.gz  

Compass e SASS

Agora, por que adicionamos o Compass? Não vou fazer desta seção um tutorial de Compass, mas para que entendem o básico, podemos adicionar o seguinte CSS de exemplo em app/uploads/stylesheets/application.css.scss:

@import "compass";

.box {  
 font {  
 family: Lucida Grande;  
 size: 12px;  
 }  
 width: 400px;  
 padding: 15px;  
 border: 1px solid black;  
 @include text-shadow(1px 0 1px opacify(#5c5c5c, .37));  
 @include box-orient(horizontal);  
 @include border-radius(20px, 20px);  
}  

Na maior parte parece um CSS normal, mas a diferença maior está nos comandos @include do Sass, que serve para carregar “Mixins”. Pense em Mixin no Sass como “funções” que retornam CSS parametrizável e reusável. O Compass é uma biblioteca de Mixins que encapsulam alguns dos aspectos mais comuns de CSS. No exemplo, estamos chamando os mixins text-shadow e border-radius, cuja função deve ser bastante óbvia. Vamos ver o CSS que isso gera:

** line 3, ../../app/uploads/stylesheets/application.css.scss **/  
.box {  
 width: 400px;  
 padding: 15px;  
 border: 1px solid black;  
 text-shadow: 1px 0 1px #5c5c5c;  
 -webkit-box-orient: horizontal;  
 -moz-box-orient: horizontal;  
 -ms-box-orient: horizontal;  
 box-orient: horizontal;  
 -webkit-border-radius: 20px 20px;  
 -moz-border-radius: 20px / 20px;  
 -ms-border-radius: 20px / 20px;  
 -o-border-radius: 20px / 20px;  
 border-radius: 20px / 20px;  
}  
/** line 4, ../../app/uploads/stylesheets/application.css.scss */  
.box font {  
 family: Lucida Grande;  
 size: 12px;  
}  

Fica claro a função de “nesting”, para herdar estilos de um elemento pai, que usamos no elemento “font” para não repetir em blocos separados, como no CSS final. O “text-shadow” foi simples, mas o “box-orient” e border-radius" automaticamente adicionaram todas as diretivas específicas de cada browser, coisas como “-webkit”, “-moz”, etc.

Veja a documentação de referência do Compass para encontrar todos os mixins e exemplos detalhados de como usá-los.

Isso é interessante, mas a principal função, para fechar todas as situações que descrevi na introdução do artigo, é a que se segue.

Primeiro, vamos adicionar duas novas imagens na pasta app/images/social-icons:

app  
 images  
 social-icons  
 facebook.png  
 linkedin.png  
 twitter.png  

Agora, vamos adicionar o seguinte HTML em app/views/home/index.html.erb:

…

1. [Twitter](http://www.twitter.com)
  
2. [Facebook](http://www.facebook.com)
  
3. [LinkedIn](http://www.linkedin.com)

Nada demais, apenas o objetivo de adicionar ícones de redes sociais com links a eles. Para estilizá-los, vamos completar nosso SCSS assim:

@import "compass";  
@import "social-icons/*.png";

…

ol.social {  
 @include horizontal-list;  
 @each $network in twitter, facebook, linkedin {  
 li.#{$network} a {  
 @include social-icons_sprite(#{$network})  
 }  
 }  
 a {  
 height: 32px;  
 width: 32px;  
 display: block;  
 text-indent: 9000px;  
 color: #FFF;  
 }  
}  

–

Novamente, estude SASS para entender essa sintaxe e também note que novamente usamos um mixin do Compass chamado horizontal-list. Lembre que colocamos 3 novas imagens, listados acima. Agora neste SCSS, na segunda linha, fazemos um @import de todos esses ícones.

Agora localize esta linha: @include social-icons_sprite(#{$network}). O nome da pasta, com o sufixo “_sprite” se torna um mixin, que recebe como parâmetro o nome da imagem/sprite. O que significa isso no CSS gerado ao final? Vejamos:

/* line 58, social-icons/**.png */  
.social-icons-sprite, ol.social li.twitter a, ol.social li.facebook a, ol.social li.linkedin a {  
 background: url(/uploads/social-icons-s25bc94da3e.png) no-repeat;  
}  
…  
/ **line 20, ../../app/uploads/stylesheets/application.css.scss** /  
ol.social li.twitter a {  
 background-position: 0 -32px;  
}  
/ **line 20, ../../app/uploads/stylesheets/application.css.scss** /  
ol.social li.facebook a {  
 background-position: 0 -64px;  
}  
/** line 20, ../../app/uploads/stylesheets/application.css.scss */  
ol.social li.linkedin a {  
 background-position: 0 0;  
}  
…  

Aqui vemos o que aconteceu: as 3 imagens separadas foram concatenadas numa única, declarada no topo do CSS, chamada neste exemplo de /uploads/social-icons-s25bc94da3e.png. Agora, cada uma das classes de rede social que criamos tem um reposicionamento da mesma imagem, como: background-position: 0 -64px;.

Isto resolve o ponto 2 da introdução do artigo, que estava pendente: gerenciamento de sprites. Dependendo da quantidade de pequenas imagens que uma única página do seu site tem, somente este truque pode causar um impacto positivo que seus usuários irão notar rapidamente por causa do aumento na velocidade de renderização.

Para complementar, sempre que usarmos chamadas como background: url(/uploads/social-icons-s25bc94da3e.png) no CSS, nunca devemos digitar a URL absoluta manualmente. Devemos deixar o Asset Pipeline cuidar disso, como ele fez aqui no caso dos sprites.

Vejamos um exemplo mais concreto. Vamos adicionar o seguinte ao nosso application.css.scss:

h1 {  
 padding-left: 60px;  
 height: 70px;  
 background: url("/uploads/rails.png") no-repeat;  
}  

O que confunde é que isso de fato funciona. Porém, caímos nos problema mencionados no início do artigo: sem o número timestamp, se atualizarmos a imagem, os usuários ficarão travados na versão antiga em cache local. Se quisermos migrar para CDN vamos ter problemas de mudar todas essas URLs manualmente, etc. Portanto, no caso de SASS o correto é usar a função image-url e fazer desta forma:

background: image-url("rails.png") no-repeat;

Isto irá gerar a URL correta. Temos as seguinte variações:

image-url("rails.png") # url(/uploads/rails.png)  
image-path("rails.png") # "/uploads/rails.png".  
asset-url("rails.png", image) # url(/uploads/rails.png)  
asset-path("rails.png", image) # "/uploads/rails.png"  

Agora, se for necessário URLs de assets dentro do Javascript, não há equivalente no application.js puro, por isso precisaríamos renomeá-lo para application.js.erb e então a mesma regra que usaríamos em views HTML ERB normais valem:

var imagem = "<%= image_path("rails.png") \>";  
var tag_imagem = "<= image_tag("rails.png") \>";  
var audio = "<= audio_path("rails.mp3") \>";  
var tag_audio = "<= image_tag("rails.mp3") \>";  
var video = "<= video_path("rails.m4v") \>";  
var tag_video = "<= image_tag("rails.m4v") %\>";  

Vejam a documentação do ActionView::Helpers::AssetTagHelper para entender melhor sobre estes helpers, mas o importante é: se estiver escrevendo a URL de um asset manualmente, como um string, você está fazendo errado.

NGINX

Não vou entrar em detalhes sobre como configurar um NGINX completo, mas fica um lembrete para não esquecer de adicionar à configuração do servidor o seguinte trecho:

location ~ ^/uploads/ {  
 expires 1y;  
 add_header Cache-Control public;  
 add_header Last-Modified "";  
 add_header ETag "";  
 break;  
}

Isso garantirá que o browser do usuário guarde todos os assets no seu cache local para não pedir novamente. Com o Asset Pipeline, como explicamos exaustivamente acima, assets atualizados são imunes ao cache local.

E para diminuir ainda mais a quantidade de bits transportado entre o servidor e o browser dos usuários, lembre de checar se o suporte a gzip está ativado:

# 1. Gzip Settings  

gzip on;  
gzip_disable "msie6";

gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;  

Conclusão

Como podem ver, o Asset Pipeline é bastante simples para a grande maioria dos casos de uso. As regras são diferentes mas simples:

• Assets devem ir todas em app/uploads
• Em desenvolvimento public/uploads deve ficar vazio. Em produção, sempre execute rake assets:precompile
• Não digite URL de assets manualmente, use os helpers de URL

Isso lhe dará, “de graça”:

• concatenação de arquivos de assets, minificação de javascript e stylesheets
• compatibilidade com caches, CDNs e suporte a gzip
• gerenciamento de sprites numa única imagem com posicionamento via CSS
• suporte a diferentes geradores de templates, como SASS

Expanda seus conhecimentos, aprenda mais sobre:

• Bourbon
• Compass
• Rails Guides
• Asset Pipeline for Dummies

Esqueçam rumores, opiniões contrárias, rants e trolls. O Asset Pipeline certamente não é simples. Porém está longe do bicho de sete cabeças que costumam descrever. No início haviam muitos bugs, que já foram corrigidos e, toda vez que alguém falar em “Asset Poopline”, normalmente é problema de de BIOS mais do que de ferramenta. Google e Stackoverflow, for the help.

• coloque todos os seus assets (imagens, stylesheets e javascripts) organizados nas pastas public/images, public/stylesheets, public/javascripts;
• utilize helpers como image_tag, stylesheet_link_tag e javascript_include_tag;
• configure seu servidor web (Apache, NGINX) para servir URIs como /images/rails.png diretamente de public/images/rails.png para não precisar passar pelo Rails;

Pronto, está tudo preparado para funcionar. Porém, existiam e ainda existem muitas situações que essa regra não cobria e diversas técnicas, “boas práticas” e gems externas precisaram ser criadas para resolvê-las. Em particular, temos as seguintes situações cotidianas em desenvolvimento web:

• quando se tem muitos assets, como javascripts, é considerado boa prática “minificá-los”, ou seja, otimizar ao máximo a quantidade de bytes eliminando supérfluos como espaços em branco e quebras de linha, nomes de variáveis e funções longas, etc. E além disso concatenar a maior quantidade de arquivos num único quanto possível. Em desenvolvimento, precisamos ter todos abertos e individuais para facilitar o debugging, mas em produção o correto é “compilá-los”
• cache precisa ser usado o máximo possível e escrever o caminho a um path manualmente, como é ruim, pois se precisarmos mudar o conteúdo dessa imagem, os usuários precisariam limpar seus caches pois o correto é configurarmos os servidores web com diretivas para manter assets no cache local por um longo período de tempo (1 ano ou mais). Helpers como image_tag criavam caminhos como , sendo esse número derivado do timestamp de modificação do asset. Assim, se o asset era atualizado esse número mudava. Mas isso não funciona bem com muitos tipos de caches e proxies, que ignoram o que vem depois do “?”
• quando uma página possui dezenas ou às vezes centenas de pequenas imagens e ícones (setas, botões, logotipos de seção, linhas, bordas, etc), o correto é usar a mesma técnica que usamos com stylesheets e javascripts: concatenar muitas imagens em um único arquivo maior e então utilizar CSS para manipular a posição x e y dentro dessa única imagem grande para posicioná-la corretamente onde precisamos.
• começamos a utilizar vários tipos diferentes de geradores de templates, como LESS e SASS para gerar stylesheets, CoffeeScript para gerar Javascript, além do próprio ERB para adicionar conteúdo dinâmico nos templates.

Para resolver essas e outras situações é que foi criado o chamado Asset Pipeline, que é um conjunto de bibliotecas e convenções para resolver o problema de assets da melhor forma possível. O Asset Pipeline sozinho não resolve tudo, ele é um framework para que seja possível integrar diferentes soluções de forma organizada.

Tudo que será explicado neste artigo vale para o Rails 3.2 e superior, existem diferenças importantes nas versões anteriores que não serão tratadas aqui. Leia o Rails Guides, especialmente os Release Notes de cada versão.

Iniciando um projeto Rails

Quando iniciamos um novo projeto com o comando rails new novo_projeto, o primeiro arquivo que você vai querer mexer é o Gemfile:

#1. Original  
group :assets do  
 gem 'sass-rails', '~\> 3.2.3'  
 gem 'coffee-rails', '~\> 3.2.1'

#1. See https://github.com/sstephenson/execjs#readme for more supported runtimes
#2. gem 'therubyracer', :platforms =\> :ruby

gem 'uglifier', '\>= 1.0.3'

end

#1. Recomendado para iniciar  
group :assets do  
 gem 'sass-rails'  
 gem 'compass-rails'

  #1. See https://github.com/sstephenson/execjs#readme for more supported runtimes  
 gem 'therubyracer', :platforms => :ruby

gem 'uglifier'

end

Não vamos entrar na controvérsia agora sobre CoffeeScript. Se você está iniciando, esqueça CoffeeScript por enquanto para não complicar ainda mais. Por outro lado, usar o Compass e particularmente o Compass Rails é algo que nem precisamos discutir já que o Compass provê diversos mixins de Sass muito úteis.

Aliás, se você ainda não conhece SASS, faça a você mesmo um favor e aprenda. Se você entende CSS, não vai ter problemas entendendo Sass, em particular a versão “SCSS” ou “Sassy CSS” que não é mais do que um conjunto acima do CSS3. Lembrando que mesmo escolhendo usar SASS podemos misturar arquivos .css.scss e arquivos convencionais .css no mesmo projeto.

Ao modificar o arquivo Gemfile, lembre-se de executar os seguintes comandos no terminal:

bundle

Para exercitar, vamos criar um simples controller com uma única página dinâmica para entender o que podemos fazer com isso. De volta ao terminal faça o seguinte:

rm public/index.html  
bundle exec rails g controller home index  

O resultado será:

create app/controllers/home_controller.rb 
route get "home/index" 
invoke erb create app/views/home 
create app/views/home/index.html.erb 
invoke test_unit create 
test/functional/home_controller_test.rb 
invoke helper create app/helpers/home_helper.rb 
invoke test_unit create 
test/unit/helpers/home_helper_test.rb 
invoke assets invoke js create app/uploads/javascripts/home.js 
invoke scss create app/uploads/stylesheets/home.css.scss

E para combinar, já que estamos recomendando SCSS, vamos apagar o arquivo app/stylesheets/application.css e criar um novo:

rm app/stylesheets/application.css  
touch app/stylesheets/application.css.scss  

E nesse novo arquivo podemos colocar somente:

@import "compass"  

Outra boa prática é ignorar o diretório public/uploads do repositório Git (você utilizar Git, correto?). Faça o seguinte:

echo "public/uploads" >> .gitignore  

E agora já podemos iniciar o servidor local de Rails e examinar o que temos até agora:

bundle exec rails s  

Processo de Pré-Compilação

Resumidamente, em termos de assets temos os seguintes principais elementos e estrutura:

app  
 assets  
 images  
 rails.png  
 javascripts  
 application.js  
 home.js  
 stylesheets  
 application.css.scss  
 home.css.scss  
 views  
 home  
 index.html.erb  
 layouts  
 application.html.erb  
config  
 application.rb  
public  
 assets  
Gemfile  
Gemfile.lock  

O código fonte do layout app/views/layouts/application.html.erb contém o seguinte:

<!DOCTYPE html>

<title>NovoProjeto</title>
  
 <%= stylesheet_link_tag "application", :media => "all" \>  
 <= javascript_include_tag "application" \>  
 <= csrf_meta_tags %\>

<%= yield %\>

Se você já tinha visto até o Rails 2.x, um layout padrão ERB não é tão diferente. Com o servidor de pé, em ambiente de desenvolvimento, vejamos o HTML gerado ao abrir http://localhost:3000/home/index:

<!DOCTYPE html>

<title>NovoProjeto</title>
  
<link href="/uploads/application.css" media="all" rel="stylesheet" type="text/css">
  
<script src="/uploads/jquery.js?body=1" type="text/javascript"></script>  
<script src="/uploads/jquery_ujs.js?body=1" type="text/javascript"></script>  
<script src="/uploads/home.js?body=1" type="text/javascript"></script>  
<script src="/uploads/application.js?body=1" type="text/javascript"></script>  
<meta content="authenticity_token" name="csrf-param">
  
<meta content="OFmZwwtshevVgcs1DUg56WVIQ8NcJZsri/nUubhEJCk=" name="csrf-token">
# Home#index

Find me in app/views/home/index.html.erb

No HTML gerado, note que os links para os assets apontam todos para /uploads. Além disso note que a chamada javascript_include_tag(“application”) expandiu para 4 javascripts diferentes. Para entender isso, precisamos examinar mais de perto o arquivo app/uploads/javascripts/application.js:

…  
//= require jquery  
//= require jquery_ujs  
//= require_tree .  

Sobre o detalhe do jQuery, todo novo projeto Rails tem declarado gem ‘jquery-rails’ no Gemfile.

Os arquivos application.∗ podendo “∗” ser “js”, “js.coffee”, “css”, “css.scss”, “css.sass”, “js.erb”, “css.erb”, etc. Eles são conhecidos como “Manifestos”. São arquivos “guarda-chuva” que declaram todos os outros arquivos que eles dependem, em ordem, para serem concatenados em um único arquivo ao serem compilados.

No exemplo padrão, no application.js a primeira e segunda linha com require declaram o jquery.js e depois o jquery_ujs.js e a terceira linha com require_tree . manda carregar todos os outros arquivos javascripts no mesmo diretório que, por acaso, tem o home.js criado pelo gerador de controller que usamos antes. Agora vejam novamente o HTML gerado e verá que são exatamente os javascripts carregados na ordem que expliquei, sendo o quarto o próprio conteúdo do arquivo application.js.

Normalmente usar o require_tree . não é exatamente ruim se os javascripts não dependem da ordem de carregamento, mas você provavelmente vai querer declarar explicitamente coisas como plugins de jQuery para garantir que eles estão carregados antes de poder usá-los.

Para explicar como tudo isso funciona é importante pararmos o servidor Rails que subimos antes e reexecutá-lo em modo produçao:

bundle exec rails s e production  

Agora, se tentarmos carregar a mesma URL http://localhost:3000/home/index no browser, receberemos um erro 500 com o seguinte backtrace:

Started GET "/home/index" for 127.0.0.1 at 2012-07-01 03:31:55 -0300  
Connecting to database specified by database.yml  
Processing by HomeController#index as HTML  
 Rendered home/index.html.erb within layouts/application (12.0ms)  
Completed 500 Internal Server Error in 155ms

ActionView::Template::Error (application.css isn't precompiled):  
 2:
 3:

 4: <title>NovoProjeto</title>

5: <%= stylesheet_link_tag "application", :media => "all" \>  
 6: <= javascript_include_tag "application" \>  
 7: <= csrf_meta_tags %\>  
 8:
 app/views/layouts/application.html.erb:5:in `_app_views_layouts_application_html_erb__408740569075721590_70099961775620'  

Este é o sinal que não realizamos um passo importante que deve ser executado toda vez que você realizar uma atualização em produção: pré-compilar os assets. É o processo que lê os arquivos manifesto e realiza a concatenação dos arquivos declarados e sua minificação (utilizando a gem Uglifier). Portanto, precisamos executar o seguinte:

bundle exec rake assets:precompile

Lembrando que antes disso o diretório public/uploads estava originalmente vazio (e em desenvolvimento, você deve garantir que esse diretório esteja sempre vazio, já explicamos porque). Após executar a a pré-compilação, esse diretório terá os seguintes arquivos:

application-363316399c9b02b9eb98cd1b13517abd.js  
application-363316399c9b02b9eb98cd1b13517abd.js.gz  
application-7270767b2a9e9fff880aa5de378ca791.css  
application-7270767b2a9e9fff880aa5de378ca791.css.gz  
application.css  
application.css.gz  
application.js  
application.js.gz  
manifest.yml  
rails-be8732dac73d845ac5b142c8fb5f9fb0.png  
rails.png  

E para entender vejamos o código-fonte do HTML gerado em produção:

<!DOCTYPE html\>

<title>NovoProjeto</title>
  
<link href="/uploads/application-7270767b2a9e9fff880aa5de378ca791.css" media="all" rel="stylesheet" type="text/css">
  
<script src="/uploads/application-363316399c9b02b9eb98cd1b13517abd.js" type="text/javascript"></script>  
<meta content="authenticity_token" name="csrf-param">
  
<meta content="OFmZwwtshevVgcs1DUg56WVIQ8NcJZsri/nUubhEJCk=" name="csrf-token">
# Home#index

Find me in app/views/home/index.html.erb

Compare este HTML com o anterior que analisamos gerado em ambiente de desenvolvimento. Em vez de 1 arquivo CSS e 4 Javascripts, temos apenas 1 CSS e 1 Javascript.

Para entendermos melhor, vejamos o que tem no arquivo public/uploads/manifest.yml:

rails.png: rails-be8732dac73d845ac5b142c8fb5f9fb0.png  
application.js: application-363316399c9b02b9eb98cd1b13517abd.js  
application.css: application-7270767b2a9e9fff880aa5de378ca791.css  

Ou seja, o arquivo application.js é idêntico ao application-363316399c9b02b9eb98cd1b13517abd.js. Se algum dos arquivos declarados no manifesto app/uploads/javascripts/application.js mudar, esse número sufixo irá mudar e o HTML apontará para o novo. Olhando novamente nossa lista de situações que precisam ser solucionadas, que apresentamos no início do arquivo, temos já até aqui a solução de 3 dos pontos:

• o ponto 1 explica o problema que é sempre melhor ter apenas um único arquivo de CSS ou JS do que dezenas deles separados, pois o navegador só precisa ter o peso de pedir um único arquivo (quanto mais arquivos, independente do tamanho, mais tempo vai demorar para a página renderizar). Além disso, graças ao Uglifier teremos esses arquivos “minificados”, ou seja, reescritos de forma a minimizar seu tamanho em bytes sem modificar a lógica da programação. Além disso, o pipeline vai um passo além e tem as versões de todos esses arquivos com extensão “.gz” que significa “gzip”. Se o browser fizer uma requisição dizendo que aceita conteúdo compactado em formato zip, se o web server disser que entende zip, ele pode diretamente enviar a versão do arquivo com extensão “.gz”. No exemplo acima, isso significa enviar um JS de 34kb em vez dos 98kb descomprimidos.
• o ponto 2 explica o problema de quanto assets mudam mas o browser guarda em cache baseado na URL que ele carregou. Se ele pedisse http://localhost:3000/uploads/application.js, mesmo se o JS fosse modificado, o browser não pediria novamente porque a boa prática diz que o web server deveria enviar cabeçalho dizendo para esse tipo de arquivo ficar em cache por 1 ano. Mas como o HTML na realidade pede por http://localhost:3000/uploads/application-363316399c9b02b9eb98cd1b13517abd.js, e se o JS mudar, esse número vai mudar também, não importa mais que esses assets fiquem indefinidamente em cache, pois da próxima vez que precisar dar versão mais nova, o nome do arquivo será completamente diferente do que estava no cache.
• finalmente, o ponto 4 explica sobre os diferente geradores de assets. Implicitamente já podemos ver isso no caso do SASS, onde arquivos com extensão “.css.scss” são convertidos em “.css”.

Para reforçar o ponto 2, vamos adicionar a seguinte função no arquivo app/uploads/javascripts/application.js:

function helloWorld() {  
 console.log("Hello World");  
}  

Agora executamos a pré-compilação novamente:

bundle exec rake assets:precompile  

O que temos no diretório public/uploads será:

application-363316399c9b02b9eb98cd1b13517abd.js  
application-363316399c9b02b9eb98cd1b13517abd.js.gz  
application-4fee97e9e402a9816ab9b3edf7a4c08b.js  
application-4fee97e9e402a9816ab9b3edf7a4c08b.js.gz  
application-7270767b2a9e9fff880aa5de378ca791.css  
application-7270767b2a9e9fff880aa5de378ca791.css.gz  
application.css  
application.css.gz  
application.js  
application.js.gz  
manifest.yml  
rails-be8732dac73d845ac5b142c8fb5f9fb0.png  
rails.png

Como não limpamos o diretório antes, temos a versão antiga e a recente. Compare, a anterior se chamava application-363316399c9b02b9eb98cd1b13517abd.js e a nova com a função de demonstração se chama application-4fee97e9e402a9816ab9b3edf7a4c08b.js. Reiniciando o servidor Rails no ambiente de produção e vendo o novo HTML gerado, verá este trecho:

<script src="/uploads/application-4fee97e9e402a9816ab9b3edf7a4c08b.js" type="text/javascript"></script>

Espero que esse detalhamente deixe bem claro o objetivo do pipeline de pré-compilação e as convenções de nomenclatura e quais problemas ele soluciona. Num artigo que escrevi recentemente chamado Enciclopédia do Heroku explico como mover esses assets pré-compilados para uma conta na Amazon S3, com o objetivo de descarregar processamento do seu servidor de aplicação, servindo a partir de um CDN, o que deve melhorar a experiência do usuário final ao carregar assets de um servidor mais próximo.

Parte 2

O artigo ficou longo, por isso vamos continuar na Parte 2

O host do programa é Scott Hanselman, que na realidade é do mundo .NET, Microsoft, mas que também cobre outras plataformas. Nesse episódio ele estava na RailsConf 2007, em sua cidade natal que é Portland, no Oregon. Ele teve a oportunidade de entrevistar David Heinemeier Hansson e Martin Fowler ao mesmo tempo. Vocês podem ler a transcrição literal da entrevista em PDF.

Eu achei esta uma das melhores entrevistas dos dois e, como sempre, resolvi que devia traduzir. Porém, essa transcrição está muito literal. Ou seja, está exatamente como eles falaram. O problema disso é que o formato está extremamente informal, disperso, quebradiço, por assim dizer. Eu comecei a traduzir mas o texto ficou tão emaranhado que quase no final resolvi jogar tudo fora e começar novamente. Em vez de traduzir ipsis literis como falaram, vou tentar expôr as idéias principais deles de forma mais organizada para que vocês consigam entender. Mesmo assim, recomendo ouvir o podcast, no áudio a conversa faz mais sentido.

HTML e CSS

O primeiro assunto começa quando Scott diz estar cansado de ficar escrevendo tags para criar telas. Ele acha que numa atualidade onde temos efeitos tridimensionais no Linux (com o projeto Beryl), o Mac OS X (que já levou 3D em conta há anos) e o recém-chegado Windows Vista, o visual ‘limitado’ do HTML talvez esteja mostrando sua idade.

David e Martin discordam disso, assim como este humilde tradutor que vos fala. Na realidade HTML e CSS são perfeitos para o trabalho. É um argumento que já foi discutido várias vezes nos últimos anos, mas é inegável que em 10 anos de história, nenhuma outra tecnologia conseguiu fazer frente ao HTML.

Tivemos Applets, o próprio Flash, agora temos tentativas como Apollo, Silverlight. David tem um argumento muito bom: nenhuma dessas ditas ‘alternativas’ apresenta nada de novo. Qual a diferença de um botão em Flash ou um botão em HTML? Absolutamente nenhum, ambos têm os mesmos eventos, fazem as mesmas coisas. A diferença é que em HTML é muito mais simples, padronizado. No fim do dia, um Silverlight talvez tenha efeitos-especiais, enfeites, mas não passa disso: firulas.

No fim do dia, o usuário ainda estará utilizando exatamente os mesmos elementos: vai arrastar o mouse sobre um botão e clicará nele. Vai escolher uma caixa de entrada e digitar seus dados. Vai clicar numa lista e escolher um ítem. Claro, existem os casos extremos, como algum Widget de Mac (ou Gadget, ou Vista), onde você queira ver a planta de sua casa, arrastar os móveis de lugar para visualizar como vai ficar.

Porém, o problema é esse: esse tipo de interface é o caso extremo, a exceção à regra. Somente um caso e centenas. A grande maioria dos casos de aplicação Web é o bom e velho formulário. E foi exatamente para isso que surgiu o HTML e o CSS. Flash pode ser bom para Widgets, não para aplicações Web.

Talvez amanhã, quando tivermos telas multi-touch ou coisas assim, alguém consiga inventar uma maneira completamente nova e muito melhor do que os paradigmas atuais. E o ponto de David é: se isso acontecer, faz sentido ir atrás. Mas enquanto essas coisas não passarem de promessas, não faz sentido segurar a respiração até acontecer. Enquanto isso, HTML e CSS são bons o suficiente para tudo que precisamos hoje.

“Tela Branca”

Outro excelente argumento de David é contra a “Tela Branca”, no sentido de um quadro em branco que você precisa pintar. A tese é que a maioria das pessoas não se dá bem com telas em branco. O problema é que você tem liberdade de fazer qualquer coisa. Nesse sentido, cada novo projeto seria mais uma tela em branco. Antes de Rails tínhamos que refazer as mesmas coisas o tempo todo. Reinventar a roda. Alguns gostam disso, mas não quer dizer que é a maneira correta.

Novamente, esse é o problema com os ditos ‘candidatos’ a substitutos do HTML. O erro deles é achar que a Web precisa ser reiniciada, começar do zero, começar com outra tecnologia em cima de uma tela branca. Onde está a inovação? Porque começar do zero para fazer os mesmos formulários novamente? Apenas para ter uma animação extra desnecessária? Qual o ponto, senão os casos extremos? Onde está o benefício senão aumentar a confusão?

Como uma nota extra: não precisamos de mais ditos ‘substitutos’. David colocou um ponto interessante: as pessoas buscando a Próxima Grande Coisa são Pesquisadores, mas não podemos confundir pesquisa com desenvolvimento do dia-a-dia. Martin completou bem: desses pesquisadores talvez 5% consigam surgir com algo realmente revolucionário, que talvez valha a pena investir. Obviamente, não temos como saber quem são os 95% que são puro lixo, portanto só nos resta investir nos 100% para descobrir. Mas se ele precisasse chutar iria atrás das pessoas que estão fazendo pesquisas mais aprofundadas no assunto da real interação do usuário com o aplicativo. Não somente artesões de novos ‘botões animados’, mas sim aqueles que estão buscando melhorar o contexto de interface de usuário como um todo.

David dá outros bons argumentos. Veja o AJAX, só agora as pessoas descobriram “Puxa, dá para fazer coisas incríveis com JavaScript manipulando dados em tempo real no browser.” Em bom português, todos se sentiram ‘pintos no lixo’, se esbaldaram e já exageraram. Mesmo com coisas simples como Ajax as pessoas ainda tem muito o que aprender. Não precisamos de nada a mais do que isso neste momento.

Quando você dá telas em branco aos desenvolvedores, eles ficam obcecados. Perdem seu tempo criando enfeites e perdem o foco no verdadeiro objetivo: a interação do usuário com a aplicação. Nós ainda estamos longe de esgotar as possibilidades da tríade HTML, CSS e JavaScript. “Precisamos aprender a andar antes de começar a correr” e nesse assunto ainda estamos engatinhando. Se começarmos a correr desde agora ainda acabamos indo na direção errada. Portanto, não, não precisamos de mais telas em branco ainda.

Como nota à parte de mim mesmo, eu diria que o futuro próximo nas interfaces de usuário não será via um novo plugin vetorial ou applet Java. O correto é puro e simplesmente o HTML 5, uma evolução natural do HTML 4 e do XHTML 1.0 que já usamos hoje mas adaptado a aceitar mais eventos, mais propriedades nos elementos que já existem. Muitas das coisas do HTML 5 nós já fazemos hoje, mas para funcionar precisamos embutir quantidades obcenas de JavaScript. A idéia do consórcio formado pela Apple, Mozilla e Opera pode não ser perfeita, mas é uma boa evolução sobre um HTML que não é atualizado significativamente há uma década. Felizmente, parece que os burocratas da W3C finalmente resolveram fazer as peças moverem.

Web Design

Isso me leva a outro assunto interessante e que a maioria está cansado de saber mas continua fazendo errado. O bom e velho “faça o que eu digo, mas não faça o que eu faço.” Nos processos de desenvolvimento padrão de aplicações Web, primeiro a ‘equipe de design’ faz os ‘protótipos’ da aplicação: fazem uma imagem em Photoshop de cada tipo de página. Dezenas de imagens. Depois disso pronto, passa para alguém recortar e montar em tabelinhas dentro do Dreamweaver.

Errado! Esta é a maneira mais equivocada de se considerar em um processo. Como David diz: é péssimo usar Photoshop para prototipar a Web pois são mídias completamente diferentes. Fazer cantos arredondados no Photoshop é algo trivial, em HTML e CSS é horrível. É como pedir para um escultor prototipar em argila e depois a coisa real tem que ser feita em metal. Não dá: o designer precisa estar o mais humanamente próximo do metal, moldar diretamente no material final.

A outra maneira errada: fazer o desenvolvedor começar a codificar antes de saber como ela deve ficar. O problema é que o desenvolvedor fará o mais simples, não o melhor. Pois não há referencial a ele. O pensamento mais comum é “farei de qualquer jeito, depois o designer fará ficar bonito”. Isso não funciona. “Mas o designer deixou rosa, com cantos arredondados e tudo bonitinho, não entendo porque o usuário não consegue usar …”

Na 37signals os web designers começam fazendo algumas poucas páginas diretamente em HTML. Essa é outra vantagem de HTML e CSS: eles possibilitam colocar ferramentas simples diretamente nas mãos dos designers. No fundo, um web designer não é somente alguém para colocar cores bonitas, mas sim para colocar cores úteis. Um bom Web Designer na realidade é um Designer de Interação.

Uma vez que as primeiras páginas estão prontas, logo elas são convertidas para Rails e a partir daí o designer é obrigado a evoluir as páginas diretamente no HTML, no meio de código Ruby. Isso ainda traz outra vantagem: ninguém precisa conjecturar como a aplicação seria: ela já está funcionando. Agora qualquer mudança é sobre a coisa real. E mais: nada dos horrendos Lorem Ipsum como textos para preencher os vazios da página. Agora o designer pode entrar com dados reais.

Integração Contínua: Especificações são Inúteis

E como evitar que os designers quebrem o código? Primeiro, temos que parar de considerar que todo designer é tão burro assim. Existem designers burros, mas para começar estes nem deveriam estar trabalhando. Os outros se dão bem trabalhando dessa maneira, sendo ao mesmo tempo designer e usuário. E para garantir a estabilidade do trabalho: testes. Os desenvolvedores tem que criar a suíte de testes desde o começo para evitar que qualquer um quebre as coisas. Quanto mais a aplicação estiver coberta por testes, mais difícil para um designer quebrar o código.

Como Martin bem lembrou, esse processo de designers e desenvolvedores trabalhando juntos levam a iterações muito curtas, coisa de poucas horas ou poucos dias. As decisões são tomadas e implementadas, num processo de integração contínua. Nesse sentido, não existe a burocracia de voltar atrás, buscar alguma especificação funcional e começar mudando de lá: a aplicação em desenvolvimento é a especificação, principalmente porque, como disse David, não existe nada de funcional em uma especificação. A única coisa que se pode chamar de ‘funcional’ é uma aplicação rodando. Não há necessidade de especular “como será que vai ficar” ela literalmente já é, a questão agora é “como melhorar?”

São os primeiros passos para um desenvolvimento ágil. Em vez de se preocupar com a burocracia, com especificações, com protótipos, com Photoshops, toma-se uma direção ‘designer-primeiro’. Mas não no sentido que os designer vão se trancar durante três meses e sair do quartinho com dúzias de layouts para passar para os desenvolvedores. As iterações são muito mais curtas, o protótipo passa para uma tela real muito rápido. E, como disse antes, é preciso uma boa dose de disciplina e testes para manter tudo rodando e evoluindo ao mesmo tempo. Parte disso, como descreveu Martin, é que o Rails meio que nos força a criar uma aplicação modularizada, que incentiva a criação de testes.

Negando novamente a Tela Branca

Quando começamos um novo projeto, digamos, em Visual C#, a ferramenta nos dá basicamente uma pasta listando as dependências de DLLs e outra pasta simples para códigos-fonte e é só. Uma das coisas que mais agradou Martin no Rails foi o fato dele pré-criar diversas pastas, cada uma com sua função. Rails tenta forçá-lo a fazer a coisa certa dificultando a coisa errada. Para que você faça feio em Rails, é necessário explicitamente querer fazer feio, apagar as pastas que já foram criadas, mover as coisas para lugares errados e assim por diante. Dá tanto trabalho fazer do jeito errado, que ninguém realmente faz isso.

Em .NET existe algo similar em projetos paralelos como o Tree Surgeon, mas a diferença é que na comunidade Rails existe algo no sub-consciente de todos que levam a essa uniformidade. Quando o gerador de Models gera um teste unitário, a idéia é que o desenvolvedor pense “puxa, o gerador criou um arquivo de teste, isso significa que eu deveria estar testando”. Existe motivação para fazer as coisas do jeito certo.

E isso só acontece porque Rails não é uma tela branca. Ela coloca uma série de limitações, ela não o deixa fazer absolutamente tudo que quiser. Pode parecer ilógico, mas a limitação traz mais liberdade de acerto. Isso porque começar numa tela em branco a cada projeto o força a tomar as mesmas decisões várias e várias vezes.

HTML, CSS, Rails todas são tecnologias cujo objetivo é simplificar nossas vidas tomando as decisões repetitivas por nós, limitando nossas possibilidades e com isso aumentando nossa produtividade sem ser difícil de aprender e, principalmente, sem limitar nossa criatividade – como fazem outras tecnologias. Esse é o balanço perfeito.

Comunidade e Senso de Estética

Essa idéia do balanço, das convenções nos leva a outro assunto recorrente: ao senso de estética que parece que todos da comunidade Rails parecem compartilhar. Não basta cuspir código, é preciso saber codificar da mesma forma como um enólogo sabe apreciar um bom vinho.

David diz que uma das habilidades que todo bom programador deve ter é saber dar bons nomes. Veja o recurso de pluralização do Rails. Nós temos essa convenção onde o nome dos Models deve ser no singular e a dos Controllers no plural. Mas não somente acrescentando um “s” no final da palavra. Existe todo um sistema para cobrir praticamente todos os casos da língua inglesa. Houve até um caso famoso na época para ter o plural ‘Octopi’ da palavra singular ‘Octopus’.

É algo que parece fútil, sem sentido, até impensável. Ainda hoje muitos questionam se não teria sido muito mais prático deixar tudo no singular mesmo e pronto. Mas a equipe Rails bateu o martelo: gostamos deste estilo de estética. Eles gastaram um bom tempo para deixar claro que estética importa.

Felizmente para a comunidade Ruby, os primeiros desenvolvedores que adotaram Ruby, como David Thomas, Hal Fulton, eram programadores que também se importavam com o código. E a comunidade se organizou em torno desse mesmo estilo, desse mesmo senso de estética. E o episódio da pluralização do Rails, acabou servindo como um filtro para entrar na comunidade: em vez do programador gastar meses aprendendo Rails para só depois se tocar que na verdade não gosta disso, a pluralização está bem na cara, é uma das primeiras coisas que se vê. Então esse principiante pode escolher imediatamente continuar ou pular fora. Se ele tiver o mesmo estilo, o mesmo nível cultural do resto da comunidade Ruby, vai entender o recurso e vai gostar de Rails.

A idéia não é excluir as pessoas porque gostamos, mas porque podemos: você não vai andar nesta casa se não respeitar esses valores, ou pelo menos se não aprender a apreciá-los.

Alpha Geeks

Finalmente chegamos numa parte mais ‘política’ da discussão. Porque eles começaram dizendo, “o que você acha que tornou .NET popular?”, bem, a Microsoft disse “Esta será a próxima grande coisa.” E o que tornou Java popular? Bem, a IBM e a Sun disseram a mesma coisa. E Ruby? Não há nenhuma corporação por trás dela.

Ruby e Rails cresceram por mérito próprio. Nenhuma grande empresa precisou investir em seu marketing. 37signals? Uma empresa de uma dúzia de pessoas. ThoughtWorks? 800 pessoas. Nada tão extraordinário quanto uma Microsoft com dezenas de milhares de pessoas espalhadas pelo globo.

E falando na ThoughtWorks, o que Martin nos revela é interessante. Ele mesmo diz que sua empresa não é nenhuma mega-corporação. Mesmo assim, quando .NET saiu, eles investiram pesado nele, fizeram diversos projetos. O que eles têm acompanhado é que a demanda pro projetos Java estagnou: não sobe nem desce. Porém as de .NET estão caindo mas Ruby já representa 40% dos projetos da empresa. Ele é o primeiro a dizer que ainda não sabe se isso é só algo momentâneo ou se estamos diante de uma tendência sólida. Mas é algo a se considerar.

Antes de falar na Microsoft, vamos falar dos Alpha Geeks. Claro, Ruby ainda é apenas um pequeno ponto comparado à larga escala de milhões de desenvolvedores Java e .NET o importante não é apenas o número absoluto de pessoas. O problema é que os chamados ‘Alpha Geeks’ são muito menos, e eles estão migrando de Java e .NET para Ruby e outras linguagens dinâmicas. Quem são esses Alpha Geeks? São os formadores e opinião, são os líderes, os cabeças das comunidades, aqueles que influenciarão as próximas grandes coisas.

O fato dos projetos de .NET estarem em declínio, no exemplo de ThoughtWorks, é uma indicação. É a mesma coisa com os movimentos Ágeis. Se um bom desenvolvedor se vê preso a uma empresa que o obriga a usar processos antiquados waterfall, só lhe resta abandonar essa empresa e ir atrás de alguma outra menor que use XP, por exemplo. Muitas pessoas chegam no David para dizer, “eu larguei meu trabalho por causa de Java. Eu simplesmente não gosto de trabalhar num ambiente onde só usam essas ferramentas. Então preferi pegar me tornar um freelance para trabalhar com Ruby on Rails. Estou muito mais feliz agora.”

Mas eles deixam claro uma coisa: isso não quer dizer que Java seja ruim. Muito pelo contrário, eles não desgostam de JRuby. Eles consideram que foi um movimento bastante acertado da Sun ter contratado o pessoal do JRuby e ter investido nesse projeto a ponto de surgir um produto tão bom que já consegue rodar aplicações complexas escritas em Rails. Resta saber se a Microsoft vai pelo mesmo caminho com o .NET.

Hidra

E voltamos ao assunto Microsoft. Eles gastam algum tempo conjecturando. O maior problema para a Microsoft é que ela fez tantas coisas ruins que perdeu a boa reputação. Nenhum deles considera que dentro da empresa Microsoft exista indivíduos que sejam verdadeiramente maus. Mas a política da corporação como um todo não está ajudando. Eles filosofam no sentido de que as pessoas podem ser boas pessoas para se conversar, tomar uma cerveja, mas no final são suas atitudes que contam quando alguém publica uma notícia dizendo que o Linux está infringindo não sei quantas patentes.

E o problema para ela é que uma ação má apaga todas as boas ações anteriores. Perdendo a reputação, mesmo tendo coisas realmente interessantes como LINQ, as novas ferramentas de Workflow e tudo mais, mesmo assim a comunidade vai começar a diminuir, os Alpha Geeks vão migrar para outras tecnologias. Talvez seja o que Paul Graham quis dizer quando afirmou que a Microsoft estava morta, no sentido de que ela não é mais perigosa porque perdeu a relevância. Quem sabe?

O problema da Microsoft em especial, é que ela é muito grande. Quem faz todas essas más ações? Todos concordam que não se pode colocar a culpa de tudo no Bill. Não é ele diretamente quem faz cada uma dessas coisas. O problema é que eles estão sem direção, estão sem líderes. E nesse sentido eles se parecem com uma Hidra. E é por isso que muita gente não confia neles: enquanto uma pessoa lá pode estar sorrindo, outra na mesma empresa o está apunhalando pelas costas.

Como eu disse antes, Scott, o entrevistador, está na folha de pagamento da Microsoft, por isso é uma situação estranha. Ele não pode ser hiperbólico sobre a Microsoft nem pode bater nela. De qualquer forma tentou conciliar: será que não adiantaria para a Microsoft fazer a mesma coisa que pessoas como David e Martin? Sair pelo mundo, em conferências, dizendo as coisas boas que tem. Mas, David, afiado como sempre, deu a última rasteira: “não basta dizer ao mundo que você é bom, você precisa fazer coisas boas para ser considerado bom.”

Nós julgamos as pessoas pelos seus atos, não pelo que elas falam. Em um determinado momento, o estilo selvagem e monopolista funcionou muito bem. Eles fizeram bilhões de dólares com essa estratégia. Mas agora não funciona mais. Esse tipo de ‘tradição’ não se muda do dia pra noite: tem pessoas que trabalham lá há mais de 15 anos. Portanto é muito difícil voltar aos trilhos, e eles precisam fazer algo rápido.