Blitz: renderizador web ligero, modular y escalable

 (github.com/DioxusLabs)
2 puntos por GN⁺ 2024-08-13 | 1 comentarios | Compartir por WhatsApp
  • Blitz es un motor de renderizado modular enfocado en el renderizado de HTML/CSS, diseñado para no incluir por defecto todas las funciones de un navegador y dejar las capacidades adicionales como opciones elegibles según sea necesario
  • Su estado actual es pre-alpha: aunque el renderizador ya tiene bastantes funciones, todavía hay muchos errores y características faltantes, por lo que aún no se recomienda usarlo para desarrollar aplicaciones
  • Sus objetivos de soporte incluyen modern HTML layout, advanced CSS, controles de formularios HTML, accesibilidad basada en AccessKit y extensión mediante custom widgets; no ofrece funciones como WebRTC, WebSockets, Bluetooth o localStorage
  • Su estructura se divide en una abstracción central del DOM y módulos de red, renderizado, ventanas y manejo de estado, mientras que los crates wrapper de nivel superior blitz y dioxus-native se encargan del renderizado de HTML/Markdown o de Dioxus VirtualDom
  • La nueva versión, Blitz v0.2+, usa Stylo; el código fuente de la v0.1 permanece en la rama legacy, pero ya no se desarrolla activamente

Motor enfocado en el renderizado de HTML/CSS

  • Blitz es un motor de renderizado HTML/CSS que parte de la idea de que los navegadores resultan demasiado pesados en comparación con el caso de uso básico de renderizar HTML/CSS
  • Su objetivo no es implementar todo el conjunto de funciones de un navegador, sino centrarse en lo necesario para renderizar HTML/CSS y dejar el resto, en la medida de lo posible, como funciones opt-in
  • Actualmente está en estado pre-alpha
    • El renderizador ya tiene bastantes capacidades
    • Todavía hay muchos errores y funciones faltantes
    • Aún no se recomienda usarlo para crear aplicaciones
    • Se puede consultar más detalle del progreso en el roadmap issue

Funciones que busca soportar y funciones que excluye

  • El alcance que Blitz busca cubrir está enfocado en el renderizado de interfaces HTML/CSS
    • modern HTML layout como flexbox, grid, table, block, inline y absolute/fixed
    • advanced CSS como complex selectors, media queries y CSS variables
    • controles de formularios HTML
    • accesibilidad basada en AccessKit
    • extensibilidad mediante custom widgets
  • Blitz no ofrece funciones como WebRTC, WebSockets, Bluetooth o localStorage
    • En aplicaciones nativas, gran parte de esas funciones puede resolverse con crates comunes de Rust
    • La postura del proyecto es que esas funciones no necesitan estar acopladas al renderizador
  • Aún no existen bindings para otros lenguajes como JavaScript o Python, aunque se aceptan contribuciones relacionadas

Cómo ejecutarlo y ejemplos

  • Después de clonar el repositorio, se puede ejecutar el paquete browser
cargo run --release --package browser
  • Como ejemplos, se incluyen una pequeña app de TODO, un renderizador de Markdown y una integración de renderizado raw con WGPU
cargo run --release --package todomvc

cargo run --release --package readme ./README.md

cargo run --release --package wgpu_texture

Arquitectura modular

  • Blitz está compuesto por una abstracción central del DOM, módulos de funciones adicionales y dos wrappers de nivel superior
    • Funciones como red, renderizado, ventanas y manejo de estado están divididas en módulos separados
    • Estas piezas pueden combinarse para crear un motor web completo

  • Crates wrapper de nivel superior

    • blitz: un frontend HTML/Markdown capaz de renderizar cadenas HTML
    • Es útil para previsualizar archivos HTML o Markdown
    • Actualmente no tiene interacción
    • Usa blitz-dom, blitz-html, blitz-shell y blitz-renderer-vello
    • dioxus-native: un frontend de Dioxus que renderiza Dioxus VirtualDom
    • Soporta interacción completa mediante el manejo de eventos de Dioxus
    • Usa blitz-dom, dioxus-core, blitz-shell y blitz-renderer-vello
    • Ambos wrappers pueden usar opcionalmente blitz-net para obtener subrecursos

  • Crates principales y crates adicionales

    • blitz-dom: abstracción central del DOM que incluye style resolution, layout y event handling
    • No incluye parsing, rendering ni integración con el sistema
    • Usa Stylo, Taffy y Parley
    • blitz-traits: crate base mínima que permite que otros crates interoperan sin depender directamente unos de otros
    • blitz-net: módulo de red que obtiene recursos desde HTTP, el sistema de archivos y encoded data URI
    • Usa reqwest
    • blitz-paint: convierte el árbol de blitz-dom en comandos de dibujo de anyrender
    • Usa anyrender
    • blitz-html: agrega parsing de HTML a blitz-dom
    • Usa html5ever y xml5ever
    • blitz-shell: shell que permite a Blitz renderizar en ventanas
    • Integra Winit event loop, AccessKit, Muda y más
    • Usa winit, accesskit y muda
    • La abstracción de renderizado AnyRender se trasladó a un repositorio separado: anyrender

