BunAppleFrontendRendimiento

MacBook Pro con pantalla táctil: qué cambia para quien usa Bun

29 de octubre de 2026·6 min de lectura·Diego Horvatti

Apple pasó años diciendo que una pantalla táctil en un portátil no tenía sentido, y ahora vende un MacBook Pro con pantalla PROLED XDR y táctil. El MacBook Pro con pantalla táctil es la noticia del mes para quien vive dentro de un Mac. Yo uso Bun a diario, así que la pregunta que me interesa es simple: ¿esto cambia algo en mi código o es solo una pantalla más bonita?

Spoiler: cambia menos de lo que sugiere el marketing y más de lo que admiten los escépticos.

Qué anunció Apple

El resumen es este: el MacBook Pro estrena una nueva generación de pantalla, llamada PROLED XDR, y ahora la pantalla acepta toque. La línea XDR ya era la apuesta de Apple por el brillo alto y el contraste para quien trabaja con imagen. La novedad es el panel nuevo sumado al toque, algo que el Mac nunca tuvo de fábrica.

No voy a repetir la ficha técnica aquí. Está en la página de Apple, y una cifra de brillo en nits no compila tu proyecto. Lo que me interesa son dos consecuencias prácticas:

Una parte de tus usuarios va a abrir tu app web en un Mac con el dedo.
Mucha gente va a cambiar de máquina y esperar que todo vaya más rápido solo.

Las dos afectan directamente a quien escribe TypeScript y usa Bun.

¿Un portátil nuevo hace que Bun sea más rápido?

Sí, pero por el motivo equivocado. Cada cambio de Mac viene con el mismo ritual: abres la terminal, ejecutas bun install y te alegras porque terminó antes. Pero Bun ya era rápido en la máquina vieja. El cuello de botella de tu día casi nunca está ahí.

Haz la prueba. Mide lo que de verdad esperas cada día:

# instalación limpia
rm -rf node_modules && time bun install

# tu suite de tests
time bun test

# el build de producción
time bun run build

En mi caso, en un monorepo mediano, bun install con la caché caliente ya tardaba pocos segundos. Lo que tardaba era el type-check de TypeScript y el build de la app web. Una máquina nueva reduce eso un poco. No arregla un tsconfig que revisa la carpeta entera, ni un test que levanta una base de datos real en cada archivo.

El hardware nuevo esconde el código lento. No lo arregla.

Si tu flujo es lento, mira primero qué puedes recortar. Tests que pueden correr en paralelo, un include de TypeScript más ajustado, una caché de build que nadie configuró. Esto funciona en el Mac nuevo, en el viejo y en el CI, que es donde pagas por minuto.

Pantalla táctil en el Mac: qué cambia en tu frontend

Aquí está la parte que vale el artículo. Durante años, mucha gente escribió CSS así:

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

La lógica era: pantalla grande, entonces hay mouse, entonces hay hover. Con un Mac con pantalla táctil, esa premisa se cae del todo. En realidad ya estaba mal desde los portátiles Windows táctiles y el iPad con teclado, pero el Mac era el refugio de quien lo ignoraba.

El usuario toca la tarjeta, no existe hover y las acciones quedan invisibles. El bug no aparece en tu Mac de trabajo, solo en la máquina de otra persona. El peor tipo de bug.

Lo correcto es preguntar por la capacidad, no por el tamaño:

.acoes { opacity: 1; }

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

Ahora el hover es una mejora para quien tiene mouse, y quien toca ve los botones siempre. Fíjate en que la regla por defecto es la que funciona para todos.

En JavaScript vale el mismo razonamiento. Si todavía tienes mousedown y touchstart duplicados en el código, cámbialos por Pointer Events:

el.addEventListener('pointerdown', (e) => {
  if (e.pointerType === 'touch') {
    // área táctil más grande, sin tooltip
  }
  iniciarArraste(e)
})

Un solo evento, tres tipos de entrada: mouse, lápiz y dedo. Menos código y menos bugs.

Otros puntos que yo revisaría pronto:

