Blitz: Hafif, modüler ve ölçeklenebilir bir web renderer

 (github.com/DioxusLabs)
2 puan yazan GN⁺ 2024-08-13 | 1 yorum | WhatsApp'ta paylaş
  • Blitz, HTML/CSS render etmeye odaklanan modüler bir render motoru ve tam tarayıcı işlevlerini varsayılan olarak sunmak yerine, gerekli ek özellikleri isteğe bağlı bırakmayı hedefleyen bir tasarıma sahip
  • Mevcut durumu pre-alpha; renderer şimdiden oldukça fazla işleve sahip olsa da çok sayıda hata ve eksik özellik bulunduğundan uygulama geliştirmede kullanılması henüz önerilmiyor
  • Hedeflenen destek kapsamı modern HTML layout, advanced CSS, HTML form controls, AccessKit tabanlı erişilebilirlik ve custom widgets genişletmeleri; WebRTC, WebSockets, Bluetooth, localStorage gibi özellikler ise sunulmuyor
  • Yapı; çekirdek DOM soyutlaması ile ağ, render, pencere ve durum yönetimi modüllerine ayrılıyor; blitz ve dioxus-native adlı üst seviye wrapper crate’ler ise HTML/Markdown veya Dioxus VirtualDom render işini üstleniyor
  • Yeni sürüm olan Blitz v0.2+ Stylo kullanıyor; v0.1 kaynak kodu legacy dalında kalmaya devam ediyor ancak aktif olarak geliştirilmiyor

HTML/CSS render etmeye odaklanan motor

  • Blitz bir HTML/CSS render motoru ve çıkış noktası, temel kullanım senaryosu olan HTML/CSS render etme ihtiyacına kıyasla tarayıcıların fazla şişkin olduğu düşüncesi
  • Amaç, tarayıcıdaki tüm işlevleri uygulamak değil; HTML/CSS render için gereken yetenekleri merkeze alıp geri kalan özellikleri mümkün olduğunca opt-in hale getirmek
  • Şu anda pre-alpha durumunda
    • Renderer şimdiden oldukça fazla işleve sahip
    • Hâlâ çok sayıda hata ve eksik özellik var
    • Uygulama geliştirmek için kullanılması henüz tavsiye edilmiyor
    • Daha ayrıntılı ilerleme durumu roadmap issue üzerinden görülebilir

Hedeflenen ve hariç tutulan özellikler

  • Blitz’in desteklemeyi hedeflediği kapsam HTML/CSS UI render etme üzerine kurulu
    • flexbox, grid, table, block, inline, absolute/fixed gibi modern HTML layout
    • complex selectors, media queries, CSS variables gibi advanced CSS
    • HTML form controls
    • AccessKit tabanlı erişilebilirlik
    • custom widgets ile genişletilebilirlik
  • Blitz, WebRTC, WebSockets, Bluetooth, localStorage gibi özellikler sunmuyor
    • Native uygulamalarda bu işlevlerin önemli bir kısmı normal Rust crate’leriyle ele alınabiliyor
    • Bu tür özelliklerin renderer ile sıkı bağlı olması gerekmediği görüşünde
  • JavaScript, Python ve diğer diller için binding’ler henüz yok, ancak bu konuda katkı kabul ediliyor

Çalıştırma ve örnekler

  • Depoyu klonladıktan sonra browser paketini çalıştırabilirsiniz
cargo run --release --package browser
  • Örnekler arasında küçük bir TODO uygulaması, Markdown renderer ve ham WGPU render entegrasyonu bulunuyor
cargo run --release --package todomvc

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

cargo run --release --package wgpu_texture

