Dioxus 0.5: Rust से वेब, डेस्कटॉप और मोबाइल ऐप डेवलपमेंट

 (dioxuslabs.com)
3 पॉइंट द्वारा GN⁺ 2024-03-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Rust GUI framework Dioxus 0.5 ने dioxus-core के पुनर्लेखन और unsafe हटाने पर ध्यान देते हुए web·desktop·mobile·Fullstack डेवलपमेंट flow को काफी सरल बनाया है
  • 0.4.3 से 0.5.0 के बीच 100,000 लाइनों से अधिक कोड और 1,400 से अधिक commits जोड़े गए, और नया core lifetimes तथा Scope dependency को हटाने की दिशा में बदला गया
  • पहले का use_state·use_ref केंद्रित state management अब Copy-योग्य Signal API से बदला गया है, जिससे event handlers और future में बार-बार Clone करने का बोझ कम होता है
  • एक ही dioxus::launch और dx serve --platform flow से web, desktop, Fullstack apps चलाए जा सकते हैं, और CLI target platform के अनुसार build features अपने आप पास करता है
  • asset hot reload, event rewrite, desktop rendering improvements, और server function streaming के साथ एक single Rust codebase का उपयोग-क्षेत्र और व्यापक हो गया है

Dioxus 0.5 की रिलीज़ दिशा

  • Dioxus, Rust से GUI बनाने की library है, और इसका उपयोग web app·desktop app·mobile app deploy करने में होता है
  • 0.5 release को community द्वारा मांगी गई सरलता, मजबूती, और completeness बढ़ाने के लक्ष्य से डिज़ाइन किया गया है
  • मुख्य बदलाव इस प्रकार हैं
    • dioxus-core का पूर्ण पुनर्लेखन और unsafe code हटाना
    • use_state, use_ref की जगह Signal आधारित API लाना
    • सभी lifetimes और cx: Scope state हटाना
    • सभी platforms पर app शुरू करने के लिए एक single launch function
    • Tailwind और Vanilla CSS को support करने वाला asset hot reload
    • native WebSys event types तक पहुँच देने वाला event rewrite
    • Error Boundary, Server Future, Suspense integration
    • desktop reconciliation में 5 गुना सुधार
    • server function streaming और Fullstack hot reload
  • Dioxus 0.4 से update करने वाले users के लिए migration guide उपलब्ध है

Lifetimes और Scope हटाना

  • Dioxus 0.1 से 0.4 तक component के अंदर की values में 'bump lifetime होती थी, जिससे event listeners में hooks, props, scope को बिना clone के उपयोग किया जा सकता था
  • event handlers में यह ज़्यादातर ठीक काम करता था, लेकिन Dioxus के future को 'static होना पड़ता था, इसलिए values को future में ले जाने से पहले clone करना पड़ता था
  • lifetime error आने पर message hook की जगह इस तरह आता था कि cx को 'static से ज़्यादा समय तक जीवित रहना चाहिए, जिससे भ्रम हो सकता था
  • Dioxus 0.5 ने Scope और 'bump lifetime हटाकर Element को lifetime-free रूप में बदल दिया है
  • अब component scope parameter के बिना सीधे props ले सकते हैं
    • उदाहरण: fn MyComponent(name: String) -> Element
  • runtime functions अब सिर्फ component के अंदर ही नहीं, बल्कि future और event handlers के अंदर भी सीधे उपयोग की जा सकती हैं
  • Element के 'static हो जाने से इसे hooks के अंदर उपयोग करना या context API के जरिए उपलब्ध कराना भी संभव हो गया है
  • यह बदलाव virtual list या offscreen rendering जैसे APIs को लागू करना आसान बनाने की बुनियाद देता है

dioxus-core से unsafe हटाना

  • 'bump lifetime और scope हटाने से Dioxus के अंदर के unsafe code को कम करने का मौका मिला
  • dioxus-core 0.5 में unsafe code नहीं है
  • कुछ dependencies में थोड़ा unsafe अभी भी बचा है, और Dioxus team का लक्ष्य 0.5 release cycle के दौरान इसे हटाना है
  • बचे हुए unsafe को या तो आसानी से हटाए जा सकने वाले हिस्सों या FFI के कारण ज़रूरी हिस्सों में बाँटा गया है

