Blitz: renderizador web leve, modular e escalável

 (github.com/DioxusLabs)
2 pontos por GN⁺ 2024-08-13 | 1 comentários | Compartilhar no WhatsApp
  • Blitz é um motor de renderização modular focado em renderização HTML/CSS, com um design que não fornece por padrão todos os recursos de um navegador e deixa funcionalidades adicionais como opcionais conforme a necessidade
  • O estado atual é pre-alpha; embora o renderizador já tenha bastante funcionalidade, ainda há muitos bugs e recursos ausentes, então seu uso para desenvolver apps ainda não é recomendado
  • O objetivo de suporte inclui modern HTML layout, advanced CSS, controles de formulário HTML, acessibilidade baseada em AccessKit e extensões via custom widgets; recursos como WebRTC, WebSockets, Bluetooth e localStorage não são oferecidos
  • A estrutura é dividida em uma abstração central de DOM e módulos de rede, renderização, janela e gerenciamento de estado, enquanto os crates wrapper de nível superior blitz e dioxus-native cuidam da renderização de HTML/Markdown ou do Dioxus VirtualDom
  • A nova versão, Blitz v0.2+, usa Stylo; o código-fonte da v0.1 permanece no branch legacy, mas não está em desenvolvimento ativo

Motor focado em renderização HTML/CSS

  • Blitz é um motor de renderização HTML/CSS e nasceu da percepção de que navegadores são excessivamente pesados em comparação com o caso de uso principal, que é renderizar HTML/CSS
  • O objetivo não é implementar todos os recursos de um navegador, mas centrar-se no que é necessário para renderização HTML/CSS e tornar o restante opt-in sempre que possível
  • Atualmente está em estado pre-alpha
    • O renderizador já tem bastante funcionalidade
    • Ainda há muitos bugs e recursos ausentes
    • Seu uso para criar apps ainda não é recomendado
    • Mais detalhes sobre o andamento podem ser vistos na roadmap issue

Recursos que pretende oferecer e recursos que ficam de fora

  • O escopo que o Blitz pretende cobrir é voltado para renderização de UI em HTML/CSS
    • modern HTML layout como flexbox, grid, table, block, inline e absolute/fixed
    • advanced CSS como complex selectors, media queries e CSS variables
    • controles de formulário HTML
    • acessibilidade baseada em AccessKit
    • extensibilidade por meio de custom widgets
  • O Blitz não oferece recursos como WebRTC, WebSockets, Bluetooth e localStorage
    • Em apps nativos, boa parte dessas funcionalidades pode ser tratada com crates Rust comuns
    • A posição do projeto é que esses recursos não precisam estar acoplados ao renderizador
  • Ainda não há bindings para outras linguagens como JavaScript e Python, mas contribuições relacionadas são bem-vindas

Como executar e exemplos

  • Após clonar o repositório, é possível executar o pacote browser
cargo run --release --package browser
  • Os exemplos incluem um pequeno app de TODO, um renderizador de Markdown e integração com renderização raw WGPU
cargo run --release --package todomvc

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

cargo run --release --package wgpu_texture

Arquitetura modular

  • Blitz é composto por uma core DOM abstraction, módulos de funcionalidades adicionais e dois wrappers de nível superior
    • Recursos como rede, renderização, janela e gerenciamento de estado são separados em módulos distintos
    • É possível combinar essas peças para formar um único motor web

  • Crates wrapper de nível superior

    • blitz: um frontend HTML/Markdown capaz de renderizar strings HTML
    • Útil para pré-visualização de arquivos HTML ou Markdown
    • Atualmente não há interatividade
    • Usa blitz-dom, blitz-html, blitz-shell e blitz-renderer-vello
    • dioxus-native: um frontend Dioxus que renderiza o Dioxus VirtualDom
    • Oferece interatividade completa por meio do tratamento de eventos do Dioxus
    • Usa blitz-dom, dioxus-core, blitz-shell e blitz-renderer-vello
    • Ambos os wrappers podem usar opcionalmente blitz-net para buscar recursos subordinados

  • Crates principais e crates adicionais

    • blitz-dom: core DOM abstraction que inclui style resolution, layout e event handling
    • Não inclui parsing, rendering nem integração com o sistema
    • Usa Stylo, Taffy e Parley
    • blitz-traits: crate-base mínima que permite que outros crates interoperem sem depender diretamente uns dos outros
    • blitz-net: módulo de rede que busca recursos via HTTP, sistema de arquivos e encoded data URI
    • Usa reqwest
    • blitz-paint: converte a árvore de blitz-dom em comandos de desenho do anyrender
    • Usa anyrender
    • blitz-html: adiciona parsing de HTML ao blitz-dom
    • Usa html5ever e xml5ever
    • blitz-shell: shell que permite ao Blitz renderizar em uma janela
    • Integra Winit event loop, AccessKit, Muda e outros
    • Usa winit, accesskit e muda
    • A abstração de renderização AnyRender foi movida para um repositório separado, anyrender