Modüler mimari

  • Blitz; core DOM abstraction, ek özellik modülleri ve iki üst seviye wrapper’dan oluşuyor
    • Ağ, render, pencere ve durum yönetimi gibi işlevler ayrı modüllere bölünmüş durumda
    • Bu parçalar birleştirilerek tek bir web motoru oluşturulabiliyor

  • Üst seviye wrapper crate’ler

    • blitz: HTML string render edebilen bir HTML/Markdown frontend
    • HTML veya Markdown dosyalarını önizlemek için kullanışlı
    • Şu anda etkileşim yok
    • blitz-dom, blitz-html, blitz-shell, blitz-renderer-vello kullanıyor
    • dioxus-native: Dioxus VirtualDom render eden bir Dioxus frontend
    • Dioxus event handling sayesinde tam etkileşim desteği sunuyor
    • blitz-dom, dioxus-core, blitz-shell, blitz-renderer-vello kullanıyor
    • Her iki wrapper da alt kaynakları almak için isteğe bağlı olarak blitz-net kullanabiliyor

  • Çekirdek crate’ler ve ek crate’ler

    • blitz-dom: style resolution, layout ve event handling içeren core DOM abstraction
    • parsing, rendering ve system integration içermez
    • Stylo, Taffy, Parley kullanır
    • blitz-traits: farklı crate’lerin birbirine doğrudan bağımlı olmadan birlikte çalışabilmesini sağlayan minimal temel crate
    • blitz-net: HTTP, dosya sistemi ve encoded data URI üzerinden kaynak getiren ağ modülü
    • reqwest kullanır
    • blitz-paint: blitz-dom ağacını anyrender draw commands’a dönüştürür
    • anyrender kullanır
    • blitz-html: blitz-dom üzerine HTML parsing ekler
    • html5ever ve xml5ever kullanır
    • blitz-shell: Blitz’in bir pencereye render etmesini sağlayan shell
    • Winit event loop, AccessKit, Muda ve benzerlerini entegre eder
    • winit, accesskit, muda kullanır
    • AnyRender render soyutlaması ayrı bir depo olan anyrender’a taşındı

Dioxus Native geliştirme sürümünü kullanma

  • Dioxus Native’in en güncel geliştirme sürümü bu depoda yer alıyor
  • Dioxus Native hızlı geliştirildiği için, resmi sürümü beklemeden en yeni özellikleri ve hata düzeltmelerini kullanmak isterseniz git sürümünü tercih edebilirsiniz
  • git sürümünü kullanma adımları şöyle
    • dioxus crate bağımlılığını tamamen kaldırın
    • dioxus-native = { git = "https://github.com/DioxusLabs/blitz";, rev = "e64a3d8", features = ["prelude"] } ekleyin
    • e64a3d8 değerini istediğiniz sürümün git commit id’siyle değiştirin
    • Rust kodunda use dioxus::prelude::* satırını use dioxus_native::prelude::* olarak değiştirin
    • Dioxus Native prelude tarafından dışa aktarılmayan dioxus özelliklerine ihtiyaç varsa dioxus-html, dioxus-signals, dioxus-router gibi ayrı sub-crate’lerden import edin
  • Dioxus Native’in git sürümü hâlâ crates.io üzerindeki kararlı Dioxus v0.7.x sürümüne bağımlı
    • dioxus-sdk, dioxus-components, dioxus-free-icons gibi ek kütüphaneler çalışmaya devam etmeli

Sürüm ve lisans

  • Bu depoda Blitz v0.2+ yeni sürümü bulunuyor ve Stylo kullanıyor
  • Önceki sürüm olan v0.1 kaynak kodu legacy dalında duruyor
    • v0.1 aktif olarak geliştirilmiyor
  • Proje Apache 2.0 ve MIT dual license ile dağıtılıyor
  • stylo_taffy crate’ine, Servo projesiyle birlikte çalışmayı kolaylaştırmak için ek olarak MPL 2.0 da uygulanıyor
    • Bu nedenle stylo_taffy, Apache 2.0, MIT ve MPL 2.0 olmak üzere triple license’a sahip
  • Blitz’e bilinçli olarak gönderilen katkılar, aksi belirtilmedikçe Apache 2.0 ve MIT ile dual licensed kabul ediliyor
    • stylo_taffy için gönderilen katkılar MPL 2.0’ı da kapsıyor

İlgili okumalar

