Tres motores, no uno

Los tres

La conclusión operativa: escribe para el mínimo común, que en la práctica significa mirar qué soporta la versión de Safari que corresponde a los macOS que quieres soportar, y el motor de las distribuciones de Linux más conservadoras que tengas en el punto de mira.

Qué difiere de verdad

Y aquí está el matiz, porque la mayoría de las diferencias no son las que la gente teme:

El resumen honesto: el problema no es que el JavaScript no funcione, es que el CSS se vea distinto. Y eso desplaza el esfuerzo de las pruebas: no hace falta probar la lógica en tres motores, hace falta mirar la interfaz en tres motores.

Cómo se prueba

Y esto es lo incómodo de la fase: hace falta acceso a las tres plataformas. No hay atajo — el nivel 46.3 ya dijo que la compilación cruzada no vale, y lo mismo aplica a la verificación visual.

Las opciones, de más a menos accesible:

• Máquinas virtuales para Windows y Linux. Funciona bien, y para macOS no es una opción legítima.
• Una máquina de cada, si el proyecto lo justifica.
• Y en el peor caso, alguien que pruebe. Un usuario con la plataforma que te falta y unas capturas de pantalla resuelven bastante.

Y una comprobación barata que ayuda mucho sin tener las tres: abrir tu frontend en el navegador correspondiente al motor de cada plataforma —el navegador basado en webkit para aproximar macOS y Linux, uno basado en Chromium para Windows— no es idéntico y detecta la mayoría de los problemas de CSS.

Reducir la superficie

Tres decisiones que hacen que las diferencias importen menos:

• No usar funciones de CSS recién salidas sin comprobar. Y hay herramientas que avisan de qué es soportado en qué versiones.
• Usar los mecanismos nativos de Tauri en vez de las API del navegador cuando existan: diálogos, portapapeles, notificaciones, ficheros. Todo lo de la fase VIII.
• Y no ajustar la interfaz al píxel. Una disposición que tolera que un texto ocupe un diez por ciento más sobrevive a los tres motores; una ajustada exactamente, no.