Blitz: हल्का, मॉड्यूलर और विस्तार योग्य वेब renderer

 (github.com/DioxusLabs)
2 पॉइंट द्वारा GN⁺ 2024-08-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Blitz एक मॉड्यूलर rendering engine है जो HTML/CSS rendering पर केंद्रित है। इसका design यह है कि यह browser की पूरी capabilities default रूप से नहीं देता, बल्कि जरूरी अतिरिक्त features को optional रखा जाए
  • इसकी मौजूदा स्थिति pre-alpha है। renderer में पहले से काफी capabilities हैं, लेकिन bugs और missing features बहुत हैं, इसलिए इसे apps बनाने के लिए इस्तेमाल करना अभी recommend नहीं किया जाता
  • इसके support goals में modern HTML layout, advanced CSS, HTML form controls, AccessKit-based accessibility, और custom widgets के जरिए विस्तार शामिल हैं। WebRTC, WebSockets, Bluetooth, localStorage जैसे features यह provide नहीं करता
  • architecture core DOM abstraction और networking, rendering, window, state management modules में बंटी है। blitz और dioxus-native नाम के higher-level wrapper crates HTML/Markdown या Dioxus VirtualDom rendering संभालते हैं
  • नया version Blitz v0.2+ Stylo का इस्तेमाल करता है। v0.1 source legacy branch में बचा हुआ है, लेकिन उस पर active development नहीं हो रहा

HTML/CSS rendering पर केंद्रित engine

  • Blitz एक HTML/CSS rendering engine है, और इसकी शुरुआत इस सोच से हुई कि default use case, यानी HTML/CSS rendering, की तुलना में browsers बहुत भारी हो गए हैं
  • लक्ष्य browser features का पूरा set implement करना नहीं है, बल्कि HTML/CSS rendering के लिए जरूरी features को केंद्र में रखना और बाकी features को जहां तक हो सके opt-in बनाना है
  • फिलहाल यह pre-alpha स्थिति में है
    • renderer में पहले से काफी capabilities हैं
    • अभी भी bugs और missing features बहुत हैं
    • apps बनाने के लिए इसका इस्तेमाल करना अभी recommend नहीं किया जाता
    • ज्यादा detailed progress roadmap issue में देखी जा सकती है

जिन features को support करना है और जिन्हें exclude किया गया है

  • Blitz का intended scope HTML/CSS UI rendering के अनुसार तय है
    • flexbox, grid, table, block, inline, absolute/fixed जैसे modern HTML layout
    • complex selectors, media queries, CSS variables जैसी advanced CSS
    • HTML form controls
    • AccessKit-based accessibility
    • custom widgets के जरिए extensibility
  • Blitz WebRTC, WebSockets, Bluetooth, localStorage जैसे features provide नहीं करता
    • native apps में ऐसे features का बड़ा हिस्सा सामान्य Rust crates से handle किया जा सकता है
    • इसका रुख यह है कि ऐसे features को renderer से जोड़ना जरूरी नहीं है
  • JavaScript, Python आदि दूसरी languages की bindings अभी नहीं हैं, लेकिन उनसे जुड़े contributions स्वीकार किए जा सकते हैं

चलाने का तरीका और examples

  • repository clone करने के बाद browser package run किया जा सकता है
cargo run --release --package browser
  • examples के रूप में एक छोटा TODO app, Markdown renderer, और raw WGPU rendering integration दिए गए हैं
cargo run --release --package todomvc

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

cargo run --release --package wgpu_texture