Uso de la versión de desarrollo de Dioxus Native

  • La versión de desarrollo más reciente de Dioxus Native está en este repositorio
  • Como Dioxus Native se está desarrollando rápidamente, se puede usar la versión de git para obtener funciones nuevas y correcciones antes de una release oficial
  • El procedimiento para usar la versión de git es el siguiente
    • Eliminar por completo la dependencia del crate dioxus
    • Agregar dioxus-native = { git = "https://github.com/DioxusLabs/blitz";, rev = "e64a3d8", features = ["prelude"] }
    • Cambiar e64a3d8 por el git commit id de la versión deseada
    • En el código Rust, cambiar use dioxus::prelude::* por use dioxus_native::prelude::*
    • Si se necesitan funciones de dioxus que el prelude de Dioxus Native no exporta, importarlas desde sub-crates individuales como dioxus-html, dioxus-signals o dioxus-router
  • La versión de git de Dioxus Native sigue dependiendo de la versión estable de crates.io, Dioxus v0.7.x
    • Bibliotecas adicionales como dioxus-sdk, dioxus-components y dioxus-free-icons deberían seguir funcionando

Versiones y licencia

  • Este repositorio contiene la nueva versión Blitz v0.2+, que usa Stylo
  • El código de la versión anterior, v0.1, permanece en la rama legacy
    • La v0.1 ya no se desarrolla activamente
  • El proyecto se distribuye bajo licencia dual Apache 2.0 y MIT
  • El crate stylo_taffy también aplica MPL 2.0 adicionalmente para facilitar la interoperabilidad con el proyecto Servo
    • Por lo tanto, stylo_taffy tiene licencia triple: Apache 2.0, MIT y MPL 2.0
  • Las contribuciones enviadas intencionalmente a Blitz se manejan como dual licensed bajo Apache 2.0 y MIT, salvo que se especifique lo contrario
    • Las contribuciones enviadas a stylo_taffy también incluyen MPL 2.0

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-08-13
Opiniones de Hacker News

  • Soy el desarrollador líder de Blitz. Todavía no está en una etapa terminada, y el sistema de entrada de texto/foco es básico; además, no admite scroll fuera del viewport raíz. Los selectores CSS complejos como nth-child y :has aún no funcionan bien, y la integración del manejo de eventos con Dioxus, un framework similar a React que corre sobre Blitz, apenas llega al nivel de clics y no tiene preventDefault. La red actualmente es muy simple: hace solicitudes síncronas en el hilo principal, y necesita networking asíncrono o multihilo bien implementado. Casi no se ha trabajado en rendimiento, así que recalcula estilos/layout/paint en cada frame, y también hay algunas fugas de memoria por nodos que no se limpian. Todavía faltan sombras, fuentes web, calc, layout con floats y controles de formulario aparte de la entrada de texto. En definitiva, está más cerca de “hacer un webview es un trabajo grande y todavía no llegamos ahí”, y espero tener una forma más completa en 2 a 3 meses. También hay capturas aquí: https://github.com/DioxusLabs/blitz/issues/23

    • Personalmente, me gustaría diseñar un nuevo formato de documento con una semántica más simple y más fácil de renderizar. HTML se siente bastante complejo, y tampoco fue diseñado para renderizado dinámico. Desde una postura a favor de lean y KISS, HTML no parece lo suficientemente liviano ni simple.
    • Estaba buscando una solución para capturar screenshots de sitios web y, si era posible, quería generarlas a partir de una representación rastreada previamente. Los servicios existentes por lo general levantan instancias de Chromium y piden screenshots, por lo que tanto los costos operativos como los de SaaS parecen bastante altos. Entonces Blitz parecería encajar bien, pero me pregunto si actualmente puede ejecutarse en modo headless y guardar screenshots.
    • Me da curiosidad la motivación para no construir sobre algo como Servo o WebKit y, en cambio, componer directamente varios componentes.
    • Me pregunto cuál es la parte de ingeniería más compleja que hay que abordar. Aunque todavía esté en desarrollo, sería bueno que pudieran compartir un documento de diseño. Personalmente, me interesa cómo motores como Blitz o Servo podrían construirse en el futuro usando métodos formales. Por ejemplo, partir de definiciones y generar partes del sistema; hoy eso también incluye LLM, aunque lo veo más como una gran herramienta que como un sistema de IA. También me viene a la mente algo como Z3. Algunas de mis empresas también tienen organizaciones de investigación sobre estos temas.
    • Me pregunto si Blitz fue creado para permitir que otras personas construyan navegadores. Estoy creando Wootzapp(https://github.com/wootzapp/wootz-browser), un servicio tipo Robinhood para etiquetado de datos en el que puedes dedicar tiempo a datos web o etiquetado de imágenes y recibir recompensas. Actualmente está basado en Chromium, y me pregunto si Blitz busca convertirse en un renderizador que pueda integrarse en otros navegadores. También estamos trabajando en mobile: ahora Android, luego iOS.

  • Este proyecto, a primera vista, parece muy útil. La idea es crear apps nativas usando el paradigma de layout HTML/CSS ampliamente utilizado, pero quitando las partes pesadas que implica una API completa de JS/DOM/navegador. Parece que podría permitir una mejora mucho mayor que empaquetar un motor de navegador como hace Electron. Justo hace poco escuché a Casey Muratori hablar de CSS de forma muy crítica en el podcast de Richard Feldman. Me pegaron especialmente los casos en los que tuvo que prerenderizar una página web y medirla dinámicamente para crear relaciones de layout simples. Como dice Muratori, escribir CSS se siente menos como construir sobre primitivos simples y más como defender un caso en un tribunal. Por supuesto, por la familiaridad, la compatibilidad y lo extremadamente productivo que es el “CSS del camino feliz”, hay una gran demanda que este tipo de proyecto satisface. Aun así, parece haber una oportunidad para ofrecer una capa más simple y general a la que el usuario pueda bajar cuando la necesite. También podría inspirarse en CSS Houdini, que intenta hacer extensible CSS mediante APIs de JS; quizá eso sea lo que significan “Custom Widgets”.

    • Eso es casi exactamente la propuesta de Blitz. Los algoritmos de layout enchufables son algo que definitivamente quiero hacer posible en Blitz. Hacer layout en JS probablemente sería demasiado lento en la mayoría de los casos, pero el hecho de que la API sea Rust es una ventaja. El motor de layout Taffy(https://github.com/DioxusLabs/taffy) ya es bastante modular. Los widgets personalizados buscan ir más allá del layout y permitir layout, paint, accesibilidad y manejo de eventos totalmente personalizados, como los widgets de los toolkits GUI tradicionales. También tengo una propuesta para agregar nuevas unidades al propio CSS. Está inspirada en la forma en que muchos sistemas de UI no web manejan el layout, y podría simplificar mucho el layout web en casos comunes: https://github.com/w3c/csswg-drafts/issues/8267 Quedó postergada por un tiempo, pero algún día tengo que retomarla, y realmente quiero implementar el algoritmo.
    • Me pregunto si se parece a un Dillo mejorado: https://en.m.wikipedia.org/wiki/Dillo Sería bueno tener algo así para navegación web simple o apps. Lo único similar que conocía era Sciter; era software propietario, pero su modelo de licenciamiento era innovador.
    • Necesitamos un CSS estricto que elimine lo innecesario y prometa mejoras de rendimiento. No entiendo por qué los navegadores todavía no lo ofrecen; por ejemplo, bastaría con quitar float.

  • Hace unos años, no, hace 20 años, creé un proyecto open source parecido llamado Flying Saucer. Era un renderizador de HTML + CSS2 hecho en Java puro. Imaginaba que se usaría para renderizar interfaces de texto enriquecido en juegos, pero su uso principal real fue la generación de PDF del lado del servidor. Era mucho más fácil generar HTML y renderizarlo como PDF que usar las distintas APIs de generación de reportes PDF disponibles en ese momento. Blitz se ve genial, y me entusiasma que haya más bibliotecas GUI en Rust. https://en.wikipedia.org/wiki/Flying_Saucer_(library) Sorprendentemente, todavía se actualiza: https://github.com/flyingsaucerproject/flyingsaucer/releases...

  • “Una webview ligera que reemplaza el motor de JavaScript por una API nativa en Rust” suena prometedor. Básicamente, si es algo como Tauri sin JS en el camino, con solo oírlo ya suena bien.

    • En parte es cierto, pero mientras Tauri usa la webview del sistema, nosotros estamos creando nuestra propia webview. En parte sobre componentes de Servo y bibliotecas de uso general, y en parte hecha por nosotros. En cierto sentido se parece más a Sciter sin JS.
    • Creo que Sciter sería una mejor comparación: https://sciter.com/ Implementa el renderizado de HTML y CSS desde cero. Si mal no recuerdo, antes tenía su propio lenguaje de programación y ahora usa JS. Hace tiempo que me interesan cosas de este tipo, pero nunca usé Sciter a fondo. Antes me preocupaba su licencia, pero viendo el sitio ahora, parece que las condiciones se volvieron mucho más flexibles. También vale la pena agregar que, si quieres usar una webview del sistema sin JS, simplemente puedes desactivar JS en la webview del sistema.
    • Tauri usa la webview nativa, así que varía según la plataforma. Blitz es un renderizador propio.

  • Interesante. Justo hoy pasé por algo horrible con puppeteer y Chromium headless, y estaba buscando un reemplazo para wkhtmltopdf. Nunca hay que ejecutar eso metiendo jemalloc en LD_PRELOAD. Resolví el problema, pero me gustaba más la idea de un renderizador simple.

    • No eres la primera persona que muestra interés en usarlo para renderizar PDF. Probablemente haría falta más soporte para propiedades CSS orientadas a impresión y layout basado en páginas. Es decir, la capacidad de dividir el layout en varias páginas separadas y controlar dónde ocurren los saltos de página. Aun así, creo que es un área que definitivamente deberíamos poder soportar algún día.
    • Mi caso de uso era un poco distinto. Intentaba renderizar un elemento de una página usando Chromium Headless desde Playwright, pero en Playwright me aparecían aleatoriamente muchos “Page crashed” y “Timed out after 30s”. Al cambiar a Firefox Headless, esos problemas desaparecieron; de hecho, al cambiar a Firefox, el renderizador se volvió unas 3 veces más rápido que Chromium Headless. Blitz es muy interesante y se acerca a lo que necesitaba. Estaba usando un navegador headless en lugar de renderizar todo directamente con Java Graphics2D, porque el layout de lo que tenía que renderizar era algo complejo y no quería reinventar la rueda creando mi propio motor de layout.
    • Revisa gotenberg[0]; quizá cubra tus necesidades. Lo uso en GitHub Actions para convertir mi currículum a PDF. [0]: https://github.com/gotenberg/gotenberg
    • Sí, Wkhtmltopdf es realmente un monstruo devorador de recursos. Otras soluciones tienen soporte incompleto de la especificación HTML, así que es difícil generar correctamente el PDF que uno quiere, salvo que alguien encuentre la forma de hacerlo usando solo funcionalidades menos modernas.

  • No es sobre Blitz en sí, pero acabo de conocer Dioxus. Me pregunto si existe alguna regla implícita según la cual los frameworks que compilan a WASM no muestran demos en serio o no alojan su propio sitio usando el framework. Creo que ya vi esto unas 5 o 6 veces. En la página de Dioxus se ve que se carga un archivo WASM, pero no queda claro dónde se usa ni si realmente se usa.

    • El sitio de Dioxus está alojado con su propio framework, pero como soporta renderizado del lado del servidor e hidratación, el bundle WASM solo se usa para funcionalidades interactivas. También estamos preparando una demo en video. Me pregunto si hay algo en particular que te gustaría ver.

  • Podría ser genial usarlo junto con htmx en el backend. Aunque parece que no se mezcla ningún motor JS, así que me pregunto cómo se podría hacer.

    • Creo que sería una combinación legendaria. Idealmente, el renderizador web debería soportar HTMX de forma nativa. La idea general de HTMX es soportar funcionalidades que hacen que HTML sea más completo. ¿Por qué solo y deberían poder hacer solicitudes HTTP? ¿Por qué solo los eventos de clic y envío deberían disparar solicitudes? ¿Por qué solo deberían ser posibles GET y POST? ¿Por qué solo se debería poder reemplazar toda la pantalla? Visto de otra forma, HTMX vuelve a los elementos HTML menos restrictivos y más generales. Si un renderizador web lo toma en cuenta al diseñarse, incluso podría volverse más simple.
    • Hay un movimiento para incorporar funciones clave de HTMX a la especificación HTML, así que quizá ya no haga falta JS. https://www.reddit.com/r/htmx/comments/1ehjw7v/comment/lg09w...
    • Es simple. Cambia htmx por Dioxus, o quizá más adelante por leptos.

  • Hoy conocí Dioxus por primera vez. https://dioxuslabs.com/

  • Realmente genial. Me gustaría probarlo en un proyecto de C++. Una pregunta que se me ocurre es el rendimiento. Me pregunto si puede renderizar páginas relativamente complejas con una alta tasa de cuadros por segundo. Normalmente uso ImGUI, y es tan bueno que casi no tengo que pensar en problemas de rendimiento al mostrar datos en tiempo real. En cambio, el renderizado web de Chromium quema CPU incluso con simples actualizaciones de texto en el DOM a solo 10 cuadros por segundo; si esto se resolviera, podría cambiar las reglas del juego.

    • El rendimiento actual es pésimo. Pero todavía no dedicamos ningún esfuerzo a la optimización, y como lo estamos construyendo sobre dependencias bastante rápidas, hay potencial para que mejore mucho. No creo que podamos vencer a Chromium en una “pelea justa”, pero tiene potencial para hacer posibles cosas que en Chrome no lo son. Por ejemplo, una API similar a canvas mucho más potente.