Signal आधारित state management

  • Dioxus 0.5 ने component के मुख्य state primitive के रूप में Signal पेश किया है
  • Signal के use_state, use_ref की तुलना में दो फायदे हैं
    • यह हमेशा Copy हो सकता है
    • manual subscription की ज़रूरत नहीं होती

  • Copy state

    • Signal<T> अंदर का T Copy न होने पर भी Copy होता है
    • यह व्यवहार unsafe के बिना बने generational-box crate की वजह से संभव हुआ है
    • ज़रूरत पड़ने पर Signal को Send+Sync बनाया जा सकता है ताकि उसे threads के बीच ले जाया जा सके
    • Copy state, Send+Sync Signal, और static components के संयोजन से state को future, event handlers, threads जैसी ज़रूरी जगहों पर आसानी से ले जाया जा सकता है
    • memory usage का तरीका 0.4 जैसा ही है, लेकिन explicit Clone की ज़रूरत नहीं पड़ती

  • Smart subscription

    • Signal value बदलने पर यह अधिक बारीकी से तय करता है कि किन components को फिर से चलाना है
    • component तभी फिर से execute होता है जब उसने Signal value पढ़ी हो
    • async task या event handler के अंदर पढ़ना component re-execution subscription नहीं माना जाता
    • अगर parent button click से Signal बदलता है लेकिन value को खुद नहीं पढ़ता, और child ही value पढ़ता है, तो सिर्फ child फिर से render होगा
    • इस संरचना की वजह से अलग state management crate Fermi की ज़रूरत नहीं रह जाती
    • Fermi, static को key की तरह इस्तेमाल करने वाला use_state जैसा API देता था
    • Dioxus 0.5 में GlobalSignal को static में रखकर सामान्य Signal की तरह उपयोग किया जा सकता है
    • Signal, context API के साथ भी काम करता है, इसलिए अलग use_shared_state hook के बिना components के बीच state share की जा सकती है
    • use_future, use_memo जैसे hooks के अंदर Signal पढ़ने पर वह अपने आप hook dependency में जुड़ जाता है

CSS और asset hot reload

  • Dioxus 0.5 ने asset system overhaul के हिस्से के रूप में asset directory की CSS files के लिए hot reload लागू किया है
  • जब CSS file RSX में दिखाई देती है, तो dx CLI उस file को watch करता है और running app में updates तुरंत stream करता है
  • यह Web, Desktop, Fullstack पर समर्थित है, जबकि mobile support आगे mobile-केंद्रित update में आएगा
  • Tailwind watcher के साथ उपयोग करने पर Tailwind CSS hot reload भी समर्थित है
  • VSCode में custom regex extension के जरिए Tailwind class hinting भी मिल सकती है
  • changes को कई devices पर एक साथ stream करके सभी target devices पर hot reload किया जा सकता है

Event system का पुनर्लेखन

  • Dioxus ने लॉन्च के बाद से cross-platform event API बनाने के लिए synthetic event system का उपयोग किया है
  • Synthetic event platform के बीच event behavior और network serialization के लिए उपयोगी था, लेकिन इसकी सीमाएँ भी थीं
  • Dioxus 0.5 अब हर platform के underlying event type को expose करता है, और cross-platform API के लिए traits भी देता है
  • इस बदलाव के दो फायदे हैं
    • platform event type से ज़रूरी जानकारी सीधे ली जा सकती है या दूसरी libraries को दी जा सकती है
    • app जिन events का उपयोग नहीं करती, उनके code का bundle splitting किया जा सकता है
  • hello world उदाहरण में gzipped size लगभग 25% कम हो गई
  • छोटा bundle बनाने के tips Dioxus optimization guide में शामिल हैं

Cross-platform execution API

  • Dioxus 0.5 app चलाने के लिए नया cross-platform API लाया है
  • अलग renderer package import करने के बजाय dioxus crate में feature enable करके prelude का launch function call करना होता है
  • एक ही app को इन platforms के लिए चलाया जा सकता है
    • Desktop: dx serve --platform desktop
    • SPA Web: dx serve --platform web
    • Fullstack: dx serve --platform fullstack
  • CLI target platform के अनुसार सही build features अपने आप पास करता है