Uso da versão de desenvolvimento do Dioxus Native

  • A versão de desenvolvimento mais recente do Dioxus Native está neste repositório
  • Como o Dioxus Native está sendo desenvolvido rapidamente, é possível usar a versão via git para obter recursos e correções mais recentes antes dos lançamentos oficiais
  • O procedimento para usar a versão via git é o seguinte
    • Remover completamente a dependência do crate dioxus
    • Adicionar dioxus-native = { git = "https://github.com/DioxusLabs/blitz";, rev = "e64a3d8", features = ["prelude"] }
    • Substituir e64a3d8 pelo git commit id da versão desejada
    • No código Rust, trocar use dioxus::prelude::* por use dioxus_native::prelude::*
    • Se forem necessários recursos do dioxus que o prelude do Dioxus Native não exporta, importar a partir de sub-crates individuais como dioxus-html, dioxus-signals e dioxus-router
  • A versão via git do Dioxus Native ainda depende da versão estável no crates.io, Dioxus v0.7.x
    • Bibliotecas adicionais como dioxus-sdk, dioxus-components e dioxus-free-icons devem continuar funcionando

Versões e licença

  • Este repositório contém a nova versão Blitz v0.2+, que usa Stylo
  • O código-fonte da versão anterior, v0.1, permanece no branch legacy
    • A v0.1 não está em desenvolvimento ativo
  • O projeto é distribuído sob licença dupla Apache 2.0 e MIT
  • O crate stylo_taffy também recebe adicionalmente a MPL 2.0 para facilitar a interoperabilidade com o projeto Servo
    • Portanto, stylo_taffy tem licença tripla: Apache 2.0, MIT e MPL 2.0
  • Contribuições enviadas intencionalmente ao Blitz, salvo indicação em contrário, são tratadas como licenciadas em regime duplo Apache 2.0 e MIT
    • Contribuições enviadas para stylo_taffy também incluem a MPL 2.0

Leituras relacionadas

