Zebkit integra el motor de Chromium como una librería en tu aplicación, sin Electron
Zebkit – Chromium as an embeddable library
Zebkit es una librería que integra el motor de Chromium (Blink, V8, PDFium, FFmpeg) directamente en aplicaciones nativas en C, C++, Rust, Python o JavaScript, sin el runtime de Electron ni Node. Ofrece una API unificada para Linux, macOS y Windows, con vistas web, PDF, media, dibujo 2D y automatización con Playwright. Frente a Electron 45.2.1, es un 34% más pequeña, arranca en 2,3 s frente a 6,6 y usa un 29% menos de memoria por página.
Electron es una base: una aplicación se construye dentro de él, sobre su runtime, sus ventanas y su empaquetado. Zebkit es una pieza: una aplicación lo añade, como añade SQLite, y conserva su proceso, su toolkit y su forma de distribuirse.
- torginus
¿En qué se diferencia esto de CEF (Chromium Embedded Framework)?
Esa también es una versión bastante reducida del motor de Chrome, diseñada para incrustarse y usada por un montón de proyectos, como juegos para sus lobbies dentro del juego u OBS para sus superposiciones web.
Personalmente, mi problema con CEF es que mantiene Chrome bastante vanilla, y hay muchas cosas ahí que no querrías incluir en tu aplicación de usuario.
Pero hay una razón por la que lo hicieron así: si realmente le metieran el hacha al código base de Chrome, básicamente perderían la capacidad de incorporar nuevas versiones upstream.
Zebkit, por otro lado, suena a que va a ser más granular; veremos si lidian con esto mejor, pero creo que definitivamente hay mercado para un motor de navegador mucho más ligero y ampliamente compatible; por ejemplo, simplemente deshacerse de los sandboxes y del aislamiento de procesos sería un cambio enorme pero incompatible.
También lo sería eliminar módulos grandes como WebRTC o la reproducción de video o webusb o lo que sea, que estoy seguro de que el 99% de las apps terminan no usando.
- joahnn_s
No entiendo. CEF existe; ¿por qué cargarlo como una lib compartida/cffi? Solo expones el proceso de tu app a todos los problemas que puede tener un navegador, incluidos problemas de seguridad.
En la mayoría de los lenguajes, CFFI hace que todo el proceso de la app se caiga, ya que es el mismo proceso. Quizás para cosas personales pueda ser adecuado, pero nada serio.
- saidnooneever
¿por qué 'zeb'? es una palabra vulgar para pene. Podría haberse elegido mejor, ya que no parece relacionarse con nada más ahí... quizás es a propósito, lo que me haría preguntarme sobre la calidad del proyecto. Lo cual parece que otros comentaristas también están debatiendo.
- netshade
Genial. Soy un usuario intensivo de CEF en ZShot ( https://zshot-app.com , https://zshot-cli.com ), pero estoy muy de acuerdo contigo en que este tipo de cosas deberían ser más fáciles de integrar.
Además, estoy muy de acuerdo contigo en lo de exponer esas librerías (como PDFium y FFmpeg) a los consumidores; reduce bastante la carga de distribución y habilita muchísimo.
Una nota para cualquiera que vaya por este camino, solo como acotación: en realidad, distribuir con Chromium (y especialmente con FFmpeg) puede volverse complicado. Si distribuyes en Mac OS, querrás preocuparte por notarizar todos tus helpers junto con tu proceso principal (asumo que Zebkit sigue funcionando con procesos helper). Similar con FFmpeg si enlazas con las librerías de FFmpeg. Y, con FFmpeg, solo validar que el cumplimiento de tu licencia sea de hecho lo que quieres distribuir; FFmpeg tiene modos GPL y LGPL, así que asegurarte de haber seleccionado el correcto es importante. Si mal no recuerdo, Blink también es LGPL, así que asegurarte de cumplir con lo que se requiere allí tiene efectos de distribución que son importantes.
- prologic
¡Esto es bastante interesante! He creado un navegador web para GoNix (https://gonix.dev) usando CEF (Chromium Embedded Framework), que funciona bastante bien, pero requiere memoria compartida y una tubería (pipe); sin embargo, incrustar Chromium como una librería suena aún más intrigante. ¡Podría intentarlo! ¡Gracias por compartir!