Asset system beta और Manganis

  • Dioxus और web apps में asset paths जल्दी पुराने हो सकते हैं, desktop और web में links अलग हो सकते हैं, और bundle में शामिल assets को manually जोड़ना पड़ता है
  • assets performance bottleneck भी बन सकते हैं
  • Dioxus Mobile guide example में 0.4 version को load होने में 7 सेकंड लगे और 9MB resources transfer हुए
  • 0.5 mobile guide उसी image का उपयोग करते हुए 1 सेकंड से कम समय में load होती है और ज़रूरी resources 1/3 रह जाते हैं
  • Dioxus 0.5 नया asset system manganis लाता है
    • यह CLI के साथ integrate होकर app assets को inspect, bundle, और optimize करता है
    • API अभी unstable है, इसलिए इसे अलग crate के रूप में publish किया गया है
    • mg! macro में asset wrap करने पर CLI इसे अपने आप detect कर लेता है
    • अधिक जानकारी manganis docs में है
  • 0.5 release के दौरान manganis assets में hot reload जोड़ने की भी योजना है

Desktop rendering में 5 गुना सुधार

  • Dioxus rendering diff को तेज़ी से बनाने के लिए कई optimizations का उपयोग करता है
  • Templates, rsx! macro के static हिस्सों के diff को skip करने देते हैं
  • Dioxus Web में sledgehammer के जरिए Rust से DOM changes तेज़ी से apply किए जाते हैं
  • Dioxus 0.5 यही तरीका network के जरिए changes apply करने में भी उपयोग करता है
  • Desktop और LiveView renderer, changes को JSON के बजाय binary protocol से communicate करते हैं
  • rendering-heavy workloads में नए renderer के साथ browser में changes apply करने का समय 1/5 रह गया और latency 1/2 हो गई
  • Dioxus 0.4 में जहाँ renderer लगातार रुक जाता था, वही benchmark Dioxus 0.5 में smoothly चलता है

Component लिखने की सुविधा

  • Dioxus 0.5 किसी खास element को extend करने और attributes को element पर spread करने की सुविधा देता है
    • उदाहरण: img element attributes को extend करने वाला ImgPlus component, width, height, src जैसे सामान्य img attributes वैसे ही ले सकता है
  • attributes और components को values पास करते समय struct initialization shorthand syntax उपयोग किया जा सकता है
    • class: class की जगह सिर्फ class लिखा जा सकता है
  • shorthand attributes, IntoAttribute implement करने वाली सभी चीज़ों पर काम करते हैं, और Signal को भी इसका लाभ मिलता है
  • Signal attributes अभी diffing skip नहीं करते, लेकिन 0.5 release cycle के दौरान performance optimization के रूप में इसे जोड़े जाने की योजना है
  • कई lines में बँटे attributes merge किए जा सकते हैं
    • एक ही class attribute में conditional values जोड़ने पर वे space delimiter से merge होती हैं
    • यह Tailwind जैसी libraries के लिए महत्वपूर्ण है, जिन्हें compile-time parsing के साथ runtime dynamic processing भी चाहिए
    • यह syntax Tailwind compiler के साथ integrate होकर tailwind-merge जैसी libraries के runtime overhead को हटा देता है

Server function streaming और Fullstack

  • Dioxus 0.5 streaming data को support करने वाले नवीनतम server functions crate को support करता है
  • server functions, client तक data stream कर सकते हैं या client से server तक data stream कर सकते हैं
  • streaming server functions output type define करके और server function से TextStream return करके बनाए जा सकते हैं
  • ये लंबे समय तक चलने वाले tasks के दौरान client को update करने के लिए उपयुक्त हैं
  • Kalosm और local LLM का उपयोग करके सामान्य hardware पर OpenAI ChatGPT endpoint जैसी functionality देने वाला एक example मौजूद है
  • CLI अब fullstack platform को support करता है, और client व server के लिए hot reload तथा parallel builds देता है
    • dx serve
    • dx serve --platform fullstack

