Linux es la factura grande
Por qué WebKitGTK es la plataforma que marca el mínimo común: versiones congeladas por distribución, los problemas de gráficos con controladores propietarios, y qué se está cocinando entre CEF y Servo.
El problema no es WebKit, es el calendario
WebKitGTK es el puerto de WebKit al conjunto de herramientas GTK, y es un proyecto serio con gente competente detrás. El problema no es su calidad: es quién decide qué versión ejecuta tu usuario.
En macOS lo decide Apple con las actualizaciones del sistema. En Windows lo decide Microsoft con un componente que se actualiza solo. En Linux lo decide cada distribución, una por una, y las distribuciones de soporte largo —que son justo las que usan las empresas y los usuarios conservadores— congelan versiones durante años a propósito. Esa es su promesa de valor.
El resultado práctico:
Fíjate en la última fila, que es la trampa: desarrollas en la distribución más moderna y publicas para la más antigua. En las otras dos plataformas ese sesgo también existe, pero es de meses; aquí puede ser de años.
Los gráficos, y el patrón de fallo más común
La familia de problemas más reportada en Linux no es de CSS: es de composición y de aceleración por hardware. El patrón típico es una ventana en negro, la interfaz que parpadea, artefactos al redimensionar, o un rendimiento de animación muy por debajo de lo esperado.
La causa casi siempre está en la interacción entre el renderizador de WebKitGTK y el controlador de gráficos concreto de la máquina. Los controladores propietarios de tarjetas dedicadas son los que más ruido dan, y no porque estén rotos: porque el conjunto de formatos de búfer que ofrecen y el que el renderizador espera no siempre coinciden.
El diagnóstico es siempre el mismo y conviene tenerlo a mano:
# El primer paso ante cualquier fallo gráfico en Linux: desactivar la# aceleración y ver si el problema desaparece. Si desaparece, ya sabes# de qué familia es, aunque todavía no sepas la causa exacta.WEBKIT_DISABLE_DMABUF_RENDERER=1 ./tu-aplicacion# Si el problema persiste, es de tu interfaz y no del renderizador.Que esa variable de entorno sea conocimiento tribal necesario es, en sí mismo, un dato sobre el estado de la plataforma. Documéntala en tu propio manual de instalación: te va a ahorrar informes de fallo.
Qué política de soporte tiene sentido
No hay una respuesta única, pero sí tres posturas coherentes. Lo incoherente es no elegir.
Soporte declarado y estrecho. Nombras dos distribuciones y sus versiones, pruebas en esas, y lo dices en tu documentación. Todo lo demás es «puede funcionar». Es la postura más honesta para un equipo pequeño y la que menos decepciona.
Empaquetado autocontenido. Distribuyes en un formato que lleva sus propias dependencias, de modo que la versión del motor sea la que tú metes y no la de la máquina. Reduce el problema de forma sustancial —y a cambio recuperas parte del peso que la tesis del nivel 3.1 había ahorrado, y algo del trabajo de parcheo—. El nivel 63 entra en los formatos y sus compromisos.
Sin soporte de Linux. Perfectamente legítimo si tu producto no tiene ahí usuarios. Decirlo por adelantado es mejor que enviar algo que se rompe.
La postura que no funciona es la de por defecto: publicar tres paquetes de Linux porque el empaquetador los genera, no probar en ninguno, y descubrir el problema por los informes de los usuarios.
Lo que se está cocinando
Dos vías, y conviene entender su estado real para no planificar sobre ellas.
CEF, el marco de Chromium empotrable. La idea es poder elegir Chromium como motor en Linux en lugar de WebKitGTK, quitando de golpe el problema del calendario. Es el camino más obvio y también el que contradice la tesis del framework: si empaquetas Chromium en Linux, en esa plataforma tienes el tamaño y la responsabilidad de parcheo de un motor empaquetado. Es un compromiso razonable —consistencia donde más falta hace, ligereza donde el motor del sistema es bueno— y hay trabajo empezado, pero no una fecha.
Servo. El motor escrito en Rust, con la coherencia evidente de ser del mismo lenguaje que el core. Está muchísimo más lejos: es un motor joven al que le falta demasiada superficie de la plataforma web para ejecutar una aplicación real hoy. Es una vía interesante a varios años vista, no una alternativa.
La lectura para planificar es simple: construye para el mundo de hoy, con WebKitGTK y sus rodeos. Si alguna de las dos vías madura, será una mejora que llega sola; ninguna es un plan sobre el que apoyar decisiones.