1 yorum

 
GN⁺ 2024-08-13
Hacker News yorumları

  • Blitz’in baş geliştiricisiyim. Henüz tamamlanmış aşamada değil; metin girişi/odak sistemi temel düzeyde ve kök viewport dışında kaydırmayı desteklemiyor. nth-child, :has gibi karmaşık CSS seçicileri henüz düzgün çalışmıyor; Blitz’in üstünde çalışan React benzeri framework Dioxus ile olay işleme entegrasyonu da yalnızca tıklama seviyesinde ve preventDefault da yok. Ağ katmanı şu anda çok basit: ana iş parçacığında eşzamanlı istek yapıyor; düzgün bir asenkron veya çok iş parçacıklı ağ katmanına ihtiyaç var. Performans çalışması da neredeyse hiç yapılmadı; her karede stil/layout/paint yeniden hesaplanıyor ve temizlenmeyen düğümler yüzünden birkaç yerde bellek sızıntısı var. Gölgeler, web fontları, calc, float layout ve metin girişi dışındaki form kontrolleri de henüz eksik. Sonuçta durum “webview yapmak büyük iş ve henüz o noktaya gelmedik” demeye daha yakın; 2-3 ay içinde daha tamamlanmış bir biçim bekliyoruz. Ekran görüntüleri burada da var: https://github.com/DioxusLabs/blitz/issues/23

    • Kişisel olarak, render etmesi daha kolay olan daha basit semantiklere sahip yeni bir belge biçimi tasarlamak isterdim. HTML bana oldukça karmaşık geliyor ve dinamik render için tasarlanmış da değil. lean ve KISS’i seven biri olarak HTML yeterince hafif veya basit görünmüyor.
    • Web sitesi ekran görüntüsü yakalayacak bir çözüm arıyordum ve mümkünse bunu daha önce crawl edilmiş bir temsilden üretmek istiyordum. Mevcut servisler genelde bir Chromium instance’ı kaldırıp ekran görüntüsü isteme yöntemiyle çalışıyor; bu yüzden işletme maliyeti de SaaS maliyeti de epey pahalı görünüyor. Bu durumda Blitz iyi uyacak gibi, ancak şu anda headless modda çalıştırılıp ekran görüntüsü kaydedilip kaydedilemeyeceğini merak ediyorum.
    • Servo veya WebKit gibi bir şeyin üstüne kurmak yerine, çeşitli bileşenleri doğrudan bir araya getirmenin motivasyonunu merak ediyorum.
    • Ele alınması gereken en karmaşık mühendislik kısmının ne olduğunu merak ediyorum. Hâlâ çalışma aşamasında olsa bile tasarım belgelerini paylaşabilseniz iyi olurdu. Kişisel olarak Blitz, Servo gibi motorların gelecekte biçimsel yöntemlerle nasıl yapılabileceğiyle ilgileniyorum. Örneğin tanımdan başlayıp sistemin bir kısmını üretme yaklaşımı; bugünlerde buna LLM’ler de dahil oluyor ama bunu AI sistemlerinden ziyade harika araçlara daha yakın görüyorum. Z3 gibi şeyler de aklıma geliyor. Şirketlerimden bazılarında da bu tür konularda araştırma organizasyonları var.
    • Blitz’in başka insanların tarayıcı yapabilmesini sağlamak için mi geliştirildiğini merak ediyorum. Wootzapp’i (https://github.com/wootzapp/wootz-browser) geliştiriyorum; web verileri veya görsel etiketleme için zaman harcayıp ödül kazanabileceğiniz, veri etiketleme için Robinhood benzeri bir servis. Şu anda Chromium tabanlı ve Blitz’in başka tarayıcılara takılıp kullanılabilecek bir renderer olmayı hedefleyip hedeflemediğini merak ediyorum. Mobilde de çalışıyoruz; şu an Android, sırada iOS var.

  • Bu proje ilk bakışta bile çok yararlı görünüyor. Yaygın kullanılan HTML/CSS layout paradigmasıyla native uygulamalar yapmak, fakat tam JS/DOM/tarayıcı API’lerinin ima ettiği ağır kısımları çıkarmak şeklinde. Electron gibi bir tarayıcı motorunu paketlemeye kıyasla çok daha büyük bir iyileştirme sağlayabilecek gibi görünüyor. Tesadüfen yakın zamanda Richard Feldman’ın podcast’inde Casey Muratori’nin CSS’i çok eleştirel biçimde anlattığını dinledim. Basit layout ilişkileri kurmak için web sayfasını önceden render edip dinamik olarak ölçmek zorunda kaldığı örnekler özellikle bana çok dokundu. Muratori’nin dediği gibi CSS yazmak, basit temel öğelerin üstüne inşa etmekten çok mahkemede bir davayı savunuyormuş hissine yakın. Elbette aşinalık, uyumluluk ve “iyi çalışan yolun CSS’i”nin inanılmaz üretken olması nedeniyle böyle bir projenin karşıladığı talep büyük. Yine de kullanıcıların daha aşağıya inip kullanabileceği daha basit ve genel bir katman sunma fırsatı da var gibi görünüyor. CSS’i JS API ile genişletilebilir yapmayı amaçlayan CSS Houdini’den ilham alınabilir; belki de “Custom Widgets” ile kastedilen şey budur.

    • Blitz’in önerisine çok yakın olan da tam olarak bu. Tak-çıkar layout algoritmaları, Blitz’te mutlaka mümkün kılmak istediğim bir şey. Layout’u JS ile yapmak çoğu durumda çok yavaş olur gibi, ama API’nin Rust olması avantaj sağlıyor. Layout motoru Taffy (https://github.com/DioxusLabs/taffy) de zaten oldukça modüler. Custom widget’lar layout’un ötesine geçip geleneksel GUI toolkit’lerindeki widget’lar gibi tamamen özel layout, paint, erişilebilirlik, olay işleme vb. şeylere izin vermeyi amaçlıyor. CSS’in kendisine yeni bir birim ekleme önerim de var. Web dışındaki birçok UI sisteminin layout yöntemlerinden ilham alıyor ve yaygın durumlarda web layout’unu ciddi biçimde basitleştirme potansiyeli var: https://github.com/w3c/csswg-drafts/issues/8267 Bir süredir geri plana atılmıştı ama bir gün tekrar ele almak ve algoritmayı gerçekten uygulamak istiyorum.
    • Bunun geliştirilmiş bir Dillo gibi bir şey olup olmadığını merak ediyorum: https://en.m.wikipedia.org/wiki/Dillo Basit web gezinmesi veya uygulamalar için böyle bir şeyin olması iyi olurdu. Bildiğim benzer tek şey Sciter’dı; kapalı kaynak yazılımdı ama lisanslama yöntemi yenilikçiydi.
    • Fazlalıkları kaldırıp performans artışı vadeden katı bir CSS gerekiyor. Tarayıcıların bunu neden hâlâ sunmadığını bilmiyorum; örneğin sadece float çıkarılsa bile olur.

  • Birkaç yıl önce, hayır 20 yıl önce, Flying Saucer adlı benzer bir açık kaynak proje yapmıştım. Saf Java tabanlı bir HTML + CSS2 renderer’dı. Oyunlarda zengin metin UI’ları render etmek için kullanılacağını hayal etmiştim, ama asıl temel kullanım alanı sunucu tarafında PDF üretimiydi. O dönemde sunulan çeşitli PDF rapor üretme API’lerini kullanmaktansa HTML üretip PDF’e render etmek çok daha kolaydı. Blitz harika görünüyor ve Rust GUI kütüphanelerinin artmasını sabırsızlıkla bekliyorum. https://en.wikipedia.org/wiki/Flying_Saucer_(library) Şaşırtıcı biçimde hâlâ güncelleniyor: https://github.com/flyingsaucerproject/flyingsaucer/releases...

  • “JavaScript motorunu yerel Rust API ile değiştiren hafif bir webview” kulağa umut verici geliyor. Temelde JS’in yol üzerinde olmadığı Tauri gibi bir şeyse, bunu duymak bile güzel

    • Bir ölçüde doğru, ama Tauri sistem webview’ini kullanırken biz kendi webview’imizi geliştiriyoruz Bir kısmı Servo bileşenleri ve genel amaçlı kütüphaneler üzerine, bir kısmı da kendi yazdığımız şeyler. Bazı açılardan JS’siz Sciter’a daha yakın
    • Sciter daha iyi bir karşılaştırma noktası olabilir: https://sciter.com/ HTML ve CSS render etmeyi sıfırdan implemente etmiş bir şey. Hatırladığım kadarıyla eskiden kendi programlama dili vardı, şimdi JS kullanıyor Bu tür şeylere uzun zamandır ilgim var ama Sciter’ı derinlemesine kullanmadım. Eskiden lisans konusunda endişelerim vardı; şimdi siteye bakınca şartlar çok daha esnekleşmiş gibi görünüyor Sistem webview’inde JS olmadan kullanmak istiyorsanız, basitçe sistem webview’inde JS’i kapatabileceğinizi de eklemek gerekir
    • Tauri yerel webview kullandığı için platforma göre değişir. Blitz ise kendi render’ına sahip

  • İlginç. Tam bugün puppeteer ve headless Chromium yüzünden berbat bir şey yaşayıp wkhtmltopdf alternatifi arıyordum LD_PRELOAD’a jemalloc koyup çalıştırmak kesinlikle yapılmaması gereken bir şey. Sorunu çözdüm ama daha basit bir renderer fikri daha çok hoşuma gitti

    • PDF render etme amacıyla ilgilenen ilk kişi değilsiniz Muhtemelen baskı odaklı CSS özelliklerine ve sayfa tabanlı yerleşim desteğine daha fazla ihtiyaç olacaktır. Yani yerleşimi birden fazla ayrı sayfaya bölmek ve sayfa kırılmalarının konumunu kontrol etmek Yine de bir gün kesinlikle destekleyebilmemiz gereken bir alan olduğunu düşünüyorum
    • Benim kullanımım biraz farklıydı. Playwright’ta Chromium Headless kullanarak sayfadaki bir öğeyi render etmeye çalışıyordum; Playwright’ta rastgele çok sayıda “Page crashed” ve “Timed out after 30s” hatası yaşadım Firefox Headless’a geçince bu sorunlar ortadan kalktı ve gerçekten de Firefox’a geçince renderer, Chromium Headless’tan yaklaşık 3 kat daha hızlı oldu Blitz çok ilginç ve ihtiyacım olan şeye yakın. Her şeyi doğrudan Java Graphics2D ile render etmek yerine headless tarayıcı kullanıyordum; çünkü render edilecek şeyin yerleşimi biraz karmaşıktı ve kendi yerleşim motorumu yapıp tekerleği yeniden icat etmek istemiyordum
    • gotenberg[0]’e bakarsanız ihtiyacınızı karşılayabilir. GitHub Actions’ta özgeçmişimi PDF’ye dönüştürmek için kullanıyorum [0]: https://github.com/gotenberg/gotenberg
    • Evet, Wkhtmltopdf gerçekten tam bir kaynak canavarı Diğer çözümlerin HTML spesifikasyonu desteği eksik olduğundan istenen PDF’yi düzgün üretmek zor. Tabii biri daha az modern özelliklerle bir yol bulmadığı sürece

  • Doğrudan Blitz hakkında değil ama Dioxus’u ilk kez öğrenmiş oldum WASM’e derlenen framework’lerin demolarını düzgün göstermemek ya da kendi sitelerini o framework ile barındırmamak gibi örtük bir kuralı mı var merak ediyorum. Bunu 5-6 kez görmüş gibiyim Dioxus ana sayfasında WASM dosyasının yüklendiğini görüyorum ama nerede kullanıldığı ya da gerçekten kullanılıp kullanılmadığı net değil

    • Dioxus sitesi kendi framework’üyle barındırılıyor, ancak sunucu tarafı render ve hydration desteklediği için WASM paketi yalnızca etkileşimli özelliklerde kullanılıyor Video demosu da hazırlanıyor. Özellikle görmek istediğiniz bir şey var mı merak ediyorum

  • Backend ile htmx birlikte kullanılırsa harika olabilir. Ancak JS motoru hiç işin içine karışmıyor gibi göründüğü için bunun nasıl yapılabileceğini merak ediyorum

    • Efsanevi bir kombinasyon olur gibi İdeal olarak web renderer’ın HTMX’i yerel olarak desteklemesi gerekir HTMX’in genel fikri, HTML’i daha eksiksiz kılan özellikleri desteklemek. Neden yalnızca ve HTTP isteği yapabilsin, neden yalnızca tıklama ve gönderme olayları istek tetiklesin, neden sadece GET ve POST mümkün olsun, neden yalnızca tüm ekran değiştirilebilsin? Başka bir açıdan bakınca HTMX, HTML öğelerini daha az kısıtlı ve daha genel hale getiriyor. Bir web renderer bunu tasarımda dikkate alırsa hatta daha da basitleşebilir
    • Temel HTMX özelliklerini HTML spesifikasyonuna dahil etmeye yönelik bir hareket var; bu yüzden JS’e gerek kalmayabilir https://www.reddit.com/r/htmx/comments/1ehjw7v/comment/lg09w...
    • Basit. htmx’i Dioxus ile değiştirirsiniz; ileride belki leptos ile

  • Dioxus’u bugün ilk kez öğrendim https://dioxuslabs.com/

  • Gerçekten harika. Bir C++ projesinde denemek isterim Aklıma gelen bir soru performans. Nispeten karmaşık sayfaları yüksek FPS ile render edip edemeyeceğini merak ediyorum Genelde ImGUI kullanıyorum; gerçek zamanlı veri gösterirken performans sorunlarını neredeyse hiç düşünmem gerekmeyecek kadar iyi. Buna karşılık Chromium’un web render’ı, basit DOM metin güncellemelerini saniyede yalnızca 10 kare hızında yapsanız bile CPU’yu yakıyor; bu çözülürse oyunun kuralları değişebilir

    • Mevcut performans berbat Ama optimizasyona henüz hiç emek harcamadık ve oldukça hızlı bağımlılıkların üzerine inşa ediyoruz; bu yüzden çok daha iyi hale gelme potansiyeli var “Adil bir dövüşte” Chromium’u yeneceğimizi sanmıyorum, ama Chrome’da mümkün olmayan şeyleri mümkün kılma potansiyeli var. Örneğin çok daha güçlü canvas benzeri API gibi