LiveView, asset handler, और file handling

  • Dioxus 0.5 में router, LiveView apps में default रूप से काम करता है
  • Dioxus Desktop custom asset handler को support करता है
  • Custom asset handler, Rust code से JavaScript के बिना browser तक data को efficiently stream करने देता है
  • यह video streaming जैसे high-bandwidth communication के लिए उपयुक्त है
  • gstreamer या webrtc data को सीधे webview तक भेजा जा सकता है, जिससे frames को सीधे encode·decode करने की ज़रूरत कम होती है
  • desktop का file drop भी event system में native रूप से integrate किया गया है

Error handling

  • Dioxus, Error Boundary और throw trait के जरिए parent components में errors को आसानी से handle करने देता है
  • throw तरीका error state और early return के फायदे जोड़ता है
  • Debug implement करने वाले Result type पर throw call करके उसे error state में बदला जा सकता है, और ? से early return किया जा सकता है
  • ErrorBoundary component, child से throw की गई error होने पर दूसरा component render करता है
  • ErrorBoundary को nest किया जा सकता है, इसलिए app के कई levels पर errors पकड़ी जा सकती हैं
  • यह pattern तब उपयोगी है जब unrecoverable errors आने पर panic करने या हर error के लिए state manually manage किए बिना global error state handle करनी हो

Developer experience और templates

  • Dioxus ने 0.3 में hot reload पेश किया, 0.4 में इसे Desktop पर जोड़ा, और 0.5 में इसे default enable किया
  • dx serve से app चलाने पर development mode में hot reload default रूप से चालू रहता है
  • Desktop app में hot reload संभव न होने पर और full recompilation की ज़रूरत पड़ने पर भी खुली window की state को preserve और restore किया जाता है
    • app window का size और position बनी रहती है
    • edit करते समय app के पूरे screen को block करने की स्थिति कम होती है
  • नए templates को इस तरह व्यवस्थित किया गया है कि Web, Desktop, Mobile, TUI, Fullstack apps एक ही command से बनाए जा सकें
  • dx new का default app अब create-react-app के करीब बदला गया है
    • इसमें assets, CSS, और basic deployment settings शामिल हैं
    • इसमें dioxus-std, VSCode Extension, docs, tutorial जैसी उपयोगी resources के links शामिल हैं

Dioxus Community और ecosystem

  • Dioxus Community ने 0.5 release के लिए महत्वपूर्ण ecosystem crates को update किया है
  • icons, charts, और Dioxus-विशेष standard library जैसे crates को 0.5 release के समय ही उपयोग के लिए तैयार किया गया
  • Dioxus Community project एक नया GitHub organization है, जिसका उद्देश्य यह सुनिश्चित करना है कि मूल maintainer के हटने पर भी महत्वपूर्ण crates up to date रहें
  • अगर आप Dioxus के लिए library बना रहे हैं, तो Dioxus पक्ष उसके maintenance में मदद कर सकता है, और लक्ष्य व्यावहारिक रूप से उसे “Tier 2” support की तरह बनाए रखना है

आगे की योजनाबद्ध सुविधाएँ

  • 0.5 के बाद की योजनाओं में ये शामिल हैं
    • asset system को stabilize करना और उससे गहरा integration
    • lazy components के साथ output .wasm का direct bundle splitting
    • Islands, resumable interactivity, और Signal serialization
    • Server component और LiveView को Fullstack में merge करना
    • बेहतर Devtools और testing framework
    • पूरा Mobile overhaul
    • WebSocket, SSE, progressive form सहित Fullstack overhaul

Servo-आधारित Dioxus-Blitz की झलक

  • Dioxus-Blitz के “Blitz 2.0” में Servo को integrate करके Firefox जैसी CSS engine के साथ WGPU native rendering का लक्ष्य रखा गया है
  • Taffy layout library बनाने वाले Nico Burns इस काम को आगे बढ़ाने के लिए full-time जुड़े हैं
  • demo में google.com को GPU पर 900 FPS में render किया गया
  • मौजूदा implementation अभी पूरी नहीं है और google.com rendering भी कुछ असहज लगती है, लेकिन यह तेज़ी से usable स्तर के करीब पहुँच रही है
  • repository यहाँ देखी जा सकती है: https://github.com/jkelleyrtp/stylo-dioxus

