Voltar para o blog
BunAppleFrontendPerformance

MacBook Pro com tela touch: o que muda para quem usa Bun

29 de outubro de 2026·6 min de leitura·Diego Horvatti

A Apple passou anos dizendo que tela touch em notebook não fazia sentido, e agora ela vende um MacBook Pro com tela PROLED XDR e touch. O MacBook Pro com tela touch é a notícia do mês para quem vive dentro de um Mac. Eu uso Bun no dia a dia, então a pergunta que me interessa é simples: isso muda alguma coisa no meu código ou é só uma tela mais bonita?

Spoiler: muda menos do que o marketing sugere e mais do que os céticos admitem.

O que a Apple anunciou

O resumo é este: o MacBook Pro ganhou uma nova geração de tela, chamada PROLED XDR, e a tela agora aceita toque. A linha XDR já era a aposta da Apple em brilho alto e contraste para quem trabalha com imagem. A novidade é o painel novo somado ao toque, coisa que o Mac nunca teve de fábrica.

Não vou repetir ficha técnica aqui. Ela está na página da Apple, e número de brilho em nit não compila seu projeto. O que me interessa são duas consequências práticas:

  • Uma parte dos seus usuários vai abrir seu app web num Mac com o dedo.
  • Muita gente vai trocar de máquina e esperar que tudo fique mais rápido sozinho.

As duas tocam direto em quem escreve TypeScript e roda Bun.

Notebook novo deixa o Bun mais rápido?

Deixa, mas pelo motivo errado. Todo upgrade de Mac vem com aquele ritual: você abre o terminal, roda bun install e fica feliz porque terminou antes. Só que o Bun já era rápido na máquina antiga. O gargalo do seu dia raramente está aí.

Faz o teste. Mede o que você realmente espera todo dia:

# instalação limpa
rm -rf node_modules && time bun install

# sua suíte de testes
time bun test

# o build de produção
time bun run build

No meu caso, num monorepo médio, o bun install com cache quente já levava poucos segundos. O que demorava era o type-check do TypeScript e o build do app web. Máquina nova reduz isso um pouco. Ela não resolve um tsconfig que checa a pasta inteira, nem um teste que sobe banco de verdade a cada arquivo.

Hardware novo esconde código lento. Ele não conserta.

Se o seu fluxo está lento, olha primeiro o que dá para cortar. Testes que podem rodar em paralelo, include do TypeScript mais enxuto, cache de build que ninguém configurou. Isso funciona no Mac novo, no velho e no CI, que é onde você paga por minuto.

Tela touch no Mac: o que muda no seu frontend

Aqui está a parte que vale o artigo. Por anos, muita gente escreveu CSS assim:

/* "desktop = mouse" */
@media (min-width: 1024px) {
  .card:hover .acoes { opacity: 1; }
  .acoes { opacity: 0; }
}

A lógica era: tela grande, então tem mouse, então tem hover. Com um Mac de tela touch, essa premissa cai de vez. Na verdade ela já estava errada desde os notebooks Windows com toque e o iPad com teclado, mas o Mac era o refúgio de quem ignorava isso.

O usuário toca no card, não existe hover, e as ações ficam invisíveis. O bug não aparece no seu Mac de trabalho, só na máquina de outra pessoa. O pior tipo de bug.

O jeito certo é perguntar pela capacidade, não pelo tamanho:

.acoes { opacity: 1; }

@media (hover: hover) and (pointer: fine) {
  .acoes { opacity: 0; }
  .card:hover .acoes { opacity: 1; }
}

Agora o hover vira melhoria para quem tem mouse, e quem toca vê os botões sempre. Repara que a regra padrão é a que funciona para todo mundo.

No JavaScript vale o mesmo raciocínio. Se você ainda tem mousedown e touchstart duplicados no código, troca por Pointer Events:

el.addEventListener('pointerdown', (e) => {
  if (e.pointerType === 'touch') {
    // área de toque maior, sem tooltip
  }
  iniciarArraste(e)
})

Um evento só, três tipos de entrada: mouse, caneta e dedo. Menos código e menos bug.