1 comentários

 
GN⁺ 2024-08-13
Opiniões no Hacker News

  • Sou o desenvolvedor líder do Blitz. Ele ainda não está em fase final; o sistema de entrada de texto/foco é básico e não há suporte a rolagem fora do viewport raiz. Seletores CSS complexos como nth-child e :has ainda não funcionam direito, e a integração do tratamento de eventos com o Dioxus, um framework parecido com React que roda sobre o Blitz, ainda se limita a cliques, sem preventDefault. A parte de rede atualmente é muito simples: faz requisições síncronas na thread principal, então precisamos de networking assíncrono ou multithread de verdade. Também quase não fizemos trabalho de desempenho: estilo/layout/pintura são recalculados a cada frame, e há alguns vazamentos de memória por causa de nós que não são limpos. Sombras, web fonts, calc, layout com floats e controles de formulário além de entrada de texto também ainda estão faltando. No fim, está mais para “criar uma webview é um trabalho grande e ainda não chegamos lá”; esperamos ter algo mais completo em 2 a 3 meses. Há capturas de tela aqui também: https://github.com/DioxusLabs/blitz/issues/23

    • Pessoalmente, eu gostaria de projetar um novo formato de documento com semântica mais simples e mais fácil de renderizar. HTML me parece bastante complexo, e também não foi projetado para renderização dinâmica. Para alguém que gosta de lean e KISS, HTML não parece leve ou simples o bastante.
    • Eu estava procurando uma solução para capturar screenshots de sites e, se possível, queria gerá-las a partir de uma representação coletada anteriormente por crawling. Os serviços existentes em geral sobem uma instância do Chromium para solicitar a captura de tela, então tanto o custo operacional quanto o custo de SaaS parecem bem altos. Nesse caso, o Blitz parece se encaixar bem, mas fico curioso se hoje ele pode ser executado em modo headless e salvar screenshots.
    • Fico curioso sobre a motivação para não construir em cima de algo como Servo ou WebKit e, em vez disso, combinar vários componentes diretamente.
    • Fico curioso sobre qual é a parte de engenharia mais complexa a ser enfrentada. Mesmo que ainda esteja em andamento, seria bom poder compartilhar um documento de design. Pessoalmente, tenho interesse em como engines como Blitz e Servo poderiam ser criadas no futuro com métodos formais. Por exemplo, começando por definições e gerando partes do sistema; hoje em dia isso também incluiria LLMs, mas eu vejo mais como ótimas ferramentas do que como sistemas de IA. Algo como Z3 também vem à mente. Algumas das minhas empresas também têm organizações de pesquisa sobre esse tipo de tema.
    • Fico curioso se o Blitz foi criado para permitir que outras pessoas construam navegadores. Estou criando o Wootzapp(https://github.com/wootzapp/wootz-browser), que é como um Robinhood para rotulagem de dados, onde você pode gastar tempo rotulando dados da web ou imagens e ser recompensado por isso. Atualmente ele é baseado em Chromium, e fico curioso se o Blitz pretende ser um renderizador que possa ser plugado em outros navegadores. Também estamos trabalhando em mobile; agora é Android, depois iOS.

  • À primeira vista, este projeto parece muito útil. A ideia é criar apps nativos usando o paradigma amplamente usado de layout HTML/CSS, mas sem o peso implícito de uma API completa de JS/DOM/navegador. Isso parece permitir uma melhoria muito maior do que empacotar um motor de navegador como no Electron. Por coincidência, recentemente ouvi Casey Muratori falando de forma muito crítica sobre CSS no podcast de Richard Feldman. Os exemplos em que ele teve de pré-renderizar páginas web e medi-las dinamicamente para criar relações simples de layout chamaram especialmente minha atenção. Como Muratori disse, escrever CSS parece menos construir sobre elementos básicos simples e mais defender um caso no tribunal. Claro, por causa da familiaridade, da compatibilidade e do fato de que “o caminho feliz do CSS” é extremamente produtivo, há uma demanda grande que projetos assim atendem. Ainda assim, parece haver uma oportunidade de oferecer uma camada mais simples e genérica para a qual os usuários possam descer quando quiserem. Pode haver inspiração no CSS Houdini, que tenta tornar o CSS extensível via APIs JS, e talvez seja isso que “Custom Widgets” queira dizer.

    • Isso é quase exatamente a proposta do Blitz. Algoritmos de layout plugáveis são algo que queremos muito tornar possível no Blitz. Fazer layout em JS provavelmente seria lento demais na maioria dos casos, mas o fato de a API ser em Rust ajuda. O motor de layout Taffy(https://github.com/DioxusLabs/taffy) também já é bastante modular. Widgets customizados visam permitir, além do layout, layout totalmente customizado, pintura, acessibilidade, tratamento de eventos etc., como widgets de toolkits GUI tradicionais. Também tenho uma proposta para adicionar novas unidades ao próprio CSS. Ela é inspirada na forma como muitos sistemas de UI que não são web fazem layout e, em casos comuns, pode simplificar bastante o layout web: https://github.com/w3c/csswg-drafts/issues/8267 Ficou em segundo plano por um tempo, mas um dia preciso retomar isso e realmente implementar o algoritmo.
    • Fico curioso se é algo como um Dillo melhorado: https://en.m.wikipedia.org/wiki/Dillo Seria bom ter algo assim para navegação web simples ou apps. O único parecido que eu conhecia era o Sciter; era software proprietário, mas o modelo de licenciamento era inovador.
    • Precisamos de um CSS estrito que remova o excesso e prometa melhorias de desempenho. Não sei por que os navegadores ainda não oferecem isso; por exemplo, bastaria remover float.

  • Alguns anos atrás — na verdade, 20 anos atrás — criei um projeto open source parecido chamado Flying Saucer. Era um renderizador HTML + CSS2 em Java puro. Eu imaginava que ele seria usado para renderizar interfaces ricas de texto em jogos, mas seu principal uso real acabou sendo geração de PDFs no lado do servidor. Era muito mais fácil gerar HTML e renderizá-lo como PDF do que usar as várias APIs de geração de relatórios em PDF disponíveis na época. O Blitz parece ótimo, e estou animado para ver mais bibliotecas GUI em Rust. https://en.wikipedia.org/wiki/Flying_Saucer_(library) Surpreendentemente, ele ainda está sendo atualizado: https://github.com/flyingsaucerproject/flyingsaucer/releases...

  • “Uma webview leve que substitui o mecanismo JavaScript por uma API Rust nativa” parece promissor. Basicamente, se for algo como Tauri sem JS no caminho, só de ouvir já soa bom

    • Até certo ponto está certo, mas enquanto o Tauri usa a webview do sistema, nós estamos criando nossa própria webview Parte dela é baseada em componentes do Servo e bibliotecas de uso geral, e parte foi feita por nós. Em alguns aspectos, é mais parecido com Sciter sem JS
    • Acho que Sciter seria uma comparação melhor: https://sciter.com/ Ele implementou renderização de HTML e CSS do zero. Pelo que me lembro, antes tinha uma linguagem de programação própria e agora usa JS Sempre tive interesse nesse tipo de coisa, mas nunca usei Sciter a fundo. Antes eu me preocupava com a licença, mas olhando o site agora parece que os termos ficaram muito mais flexíveis Também vale acrescentar que, se você quiser usar sem JS em uma webview do sistema, basta desativar o JS na webview do sistema
    • Tauri usa a webview nativa, então varia por plataforma. Blitz é um renderizador próprio

  • Interessante. Hoje mesmo passei por uma situação horrível com puppeteer e Chromium headless, e estava procurando uma alternativa ao wkhtmltopdf Executar com jemalloc em LD_PRELOAD é algo que você definitivamente não deve fazer. Resolvi o problema, mas fiquei mais inclinado a um renderizador mais simples

    • Você não é a primeira pessoa a demonstrar interesse em uso para renderização de PDF Provavelmente seria necessário mais suporte a propriedades CSS voltadas para impressão e layout baseado em páginas. Ou seja, dividir o layout ao longo de várias páginas separadas e controlar onde as quebras de página acontecem Ainda assim, acho que é uma área que definitivamente deveríamos conseguir suportar algum dia
    • Meu caso de uso era um pouco diferente. Eu tentava renderizar um elemento de uma página usando Chromium Headless no Playwright, mas recebia aleatoriamente muitos erros de "Page crashed" e "Timed out after 30s" no Playwright Ao mudar para Firefox Headless, esses problemas desapareceram e, na prática, ao trocar para Firefox, o renderizador ficou cerca de 3 vezes mais rápido que o Chromium Headless O Blitz é muito interessante e se aproxima do que eu precisava. Eu estava usando um navegador headless em vez de renderizar tudo diretamente com Java Graphics2D, porque o layout do que precisava ser renderizado era meio complexo e eu não queria reinventar a roda criando meu próprio mecanismo de layout
    • Dê uma olhada no gotenberg[0]; talvez atenda ao que você precisa. Uso para converter meu currículo em PDF no GitHub Actions [0]: https://github.com/gotenberg/gotenberg
    • Sim, o Wkhtmltopdf é realmente um monstro devorador de recursos Outras soluções têm suporte incompleto à especificação HTML, o que dificulta gerar corretamente o PDF desejado. A menos que alguém encontre um jeito usando apenas recursos menos modernos

  • Não é exatamente sobre o Blitz em si, mas acabei de conhecer o Dioxus Fico me perguntando se existe alguma regra tácita de que frameworks que compilam para WASM não mostram demos direito ou não hospedam o próprio site usando o framework. Acho que já vi isso umas 5 ou 6 vezes Na página inicial do Dioxus, dá para ver que um arquivo WASM é carregado, mas não fica claro onde ele é usado ou se é realmente usado

    • O site do Dioxus é hospedado com o próprio framework, mas como ele suporta renderização do lado do servidor e hidratação, o bundle WASM é usado apenas para funcionalidades interativas Também estamos preparando demos em vídeo. Fico curioso para saber se há algo específico que você gostaria de ver

  • Com um backend e htmx junto, isso poderia ser incrível. Mas parece que não há nenhum mecanismo JS envolvido, então fico curioso para saber como isso poderia ser feito

    • Acho que seria uma combinação lendária Idealmente, o renderizador web deveria dar suporte nativo ao HTMX A ideia geral do HTMX é suportar recursos que tornem o HTML mais completo. Por que apenas e deveriam poder fazer requisições HTTP? Por que só eventos de clique e envio deveriam disparar requisições? Por que só GET e POST deveriam ser possíveis? Por que só a tela inteira deveria poder ser substituída? Vendo de outro jeito, o HTMX torna os elementos HTML menos restritos e mais gerais. Se um renderizador web levar isso em conta no design, talvez até fique mais simples
    • Há um movimento para colocar recursos centrais do HTMX na especificação HTML, então talvez JS deixe de ser necessário https://www.reddit.com/r/htmx/comments/1ehjw7v/comment/lg09w...
    • Simples. Troque htmx por Dioxus, ou talvez por leptos no futuro

  • Conheci o Dioxus hoje https://dioxuslabs.com/

  • Muito legal. Quero experimentar em um projeto C++ Uma pergunta que me veio à mente é sobre desempenho. Fico curioso se ele consegue renderizar páginas relativamente complexas com uma alta taxa de quadros por segundo Normalmente uso ImGUI, e ele é excelente a ponto de eu quase não precisar pensar em problemas de desempenho ao exibir dados em tempo real. Por outro lado, a renderização web do Chromium consome CPU mesmo com uma simples atualização de texto no DOM a apenas 10 quadros por segundo; se isso for resolvido, pode mudar o jogo

    • O desempenho atual é péssimo Mas ainda não dedicamos nenhum esforço a otimização, e como estamos construindo sobre dependências bastante rápidas, há potencial para melhorar muito Não acho que venceremos o Chromium em uma “briga justa”, mas há potencial para viabilizar coisas impossíveis no Chrome. Por exemplo, uma API semelhante a canvas muito mais poderosa