योगदान कैसे करें

  • Dioxus project इन तरह के contributions चाहता है
    • documentation translation
    • “Good First Issues” आज़माना
    • documentation सुधार
    • CLI contribution
    • Discord community में सवालों के जवाब देना
  • Dioxus team ने 2024 के बाकी समय में community support के लिए आभार जताया और app development बदलने में मदद मांगी है

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

1 टिप्पणियां

 
GN⁺ 2024-03-29
Hacker News टिप्पणियाँ
  • पिछले साल मैंने Dioxus से Mastodon क्लाइंट Ebou बनाया था, और कुल मिलाकर अनुभव अच्छा था, लेकिन इसमें बहुत-सी चीज़ें गायब भी थीं
    जब मैंने काम शुरू किया था तब यह 0.2 वर्ज़न पर था, और अब 0.5 में हुए बदलावों से लगता है कि उस समय जो जटिलताएँ थीं, उनमें से ज़्यादातर लगभग खत्म हो गई हैं। मैंने अभी खुद इसे आज़माया नहीं है, लेकिन lifetime हटने और बार-बार clone करने की मजबूरी कम होने से यह काफी ज़्यादा आरामदायक लग रहा है
    • जानना चाहता हूँ कि आपने Dioxus कैसे चुना
      Rust framework काफ़ी हैं जो native reactive UI के लिए desktop, web/wasm, mobile वगैरह पर deploy हो सकते हैं, https://github.com/flosse/rust-web-framework-comparison, इसलिए गलत चुनाव होने पर किसी छोड़े गए framework को ढोना पड़े या दर्दनाक migration करनी पड़े, यह चिंता रहती है
      Rust HTTP server framework का हाल भी कुछ ऐसा ही था, लेकिन अब Axum, Actix, Rocket आगे दिखते हैं, और community का रुझान Axum की तरफ जाता हुआ लगता है, इसलिए कभी-कभी लगता है कि कहीं Actix चुनना गलत तो नहीं था। क्या Dioxus के जीतने के कोई संकेत हैं, और बड़े community, YC समर्थन, और momentum के अलावा अभी इसे चुनने के लिए कोई और संकेतक हैं?
      क्या Leptos और Yew भी इसके बड़े competitor हैं, और वे Dioxus से बेहतर या बदतर क्यों हैं, यह भी जानना चाहता हूँ। हमारी कंपनी ने Rust, Actix, और Bevy में काफी निवेश किया है, और आगे Bevy तथा Dioxus जैसे framework को जोड़कर native desktop और mobile client बनाना चाहती है
      और यह भी जानना चाहता हूँ कि Dioxus नाम Pokémon के Deoxys से आया है या नहीं। लोगो देखकर वैसा लगता है, लेकिन codebase में Pokémon का कोई reference नहीं है
  • “कुल मिलाकर अच्छा था, लेकिन बहुत कुछ गायब था” वाली बात से सहमत हूँ
    करीब 9 महीने पहले मैंने Dioxus से sshfs के लिए एक GUI frontend बनाया था, और जब तक किसी ऐसी दीवार से टकराव न हो जहाँ developer ने अभी तक कोई feature पूरा न किया हो, तब तक यह सच में एक शानदार GUI framework लगता था
    अलग-अलग context के बीच state share करना कभी-कभी तकलीफ़देह होता है, लेकिन भाषा या underlying technology चाहे जो भी हो, मैंने जितने भी GUI framework इस्तेमाल किए हैं, उनमें ऐसा रहा है। Dioxus 0.5 इस मामले में बड़ी प्रगति जैसा लगता है। मेरा ब्लॉग HTML का बड़ा हिस्सा Dioxus से render करता है, और क्योंकि मैं उसे limits तक push नहीं कर रहा, इसलिए वह बहुत अच्छे से काम करता है
  • मैं Dioxus पर दिलचस्पी से नज़र रखे हुए हूँ, लेकिन अभी तक इसे इस्तेमाल करने का मौका नहीं मिला
    लेकिन lifetime removal का समाधान थोड़ा अजीब लग रहा है। generational-box कहीं किसी तरह का गरीबों वाला garbage collector तो नहीं है, यह सोच रहा हूँ, और इसका performance impact कैसा रहा, यह जानना चाहता हूँ
    साथ ही, [generational-box]([https://crates.io/crates/generational-box](<https://crates.io/crates/generational-box>;)) लिंक टूटा हुआ है
    • यह गरीबों वाला garbage collector तो है, लेकिन memory semantics पहले वाले version जैसी ही हैं
      use_hook component की lifetime तक value को own करता है, इसलिए component हटने पर वह value भी drop हो जाती है। सभी signal अब भी use_hook का इस्तेमाल करते हैं, इसलिए उनकी lifetime भी वही रहती है। आम तौर पर use_hook के बाहर GenerationalBox::new() कॉल करने की सलाह नहीं दी जाती, इसलिए performance पर असर नहीं पड़ता
      अगर आप loop के अंदर GenerationalBox::new() का बहुत ज़्यादा इस्तेमाल करेंगे, तो वह garbage component के drop होने तक रहेगा, लेकिन ज़्यादातर मामलों में आप Map या Vec में push/pop करेंगे, और वहाँ सामान्य memory semantics लागू होंगी
    • यह मूल रूप से automatic reference counting है: https://en.wikipedia.org/wiki/Automatic_Reference_Counting
  • मैं Rust programmer नहीं हूँ, लेकिन generational-box crate कैसे काम करता है, यह जानने की उत्सुकता है
    इतना समझता हूँ कि यह किसी तरह का arena allocation है, लेकिन यह “copy किए बिना copy” कैसे support करता है, और अंदर generational RefCell arena बनाकर GenerationalBox को Copy बताना सुरक्षित क्यों है, यह समझ नहीं आता
    static data के pointer बनाए जा सकते हैं, यह समझता हूँ, लेकिन अगर value की static lifetime न हो तो क्या होता है, यह जानना चाहता हूँ
    • इसमें data copy नहीं होता, बल्कि data के reference की copy होती है
      data का reference पूरे program lifetime तक बना रहता है। generational box ऐसे data को रखने देता है जिसकी lifetime program से छोटी हो, लेकिन उस data में reference शामिल नहीं होने चाहिए। डाले गए data को drop करने के बाद उस box को किसी और allocation के लिए reuse किया जाता है
      centralized arena की जगह box इस्तेमाल करने को छोड़ दें, तो यह generational arena जैसा ही काफ़ी मिलता-जुलता तरीका है, और lock की समस्या से बचने के लिए ऐसा चुना गया है। drop होने के बाद अगर आप Copy reference से data access करने की कोशिश करेंगे, तो अच्छा error message मिलेगा और access fail हो जाएगा
    • मैं इस crate को अच्छी तरह नहीं जानता, लेकिन Rust के नज़रिए से देखें तो Copy का एक खास मतलब होता है
      अगर कोई type Copy trait implement करता है, तो उसका मतलब है कि उसे memcpy से copy किया जा सकता है, और यह deep copy नहीं बल्कि shallow copy के ज़्यादा करीब है
      इसलिए इसे “copy किए बिना copy” नहीं, बल्कि non-Copy type को Copy type जैसा handle करने की सुविधा समझता हूँ। README में static content की ज़रूरत बताई गई है, इसलिए static lifetime के बिना value के लिए जवाब यही है कि “ऐसा नहीं किया जा सकता”
  • मैं इसे कुछ समय से देख रहा था, और अब इसके release होने से बहुत खुशी है
    Dioxus में React की सफलता के कई तत्व लिए गए हैं, लेकिन उसके ऊपर तेज़ी से innovation और shipping करने वाली बात मुझे पसंद है। इस release में आए signals को आज़माने का इंतज़ार है
  • काश RSX की जगह कुछ ऐसा होता जो React/JSX से ज़्यादा SwiftUI के करीब होता
    React ने JS और web के लिए जो अच्छी चीज़ें की हैं और उसका जो नाम है, वह मानता हूँ, लेकिन अगर 2024 में किसी भाषा या DSL को शुरू से design किया जा सकता है, तो मुझे नहीं लगता कि “reactive UI” code को ज़रूर React जैसा दिखना चाहिए
    मेरा मतलब यह नहीं कि SwiftUI परफेक्ट है, लेकिन SwiftUI में लिखा code, React में वैसा ही code लिखने की तुलना में, कहीं ज़्यादा साफ़-सुथरा, व्यवस्थित और compartmentalized लगता है

cross-platform GUI में JSX इस्तेमाल करने का असली फायदा बस इतना लगता है कि web के मौजूदा libraries को फिर से इस्तेमाल किया जा सके, लेकिन RSX में डेवलपर अपने JSX concept knowledge को RSX में ला सकते हैं—इसके अलावा इसकी “portable value” कम दिखती है। इसके बजाय React/JSX paradigm से objectively बेहतर लगने वाला कोई नया paradigm सीखना शायद बेहतर समझौता है
संक्षेप में, “SwiftUI लेकिन cross-platform” जैसा कोई project अच्छा होता, लेकिन अभी ऐसा कुछ नहीं है। @Tokamak/TokamakUI के बारे में पता है, लेकिन वह अभी काफी अधूरा लगता है और उसकी activity भी कम हुई दिखती है

  • https://ribir.org/ है
    अभी यह सिर्फ Linux/mac/windows के native desktop apps को support करता है, लेकिन WASM, web, और mobile support की योजना है
  • Freenet का decentralized homepage बनाने के लिए मैंने Dioxus चुना
    यह वह पहला decentralized website होगा जो Freenet सेटअप करने वाले लोग देखेंगे। यह कुछ हद तक Kweb जैसा भी है, जो एक Kotlin web framework है जिस पर मैं कुछ सालों से बीच-बीच में काम करता रहा हूँ, खासकर state handling और code से HTML में map होने वाले DSL तरीके में समानता है। अभी तक यह पसंद आ रहा है
    https://freenet.org/
    https://kweb.io/
    • बढ़िया। लगता है जब मैंने पहली बार DSL डिज़ाइन किया था तो kweb देखा था, और दोनों सच में काफी मिलते-जुलते हैं
      मैं वैसे भी Kotlin का fan हूँ, और Kotlin DSL व concurrency model पसंद करता हूँ
  • Tauri से तुलना करें तो यह कैसा है, यह जानना चाहता हूँ
    • README में इसके बारे में लिखा है: https://github.com/dioxusLabs/dioxus/?tab=readme-ov-file#dioxus-vs-tauri
      Tauri frontend को webview में रखता है, और native Rust functions से Electron की तरह IPC boundary के ज़रिए communicate करना पड़ता है
      Dioxus में Rust code native side पर होता है, इसलिए file system read, websocket जैसे कामों के लिए IPC की ज़रूरत नहीं पड़ती। Tauri frontend को WASM में compile करने के लिए मजबूर करता है, और कई दिलचस्प Rust crates हैं जो wasm में compile नहीं होते
      जब IPC boundary नहीं होती तो development कितना सरल हो जाता है, यह शब्दों में बताना मुश्किल है। Dioxus tools सिर्फ Rust को target करते हैं, इसलिए 0 से bundled .app तक 1 मिनट से कम में पहुँचा जा सकता है। नया build लगभग 12 सेकंड, नया bundle लगभग 20 सेकंड लेता है
      फिर भी मुझे Tauri की flexibility बहुत पसंद है—यानी अगर UI web-compatible है, तो frontend में कुछ भी इस्तेमाल किया जा सकता है—और Dioxus को Tauri app के अंदर भी इस्तेमाल किया जा सकता है
    • मैं भी यही सवाल पूछने आया था
      अच्छा लगा कि Dioxus ने इसे README में सीधे address किया, लेकिन उन लोगों के वास्तविक अनुभव भी जानना चाहूँगा जिन्होंने दोनों इस्तेमाल किए हों
      मैंने Tauri से एक toy desktop app बनाई थी, और यह तो देख लिया कि web frontend हर key input पर update और काम करते हुए भी बिना lag के चल सके, IPC उसके लिए काफ़ी तेज़ है—और जवाब “हाँ” था। लेकिन क्या frontend से हर key input पर बड़ी file Rust layer को भेजकर फिर वापस frontend में लाई जा सकती है—कम से कम मेरी naive implementation में जवाब “नहीं” था
      Tauri और Dioxus, दोनों के लिए अच्छे use cases बहुत हैं, और कुछ मामलों में Dioxus बेहतर लग सकता है। मैं ऐसे comparison अनुभव सुनना चाहूँगा जैसे “हमने अपने project में X और Y की वजह से Dioxus या Tauri चुना।” Dioxus सच में बहुत बढ़िया लग रहा है, इसलिए इसे आज़माने का उत्साह है
  • native apps में rendering कैसे होती है, यह जानना चाहता हूँ। क्या यह अभी भी किसी तरह के browser instance के अंदर चलता है?
    • आप renderer के रूप में system webview इस्तेमाल कर सकते हैं, या stylo से लाया गया experimental WGPU-based engine चुन सकते हैं
      stylo, Servo का वह हिस्सा है जो Firefox के साथ साझा होता है। लंबे समय में वे लोगों को WGPU renderer की ओर ले जाना चाहते हैं, लेकिन यह अभी काफी शुरुआती अवस्था में है, और Dioxus इस्तेमाल करने वाली कई कंपनियाँ व्यावहारिक रूप से जानती हैं कि webview app के लगभग 90% मामलों के लिए पर्याप्त अच्छा समाधान है
  • “0.5 release cycle के दौरान कई dependencies में बचे बहुत छोटे unsafe को हटाने की योजना” वाले हिस्से में, मैं देखना चाहूँगा कि वे use cases क्या हैं और motivation क्या है
    मैं समझता हूँ कि लोग कभी-कभी unsafe बहुत आसानी से इस्तेमाल कर लेते हैं, लेकिन standard library भी unsafe से भरी हुई है, इसलिए रेखा को वहीं खींचना कभी-कभी रेत पर रेखा खींचने जैसा लगता है
    • ज़्यादातर FFI के साथ interact करने या कुछ types को Send/Sync घोषित करने के लिए इसकी ज़रूरत पड़ती है
      यह तीन जगह इस्तेमाल हो रहा है। iOS में कुछ FFI fixes, signal में function-call syntax संभव बनाने वाला implementation, और pointer को hash की तरह इस्तेमाल करने वाली ID के लिए Send/Sync implement करने वाला हिस्सा
      आख़िरी वाले को अभी देखता हूँ तो लगता है कि शायद usize से बदलकर हटाया जा सकता है
    • मैं सहमत हूँ कि लोग unsafe से थोड़ा ज़्यादा डर सकते हैं
      फिर भी, अगर crate author अपने crate से unsafe हटाने का लक्ष्य रखता है, तो यह ज़रूरी नहीं कि वह गलत फ़ैसला हो
      जो crate author सारे unsafe हटाना चाहते हैं, वे अक्सर यूज़र पर पड़ने वाले trust burden को कम करना चाहते हैं। मेरी नज़र में यही unsafe keyword की ताकत है। सच कहें तो शायद इसे trust_me blocks और check_yourself functions में बाँटा जाना चाहिए था
      unsafe memory safety की बातचीत को code में बहुत सीमित और auditable जगहों तक समेट देता है, और साथ ही trust पर एक नई, संभाली जा सकने वाली बातचीत भी बनाता है
  • React ने hook API में use* naming convention क्यों बनाई, यह समझता हूँ, लेकिन Dioxus में नया signal बनाने वाला function use_signal क्यों है, यह जानना चाहता हूँ
    let mut count = use_signal(|| 0); क्या यह नया signal बनाने वाली call नहीं है? signal हर render पर दोबारा नहीं बनता, और यही तो signal की मूल बात है
    SolidJS में const [count, setCount] = createSignal(0) की तरह createSignal से signal बनाया जाता है, और यह कहीं ज़्यादा समझने में आसान लगता है
    API naming महत्वपूर्ण है। state hooks अलग तरह से behave करते हैं और useMemo जैसी अतिरिक्त ज़रूरतें भी पैदा हो सकती हैं। Dioxus ने सिर्फ React जैसा दिखने के अलावा use_signal नाम क्यों चुना, इसके पीछे कोई वजह है क्या?
    • Dioxus अब भी components को re-render करता है, लेकिन component जो rsx बनाता है उस पर कई optimizations लागू करता है, इसलिए performance Solid के करीब आती है
      Solid से ज़्यादा यह Preact के करीब है
      इन optimizations में UI के dynamic हिस्सों को अलग “diff bin” में बाँटना, default memoization, और signals का properties को implicit dirty/managed के रूप में mark करना शामिल है