O browser de hoje faz sozinho muito mais do que pensas.

Coisas que antes precisavam de JavaScript

Muitos componentes que escrevíamos à mão são hoje HTML e CSS nativos, suportados por todos os principais browsers. Menos código significa menos bugs, menos coisas para manter e páginas mais leves.

// Fundo, foco e tecla Esc: tudo à mão
modal.classList.add('is-open');
document.body.style.overflow = 'hidden';
lastFocus = document.activeElement;
modal.querySelector('button').focus();
document.addEventListener('keydown', onEsc);
// ...mais uma "focus trap" para não sair com Tab

<dialog id="conferma">
  <p>Queres mesmo sair?</p>
  <form method="dialog">
    <button>Fechar</button>
  </form>
</dialog>

<script>conferma.showModal();</script>

button.addEventListener('click', () => {
  menu.classList.toggle('open');
});
document.addEventListener('click', (e) => {
  if (!menu.contains(e.target) && e.target !== button) {
    menu.classList.remove('open');
  }
});
// ...e outro listener para a tecla Esc

<button popovertarget="menu">Menu</button>

<div id="menu" popover>
  <a href="/">Início</a>
  <a href="/radar/">Jogos e notícias</a>
</div>

new ResizeObserver(([entry]) => {
  card.classList.toggle(
    'is-wide',
    entry.contentRect.width > 480
  );
}).observe(card);

.card-wrap {
  container-type: inline-size;
}

@container (width > 30rem) {
  .card { grid-template-columns: 1fr 2fr; }
}

checkbox.addEventListener('change', () => {
  card.classList.toggle(
    'is-selected',
    checkbox.checked
  );
});

.card:has(input:checked) {
  border-color: var(--accent);
}

// era preciso um pré-processador
.card {
  padding: 1rem;
  &:hover { border-color: violet; }
  .title { font-weight: 700; }
}

/* funciona assim no browser */
.card {
  padding: 1rem;
  &:hover { border-color: violet; }
  & .title { font-weight: 700; }
}

Velocidade: mede-se, não se adivinha

A Google mede a experiência real dos utilizadores com três métricas, os Core Web Vitals. Estes são os valores considerados «bons», a atingir em pelo menos 75% das visitas.

• LCP

  ≤ 2,5 s

  Largest Contentful Paint. Quanto tempo demora a aparecer o conteúdo principal da página.

• INP

  ≤ 200 ms

  Interaction to Next Paint. A rapidez com que a página responde a cliques, toques e teclas. Substituiu o FID em março de 2024.

• CLS

  ≤ 0,1

  Cumulative Layout Shift. Quanto o layout «salta» enquanto a página carrega.

Como lá chegar

• Imagens leves e com dimensões. AVIF ou WebP, sempre com width e height declarados: assim o layout não salta.
• Fontes self-hosted. Só os pesos que usas, com font-display: swap. Nenhum pedido a servidores externos.
• JavaScript só quando é preciso. Os três minijogos deste site só são descarregados quando estão prestes a entrar no ecrã.
• Põe em pausa o que não se vê. Uma animação fora do ecrã gasta bateria para nada: o IntersectionObserver para-a e o requestAnimationFrame retoma-a.
• Mede em dispositivos reais. O PageSpeed Insights mostra os dados de utilizadores reais; o painel Performance do Chrome diz-te onde se perde tempo.

Acessibilidade: já não é um extra

A caixa de ferramentas

Não é preciso ir atrás de todas as novidades. Estas ferramentas cobrem o fluxo completo, do primeiro ficheiro ao lançamento.

• Escrever

  Um dev server que arranca num instante e tipos que encontram os erros antes do browser.

  Vite, TypeScript

• Qualidade

  Regras automáticas: as discussões sobre estilo acabam antes de começar.

  ESLint ou Biome, Prettier

• Testes

  Testes unitários para a lógica, testes end-to-end que clicam na página como faria uma pessoa.

  Vitest, Playwright

• Lançamento

  Cada alteração passa pelos testes automáticos e tem uma pré-visualização com um link para partilhar antes de ir para o ar.

  Git, GitHub Actions, Cloudflare Pages ou Netlify

• Observar

  Depois do lançamento, o trabalho continua: velocidade real e erros dos utilizadores, não só os do teu computador.

  PageSpeed Insights, Sentry

Trabalhar com a IA sem perder o controlo

Os assistentes de código aceleram muito o trabalho. Mas o código que vai para o ar continua a ser teu, com os seus bugs e as suas vulnerabilidades.

• Revê cada linha. Se não consegues explicar o que faz um pedaço de código, ele não está pronto para produção.
• Confirma que os pacotes existem mesmo. Num estudo com 16 modelos, cerca de um em cada cinco pacotes sugeridos não existia. E há quem registe precisamente esses nomes inventados, com código malicioso lá dentro: chama-se slopsquatting.
• Nada de segredos nos prompts. Chaves de API, palavras-passe e dados de clientes não se colam num chat.
• Pede os testes juntamente com o código. E corre-os: um teste que nunca viste falhar não prova nada.
• Usa-a para perceber, não só para escrever. «Explica-me porquê» ensina mais do que «escreve-me isto».