Outros pontos que eu revisaria logo:

  • Alvos de toque. Botão de 24px funciona com mouse e irrita com o dedo. Mire em uns 44px de área clicável.
  • Tooltips. Se a informação só aparece no hover, ela não existe para quem toca.
  • Gestos. Arrastar com o dedo pode brigar com o scroll da página. touch-action: none só onde precisa, nunca no body.

Como testar isso com Bun sem ter o Mac novo

Você não precisa comprar a máquina para validar. O Bun serve HTML direto, com hot reload, o que deixa esse tipo de teste bem rápido:

bun ./index.html

Com o servidor rodando, abre o DevTools do Chrome, liga a emulação de dispositivo e ativa o modo touch. A media query (hover: hover) passa a responder como numa tela de toque. Para ter certeza, testa no celular pela rede local. É o teste mais barato que existe.

Se você quer travar isso no CI, dá para escrever um teste com Playwright simulando toque e rodar com o Bun. Algo assim:

import { test, expect } from '@playwright/test'

test.use({ hasTouch: true, viewport: { width: 1512, height: 982 } })

test('ações do card visíveis sem hover', async ({ page }) => {
  await page.goto('http://localhost:3000')
  await expect(page.locator('.card .acoes').first()).toBeVisible()
})

Repara no viewport: tamanho de notebook, com toque. Esse é justamente o caso que a sua suíte provavelmente nunca cobriu.

Tela HDR e cor: um detalhe que pouca gente olha

Tela XDR mostra cor e brilho que a maioria dos monitores não alcança. Para dashboards, apps de foto e qualquer coisa visual, isso tem dois efeitos.

O primeiro: imagem com perfil de cor errado fica mais estranha numa tela boa. Se o seu pipeline de imagens remove o perfil ICC para economizar bytes, o vermelho da marca pode sair diferente do que o designer aprovou.

O segundo: o CSS já tem color(display-p3 ...) e a media query (dynamic-range: high). Dá para oferecer uma cor mais viva para quem tem tela capaz, sem quebrar para quem não tem:

.destaque { color: #e63946; }

@supports (color: color(display-p3 1 0 0)) {
  .destaque { color: color(display-p3 0.95 0.2 0.25); }
}

É um detalhe. Mas é o tipo de detalhe que separa produto caprichado de produto que só funciona.

Vale trocar de máquina por causa disso?

Minha opinião honesta: se o seu Mac atual é Apple Silicon e aguenta o seu dia, não. O ganho em bun install e bun test vai ser de segundos, e você já não esperava muito por eles. O toque é interessante, mas ninguém programa encostando o dedo na tela. Seu braço desiste em dez minutos, e a tela vira um museu de digitais.

Se você ainda está num Intel, aí a conversa muda, e o motivo é o chip, não a tela.

O que eu faria hoje, independente de comprar: abrir o projeto, buscar todo :hover e todo mousedown e perguntar se aquilo funciona com o dedo. Esse ajuste vale para Mac, Windows, iPad e celular. É o tipo de melhoria que custa uma tarde e dura anos.

A tela nova é bonita. O que garante que seu app funciona nela é código que não supõe nada sobre quem está do outro lado. É assim que eu tento construir os projetos que mantenho.

Resumo para o LinkedIn

A Apple vende agora um MacBook Pro com tela touch, e o seu `:hover` pode ter acabado de quebrar.

Por anos a gente escreveu CSS achando que tela grande vinha sempre com mouse. Essa premissa caiu de vez.

O usuário toca no card, o hover não existe, e os botões ficam invisíveis. O bug não aparece no seu Mac, só no Mac de outra pessoa.

A correção é perguntar o que o aparelho sabe fazer, não o tamanho da tela: `@media (hover: hover)`, Pointer Events e alvos de toque de 44px.

E sobre trocar de máquina pelo Bun: o `bun install` já era rápido. Hardware novo esconde código lento, mas não conserta.

Escrevi como testar tudo isso com Bun sem precisar comprar o Mac novo. O link está nos comentários.

#Bun #Frontend #CSS #WebDev #TypeScript