Zebkit permite a los desarrolladores integrar los componentes Blink, V8, PDFium y FFmpeg de Chromium como una librería compartida en lugar de un entorno de ejecución completo. Este enfoque permite que una aplicación anfitriona mantenga su propio bucle de eventos nativo, ventanas y kit de herramientas, mientras añade vistas web como hijos de su propia interfaz de usuario o como marcos fuera de pantalla.
La arquitectura de Zebkit
El creador del proyecto, Riiiiichard, describe Zebkit como una forma de añadir capacidades web a un programa de la misma manera que se añadiría una librería como SQLite. Proporciona los componentes del motor principal —Blink para el renderizado, V8 para JavaScript, PDFium para el manejo de PDF y FFmpeg para multimedia— como una única librería que se vincula con el código nativo.
A diferencia de Electron, que empaqueta la aplicación dentro de su propio entorno y empaquetado, Zebkit permite que la aplicación anfitriona conserve su propio bucle de eventos y ventanas. El motor puede integrarse como una ventana, como un hijo de una ventana existente (como X11, NSView o HWND) o como un componente fuera de pantalla donde la librería devuelve los marcos a la aplicación para que los dibuje.
Comparaciones de rendimiento y tamaño
Riiiiichard informa que Zebkit ofrece mejoras significativas de eficiencia sobre la versión más reciente de Electron en Linux. Específicamente, es un 34% más pequeño (62 MB comprimidos), presenta un tiempo de inicio en frío de 2.3 segundos en comparación con los 6.6 segundos de Electron, y utiliza un 29% menos de memoria para las páginas manteniendo la misma velocidad de DOM y JavaScript.
La reducción de tamaño se logra mediante opciones de compilación específicas que desactivan funciones innecesarias. Sin embargo, el creador señala que ciertos componentes como WebRTC y la reproducción de vídeo deben permanecer porque Blink depende de ellos y la mayoría de las aplicaciones requieren soporte de multimedia.
Discusión de la comunidad y compensaciones
Los comentaristas en Hacker News discutieron cómo Zebkit difiere del Chromium Embedded Framework (CEF). Un comentarista, escribiendo como torginus, señaló que aunque CEF se utiliza ampliamente para vestíbulos de juegos y superposiciones, a menudo mantiene Chrome 'vanilla', lo que dificulta la actualización a nuevas versiones. En contraste, el enfoque más granular de Zebkit puede permitir optimizaciones más específicas, aunque queda por ver cómo maneja la complejidad de esos cambios.
Otros participantes plantearon preocupaciones con respecto a la seguridad y la gestión de procesos. Un comentarista, joahnn_s, cuestionó la seguridad de cargar Chromium como una librería compartida a través de CFFI, señalando que un fallo en el motor podría colapsar todo el proceso de la aplicación. Riiiiichard aclaró que, si bien la interfaz de integración es una API en C, Zebkit sigue utilizando los procesos de renderizado aislados internamente por Chromium y la memoria compartida para mantener el aislamiento.
Integración y limitaciones
Zebkit exporta varias librerías C de Chromium, como BoringSSL, zstd y FFmpeg, para que las aplicaciones anfitrionas no necesiten compilarlas o enviarlas dos veces. Esto ayuda a gestionar las dependencias del motor subyacente manteniendo la huella de la aplicación anfitriona manejable.
Aunque el proyecto proporciona enlaces para Rust, Python y JavaScript, algunas integraciones específicas siguen en progreso. Por ejemplo, actualmente no existe un enlace nativo para Go, aunque se pretende que la API en C sea utilizable a través de cgo. El objetivo principal del proyecto es proporcionar una versión 'delgada' de Chromium que otorgue a la aplicación anfitriona el control total sobre permisos, descargas y certificados.