मॉड्यूलर architecture

  • Blitz core DOM abstraction, अतिरिक्त feature modules, और दो higher-level wrappers से बना है
    • networking, rendering, window, state management जैसी capabilities अलग-अलग modules में बंटी हैं
    • इन हिस्सों को मिलाकर एक web engine बनाया जा सकता है

  • higher-level wrapper crates

    • blitz: HTML strings render कर सकने वाला HTML/Markdown frontend
    • HTML या Markdown files के preview के लिए उपयोगी है
    • फिलहाल इसमें interaction नहीं है
    • blitz-dom, blitz-html, blitz-shell, blitz-renderer-vello का इस्तेमाल करता है
    • dioxus-native: Dioxus VirtualDom render करने वाला Dioxus frontend
    • Dioxus event handling के जरिए full interaction support करता है
    • blitz-dom, dioxus-core, blitz-shell, blitz-renderer-vello का इस्तेमाल करता है
    • दोनों wrappers sub-resources लाने के लिए optional रूप से blitz-net का इस्तेमाल कर सकते हैं

  • core crates और अतिरिक्त crates

    • blitz-dom: style resolution, layout, event handling शामिल करने वाला core DOM abstraction
    • parsing, rendering, system integration शामिल नहीं करता
    • Stylo, Taffy, Parley का इस्तेमाल करता है
    • blitz-traits: minimal base crate जो दूसरे crates को सीधे एक-दूसरे पर depend किए बिना interoperate करने देता है
    • blitz-net: HTTP, filesystem, encoded data URI से resources fetch करने वाला networking module
    • reqwest का इस्तेमाल करता है
    • blitz-paint: blitz-dom tree को anyrender draw commands में बदलता है
    • anyrender का इस्तेमाल करता है
    • blitz-html: blitz-dom में HTML parsing जोड़ता है
    • html5ever और xml5ever का इस्तेमाल करता है
    • blitz-shell: shell जो Blitz को window में render करने देता है
    • Winit event loop, AccessKit, Muda आदि को integrate करता है
    • winit, accesskit, muda का इस्तेमाल करता है
    • AnyRender rendering abstraction को अलग repository anyrender में move कर दिया गया है

Dioxus Native development version का इस्तेमाल

  • Dioxus Native का latest development version इसी repository में है
  • क्योंकि Dioxus Native तेजी से develop हो रहा है, official release से पहले latest features और bug fixes इस्तेमाल करने के लिए git version का उपयोग किया जा सकता है
  • git version इस्तेमाल करने की प्रक्रिया इस प्रकार है
    • dioxus crate dependency को पूरी तरह हटाएं
    • dioxus-native = { git = "https://github.com/DioxusLabs/blitz";, rev = "e64a3d8", features = ["prelude"] } जोड़ें
    • e64a3d8 को इच्छित version के git commit id से बदलें
    • Rust code में use dioxus::prelude::* को use dioxus_native::prelude::* में बदलें
    • अगर ऐसी dioxus functionality चाहिए जिसे Dioxus Native prelude export नहीं करता, तो dioxus-html, dioxus-signals, dioxus-router आदि individual sub-crates से import करें
  • Dioxus Native का git version crates.io के stable version Dioxus v0.7.x पर अब भी depend करता है
    • dioxus-sdk, dioxus-components, dioxus-free-icons जैसी अतिरिक्त libraries काम करती रहनी चाहिए

version और license

  • इस repository में Blitz v0.2+ का नया version है और यह Stylo का इस्तेमाल करता है
  • पिछला version v0.1 source legacy branch में मौजूद है
    • v0.1 पर active development नहीं हो रहा
  • project Apache 2.0 और MIT dual license के तहत distribute किया जाता है
  • Servo project के साथ interoperability आसान बनाने के लिए stylo_taffy crate पर MPL 2.0 भी अतिरिक्त रूप से लागू है
    • इसलिए stylo_taffy Apache 2.0, MIT, MPL 2.0 की triple license में है
  • Blitz में जानबूझकर submit किए गए contributions, जब तक अलग शर्तें न हों, Apache 2.0 और MIT के तहत dual licensed माने जाते हैं
    • stylo_taffy में submit किए गए contributions में MPL 2.0 भी शामिल है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-08-13