Áreas táctiles. Un botón de 24px funciona con mouse y molesta con el dedo. Apunta a unos 44px de área clicable.
Tooltips. Si la información solo aparece con hover, no existe para quien toca.
Gestos. Arrastrar con el dedo puede chocar con el scroll de la página. touch-action: none solo donde haga falta, nunca en el body.

Cómo probar esto con Bun sin tener el Mac nuevo

No necesitas comprar la máquina para validarlo. Bun sirve HTML directamente, con hot reload, y eso hace que este tipo de prueba sea muy rápida:

bun ./index.html

Con el servidor corriendo, abre las DevTools de Chrome, activa la emulación de dispositivos y el modo táctil. La media query (hover: hover) pasa a responder como en una pantalla táctil. Para estar seguro, prueba en el móvil por la red local. Es la prueba más barata que existe.

Si quieres asegurarlo en el CI, puedes escribir un test con Playwright simulando toque y ejecutarlo con Bun. Algo así:

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

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

test('acciones de la tarjeta visibles sin hover', async ({ page }) => {
  await page.goto('http://localhost:3000')
  await expect(page.locator('.card .acoes').first()).toBeVisible()
})

Fíjate en el viewport: tamaño de portátil, con toque. Ese es justo el caso que tu suite probablemente nunca cubrió.

Pantalla HDR y color: un detalle que poca gente mira

Una pantalla XDR muestra colores y brillo que la mayoría de los monitores no alcanza. Para dashboards, apps de fotos y cualquier cosa visual, esto tiene dos efectos.

El primero: una imagen con el perfil de color equivocado se ve más rara en una buena pantalla. Si tu pipeline de imágenes elimina el perfil ICC para ahorrar bytes, el rojo de la marca puede salir distinto del que aprobó el diseñador.

El segundo: CSS ya tiene color(display-p3 ...) y la media query (dynamic-range: high). Puedes ofrecer un color más vivo a quien tiene una pantalla capaz, sin romper nada para quien no la tiene:

.destaque { color: #e63946; }

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

Es un detalle. Pero es el tipo de detalle que separa un producto cuidado de uno que solo funciona.

¿Vale la pena cambiar de máquina por esto?

Mi opinión honesta: si tu Mac actual es Apple Silicon y aguanta tu día, no. La ganancia en bun install y bun test será de segundos, y ya no esperabas mucho por ellos. El toque es interesante, pero nadie programa tocando la pantalla con el dedo. Tu brazo se rinde en diez minutos y la pantalla se convierte en un museo de huellas.

Si todavía estás en un Intel, ahí la conversación cambia, y el motivo es el chip, no la pantalla.

Lo que yo haría hoy, compres o no: abrir el proyecto, buscar cada :hover y cada mousedown y preguntarme si eso funciona con el dedo. Este ajuste vale para Mac, Windows, iPad y móvil. Es el tipo de mejora que cuesta una tarde y dura años.

La pantalla nueva es bonita. Lo que garantiza que tu app funcione en ella es un código que no supone nada sobre quién está al otro lado. Así intento construir los proyectos que mantengo.

Resumen para LinkedIn

Apple ahora vende un MacBook Pro con pantalla táctil, y tu `:hover` puede haberse roto.

Durante años escribimos CSS pensando que una pantalla grande siempre venía con mouse. Esa premisa se cayó del todo.

El usuario toca la tarjeta, el hover no existe y los botones quedan invisibles. El bug no aparece en tu Mac, solo en el Mac de otra persona.

La solución es preguntar qué sabe hacer el dispositivo, no el tamaño de la pantalla: `@media (hover: hover)`, Pointer Events y áreas táctiles de 44px.

Y sobre cambiar de máquina por Bun: `bun install` ya era rápido. El hardware nuevo esconde el código lento, pero no lo arregla.

Escribí cómo probar todo esto con Bun sin comprar el Mac nuevo. El enlace está en los comentarios.

#Bun #Frontend #CSS #DesarrolloWeb #TypeScript