Hacker News की रायें

  • मैं Blitz का lead developer हूँ। यह अभी पूरा नहीं हुआ है, और text input/focus system बुनियादी है; root viewport के अलावा scrolling सपोर्ट नहीं है nth-child, :has जैसे जटिल CSS selectors अभी ठीक से काम नहीं करते, और Blitz के ऊपर चलने वाले React-जैसे framework Dioxus के साथ event handling integration भी सिर्फ click तक सीमित है; preventDefault भी नहीं है networking अभी बहुत simple है, main thread पर synchronous requests कर रहा है, और सही asynchronous या multithreaded networking की ज़रूरत है performance पर भी लगभग काम नहीं हुआ है, इसलिए हर frame में style/layout/paint दोबारा calculate हो रहे हैं, और साफ़ न होने वाले nodes की वजह से कुछ जगह memory leaks भी हैं shadows, web fonts, calc, float layout, text input के अलावा form controls भी अभी नहीं हैं। कुल मिलाकर यह “webview बनाना बड़ा काम है और हम अभी वहाँ तक नहीं पहुँचे” जैसा है, और 2–3 महीनों में एक अधिक complete रूप की उम्मीद है screenshot यहाँ भी हैं: https://github.com/DioxusLabs/blitz/issues/23

    • निजी तौर पर, मैं एक नया document format design करना चाहता हूँ जिसकी semantics ज़्यादा simple हों और जिसे render करना आसान हो HTML काफी complex लगता है, और इसे dynamic rendering के लिए design भी नहीं किया गया था। lean और KISS पसंद करने वाले व्यक्ति के नाते HTML मुझे पर्याप्त lightweight या simple नहीं लगता
    • मैं websites के screenshots capture करने का solution ढूँढ रहा था, और संभव हो तो पहले से crawled representation से बनाना चाहता था मौजूदा services आम तौर पर Chromium instance चालू करके screenshot request करती हैं, इसलिए operating cost और SaaS cost दोनों काफी महंगे लगते हैं। ऐसे में Blitz अच्छा fit लगता है, लेकिन जानना चाहता हूँ कि क्या इसे अभी headless mode में चलाकर screenshot save किया जा सकता है
    • Servo या WebKit जैसी चीज़ों के ऊपर बनाने के बजाय, कई components को खुद जोड़ने की प्रेरणा क्या है, यह जानना चाहता हूँ
    • सबसे जटिल engineering हिस्सा कौन सा है जिसे संभालना पड़ता है, यह जानना चाहता हूँ। अगर अभी काम जारी है तब भी design documents share कर सकें तो अच्छा होगा निजी तौर पर मुझे इसमें दिलचस्पी है कि आगे चलकर Blitz, Servo जैसे engines को formal methods से कैसे बनाया जा सकता है। उदाहरण के लिए definitions से शुरू करके system के कुछ हिस्से generate करने का तरीका, और आजकल इसमें LLM भी शामिल हैं, लेकिन मैं इसे AI system से ज़्यादा बेहतरीन tools जैसा देखता हूँ। Z3 जैसी चीज़ भी याद आती है मेरी कुछ companies में भी ऐसे topics पर research organizations हैं
    • जानना चाहता हूँ कि क्या Blitz इसलिए बनाया गया है कि दूसरे लोग browser बना सकें मैं Wootzapp(https://github.com/wootzapp/wootz-browser) बना रहा हूँ, जो data labeling के लिए Robinhood जैसी service है जहाँ web data या image labeling पर समय लगाकर reward मिल सकता है अभी यह Chromium-based है, और जानना चाहता हूँ कि क्या Blitz ऐसा renderer बनना चाहता है जिसे दूसरे browsers में plug in किया जा सके। हम mobile भी कर रहे हैं; अभी Android है, अगला iOS है

  • यह project पहली नज़र में ही बहुत उपयोगी लगता है widely used HTML/CSS layout paradigm से native apps बनाना, लेकिन full JS/DOM/browser APIs से आने वाले भारी हिस्सों को हटाना—यह तरीका Electron की तरह browser engine package करने की तुलना में बहुत बड़ा सुधार संभव कर सकता है संयोग से, हाल में Richard Feldman के podcast में Casey Muratori को CSS की बहुत आलोचना करते सुना। simple layout relationships बनाने के लिए web page को pre-render करके dynamically measure करना पड़ा—ऐसे examples खासकर असरदार लगे Muratori के शब्दों में, CSS लिखना simple primitives पर build करने जैसा नहीं, बल्कि court में case argue करने जैसा लगता है बेशक familiarity, compatibility, और “happy path CSS” की जबरदस्त productivity की वजह से ऐसे project जिस demand को satisfy करते हैं वह बड़ी है। लेकिन ऐसा भी मौका दिखता है कि users को नीचे उतरकर इस्तेमाल करने के लिए एक अधिक simple और general layer दी जाए CSS को JS API से extensible बनाने की कोशिश CSS Houdini से inspiration ली जा सकती है, और शायद “Custom Widgets” का मतलब भी यही हो सकता है

    • लगभग यही Blitz के प्रस्ताव जैसा है pluggable layout algorithms एक ऐसी चीज़ है जिसे Blitz में ज़रूर संभव बनाना चाहता हूँ। layout को JS में करने पर अधिकतर मामलों में वह बहुत slow होगा, लेकिन API Rust होने से फायदा है layout engine Taffy(https://github.com/DioxusLabs/taffy) भी पहले से काफी modular है custom widgets का मतलब layout से आगे जाकर पारंपरिक GUI toolkit के widgets की तरह पूरी तरह custom layout, paint, accessibility, event handling आदि की अनुमति देना है CSS में ही नई unit जोड़ने का प्रस्ताव भी है। यह web के बाहर कई UI systems के layout तरीकों से प्रेरित है, और common cases में web layout को काफी simplify कर सकता है: https://github.com/w3c/csswg-drafts/issues/8267 कुछ समय से यह पीछे धकेला गया था, लेकिन किसी दिन फिर करना होगा, और सच में algorithm implement करके देखना चाहता हूँ
    • क्या यह improved Dillo जैसा महसूस होता है, यह जानना चाहता हूँ: https://en.m.wikipedia.org/wiki/Dillo simple web browsing या apps के लिए ऐसी चीज़ हो तो अच्छा होगा। मुझे जो मिलता-जुलता पता था वह सिर्फ Sciter था, और वह proprietary software था, लेकिन उसकी licensing approach innovative थी
    • unnecessary चीज़ें हटाकर performance improvement का वादा करने वाला strict CSS चाहिए। browsers अभी तक इसे क्यों नहीं देते, समझ नहीं आता; उदाहरण के लिए सिर्फ float हटाना भी काफी होगा

  • कुछ साल पहले, नहीं, 20 साल पहले मैंने Flying Saucer नाम का मिलता-जुलता open-source project बनाया था। यह pure Java-based HTML + CSS2 renderer था मैंने सोचा था कि इसका उपयोग games में rich text UI render करने के लिए होगा, लेकिन असली मुख्य use server-side PDF generation निकला। उस समय उपलब्ध कई PDF report generation APIs इस्तेमाल करने की तुलना में HTML generate करके PDF में render करना कहीं आसान था Blitz शानदार दिखता है, और Rust GUI libraries और बढ़ेंगी, यह देखकर उत्साहित हूँ https://en.wikipedia.org/wiki/Flying_Saucer_(library) हैरानी की बात है कि यह अभी भी update हो रहा है: https://github.com/flyingsaucerproject/flyingsaucer/releases...

  • “JavaScript इंजन को native Rust API से बदलने वाला हल्का webview” — यह promising लगता है। मूल रूप से अगर यह JS को path से हटाने वाला Tauri जैसा है, तो सुनने में ही अच्छा है

    • कुछ हद तक सही है, लेकिन Tauri system webview इस्तेमाल करता है, जबकि हम अपना खुद का webview बना रहे हैं कुछ हिस्सा Servo components और general-purpose libraries के ऊपर है, और कुछ हमने खुद बनाया है। कुछ मायनों में यह JS के बिना Sciter के ज्यादा करीब है
    • Sciter शायद बेहतर comparison होगा: https://sciter.com/ यह HTML और CSS rendering को scratch से implement करता है। जहाँ तक याद है, पहले इसकी अपनी programming language थी और अब JS इस्तेमाल करता है मुझे इस तरह की चीज़ों में लंबे समय से दिलचस्पी रही है, लेकिन Sciter को गहराई से इस्तेमाल नहीं किया। पहले licensing की चिंता थी, पर अब साइट देखकर लगता है कि शर्तें काफी ज्यादा flexible हो गई हैं यह भी जोड़ने लायक है कि अगर आप system webview में JS के बिना इस्तेमाल करना चाहते हैं, तो बस system webview में JS बंद कर सकते हैं
    • Tauri native webview इस्तेमाल करता है, इसलिए यह हर platform पर अलग होता है। Blitz का अपना renderer है

  • दिलचस्प। आज ही puppeteer और headless Chromium की वजह से बहुत बुरा अनुभव हुआ और मैं wkhtmltopdf का replacement ढूँढ रहा था LD_PRELOAD में jemalloc डालकर चलाना बिल्कुल नहीं करना चाहिए। समस्या हल हो गई, लेकिन मुझे एक simple renderer वाला रास्ता ज्यादा पसंद आया

    • आप PDF rendering use case में रुचि दिखाने वाले पहले व्यक्ति नहीं हैं शायद print-oriented CSS properties और page-based layout support की ज्यादा जरूरत होगी। यानी layout को कई अलग-अलग pages में बाँटना और page break की जगह control करना फिर भी मुझे लगता है कि यह ऐसा क्षेत्र है जिसे किसी दिन निश्चित रूप से support कर पाना चाहिए
    • मेरा use case थोड़ा अलग था। मैं Playwright में Chromium Headless का इस्तेमाल करके page के एक element को render करने की कोशिश कर रहा था, लेकिन Playwright में "Page crashed" और "Timed out after 30s" randomly बहुत ज्यादा आ रहे थे Firefox Headless पर switch करने पर ये समस्याएँ गायब हो गईं, और असल में Firefox पर switch करने के बाद renderer Chromium Headless से करीब 3x तेज हो गया Blitz बहुत दिलचस्प है और मेरी जरूरत के काफी करीब है। मैं सब कुछ सीधे Java Graphics2D से render करने के बजाय headless browser इस्तेमाल कर रहा था, क्योंकि render किए जाने वाले target का layout थोड़ा complex था और मैं अपना layout engine बनाकर wheel reinvent नहीं करना चाहता था
    • gotenberg[0] देख लें, शायद आपकी जरूरत पूरी कर दे। मैं GitHub Actions में resume को PDF में convert करने के लिए इसका इस्तेमाल कर रहा हूँ [0]: https://github.com/gotenberg/gotenberg
    • सही है, Wkhtmltopdf सचमुच resource खाने वाला monster है दूसरी solutions में HTML spec support अधूरा है, इसलिए मनचाहा PDF ठीक से बनाना मुश्किल होता है। जब तक कोई less modern features से ही तरीका न निकाल ले

  • यह सीधे Blitz के बारे में नहीं है, लेकिन मुझे Dioxus के बारे में पहली बार पता चला सोचता हूँ कि क्या WASM में compile होने वाले frameworks के बीच कोई unspoken rule है कि वे demo ठीक से नहीं दिखाते या अपनी site को उसी framework से खुद host नहीं करते। लगता है ऐसा 5–6 बार देख चुका हूँ Dioxus homepage पर WASM file load होती दिखती है, लेकिन यह साफ नहीं है कि वह कहाँ इस्तेमाल हो रही है या वाकई इस्तेमाल भी हो रही है या नहीं

    • Dioxus site अपने ही framework से host की गई है, लेकिन क्योंकि यह server-side rendering और hydration support करती है, WASM bundle सिर्फ interaction features के लिए इस्तेमाल होता है Video demo भी तैयार हो रहा है। जानना चाहूँगा कि आप खास तौर पर क्या देखना चाहते हैं

  • Backend के साथ htmx इस्तेमाल किया जाए तो शानदार हो सकता है। हालांकि लगता है कि JS engine बिल्कुल भी शामिल नहीं है, इसलिए सोच रहा हूँ कि यह कैसे किया जा सकेगा

    • यह legendary combination हो सकता है ideally web renderer को HTMX को natively support करना चाहिए HTMX का सामान्य idea यह है कि HTML को ज्यादा complete बनाने वाली capabilities support की जाएँ। क्यों सिर्फ और ही HTTP requests कर सकें, क्यों सिर्फ click और submit events ही requests trigger करें, क्यों सिर्फ GET और POST ही possible हों, क्यों सिर्फ पूरी screen ही replace की जा सके दूसरे तरीके से देखें तो HTMX HTML elements को कम restrictive और ज्यादा general बनाता है। अगर web renderer design करते समय इसे ध्यान में रखे, तो यह उल्टा और simple भी हो सकता है
    • core HTMX features को HTML spec में डालने की कोशिश चल रही है, जिससे शायद JS की जरूरत न रहे https://www.reddit.com/r/htmx/comments/1ehjw7v/comment/lg09w...
    • आसान है। htmx को Dioxus से बदल दें, या बाद में शायद leptos से

  • Dioxus के बारे में आज पहली बार पता चला https://dioxuslabs.com/

  • सच में शानदार। C++ project में इस्तेमाल करके देखना चाहूँगा एक सवाल जो मन में आया वह performance है। सोच रहा हूँ कि क्या यह अपेक्षाकृत complex page को high frames per second पर render कर सकता है आम तौर पर मैं ImGUI इस्तेमाल करता हूँ, और real-time data दिखाते समय performance issues के बारे में मुश्किल से सोचना पड़ता है, इतना अच्छा है। दूसरी ओर Chromium की web rendering तो simple DOM text update को 10 frames per second पर करने भर से CPU जला देती है; अगर यह solve हो जाए तो खेल बदल सकता है

    • अभी performance खराब है लेकिन optimization पर अभी बिल्कुल मेहनत नहीं की गई है, और हम काफी तेज dependencies के ऊपर बना रहे हैं, इसलिए इसके काफी बेहतर होने की संभावना है “fair fight” में शायद Chromium को नहीं हरा पाएँगे, लेकिन इसमें ऐसी चीजें संभव करने की क्षमता है जो Chrome में संभव नहीं हैं। जैसे कि कहीं ज्यादा powerful canvas-जैसी API