मैंने अपने Mac Electron ऐप को Rust में फिर से लिखा

• डेवलपर ने Mac के लिए बने मौजूदा Electron ऐप Desktop Docs को Rust में फिर से लिखा, और निष्कर्ष यह रहा कि यह सही फैसला था
• Electron से बना शुरुआती ऐप आकार में 1GB था और परफॉर्मेंस समस्याओं के कारण बार-बार क्रैश होता था
  • खासकर बड़ी इमेज/वीडियो प्रोसेसिंग में परफॉर्मेंस गिरने की समस्या थी
• Rust + Tauri से दोबारा बनाने के बाद ऐप का आकार 83% कम हुआ, इंडेक्सिंग स्पीड 3 गुना से अधिक बेहतर हुई, और स्थिरता भी बढ़ी
  • ऐप आकार: 1GB → 172MB (83% कमी)
  • इंस्टॉलेशन फ़ाइल: 232MB → 69.5MB (70% कमी)
  • वीडियो इंडेक्सिंग: 38 मिनट के वीडियो के लिए 10~14 मिनट → 3 मिनट
  • अस्थिर Electron ऐप की तुलना में कहीं अधिक स्थिर रनटाइम
• रीबिल्ड की प्रक्रिया और चुनाव
  • Electron ऐप में बैकग्राउंड में भी Chromium अकेले 200MB से अधिक मेमोरी इस्तेमाल करता था, यहाँ तक कि वीडियो कॉल भी क्रैश का कारण बनती थी
  • नए ऐप में भी CLIP embeddings और Redis vector store को वैसे ही रखा गया
  • लेकिन Rust में इमेज/वीडियो प्रोसेसिंग और फ़ाइल I/O की पूरी पाइपलाइन फिर से लिखी गई
  • UI को भी पुराने कोड को पोर्ट करने के बजाय शुरू से फिर से लिखा गया, और नतीजतन एक अधिक साफ़ और सरल इंटरफ़ेस तैयार हुआ
• तकनीकी कठिनाइयाँ
  • Rust की learning curve ऊँची है, और Tauri community अभी Electron जितनी mature नहीं है
  • Redis को ऐप में bundle करने की प्रक्रिया में permissions handling और deployment से जुड़ी समस्याएँ थीं
  • इसके बावजूद Electron की तुलना में कुल मिलाकर control और performance बेहतर हुए
• निष्कर्ष
  • पूरी feature parity अभी नहीं आई है, लेकिन core features कहीं अधिक तेज़ और स्थिर तरीके से काम करते हैं
  • “जो कोड चलता तो है, लेकिन गलत तरीके से बनाया गया है, उसे साहस के साथ छोड़ देना चाहिए”

[choyunsung79]

Electron में Chromium built-in होता है, जबकि Tauri OS में इंस्टॉल किए गए इंजन का इस्तेमाल करता है, इसलिए दोनों में अंतर है.

Tauri (OS WebView) हल्के deployment और तेज़ performance की ज़रूरत होने पर फ़ायदेमंद है, लेकिन
जहाँ security, reliability और feature control महत्वपूर्ण हों, वहाँ Electron (Chromium built-in) तरीका ज़्यादा उपयुक्त है.

कोड की समस्या के बारे में मैं ठीक से नहीं जानता, लेकिन मुझे लगता है कि platform की विशेषताएँ काफ़ी असर डालती हैं.

[bus710]

अगर Flutter है, तो rinf भी काफ़ी अच्छा है।

[aer0700]

मैंने Electron इस्तेमाल किया है, लेकिन Tauri को कभी नहीं आज़माया। लगता है, इसे एक बार ज़रूर इस्तेमाल करके देखना चाहिए।

[GN⁺]

Hacker News राय

• मैं Rust और egui का इस्तेमाल करके एक डेस्कटॉप ऐप बना रहा/रही हूँ, और चूँकि Rust भी नया है और डेस्कटॉप डेवलपमेंट भी, इसलिए एक साथ इतने सारे कॉन्सेप्ट सीखना मुश्किल लग रहा है। मेरा डोमेन mechanical engineering analysis tools का है, इसलिए backend में high performance चाहिए और frontend में data visualization की ज़रूरत होती है। Tauri इस्तेमाल करते समय rust, js, html जैसे कई stacks को साथ में मैनेज करना कितना मुश्किल था, यह जानना चाहता/चाहती हूँ

• हाल ही में मैंने Tauri से Electron पर प्रोजेक्ट शिफ्ट किया था। अलग-अलग platforms पर इस्तेमाल होने वाले webview के rendering differences बहुत सिरदर्द बने। क्या आपने cross-platform UI bugs झेले हैं, यह जानना चाहता/चाहती हूँ। UI requirements सरल हैं और calculations जटिल, इसलिए मुझे लगता है कि QA cost हो तो भी वह वाजिब है। समझ नहीं आ रहा कि मेरा अनुभव असामान्य था या rendering differences सच में आम समस्या हैं। और यह भी जानना चाहता/चाहती हूँ कि आपने Tauri 1.0 इस्तेमाल किया था या 2.0। 2.0 मेरे v1 से migrate करते समय stable हुआ था, migration एक दुःस्वप्न था और documentation भी बहुत कमज़ोर थी। अब documentation बेहतर हुई है या नहीं, यह भी जानना चाहता/चाहती हूँ

  • हम kreya.app में system webview को खुद implement करके इस्तेमाल करते हैं (यानी Tauri नहीं), और platform differences वास्तव में लगभग समस्या नहीं बनते। ज़्यादातर चीज़ें polyfills से सुलझ जाती हैं, और Linux पर end-to-end automated tests चलाकर हम अधिकांश समस्याएँ पकड़ लेते हैं। सबसे मुश्किल बात यह जानना है कि user का webview version कितना पुराना है। Linux और Mac पर यह बड़ा मुद्दा है, जबकि Windows में WebView2 की वजह से स्थिति काफ़ी बेहतर है
  • सच कहूँ तो अभी तक Tauri version के साथ cross-platform deployment नहीं किया है, इसलिए आगे पता चलेगा। अच्छी बात यह है कि UI requirements सरल हैं। Tauri में आपको किस तरह के rendering differences मिले, यह जानना चाहूँगा/चाहूँगी। ऐप में किस platform पर सबसे अच्छा चला या सबसे ज़्यादा समस्या आई, यह भी जानना चाहता/चाहती हूँ। हम भी Windows support चाहते हैं। Electron version में Mac Intel chip पर bundled binary चलाने में दिक्कत थी, और वह इतनी परेशान करने वाली थी कि Tauri rebuild करते समय हमने पहले सिर्फ़ एक platform, Mac (Apple chip), पर ध्यान देने का फैसला किया। हमने Tauri 1.4 इस्तेमाल किया और अभी तक कोई समस्या नहीं है। 2.0 migration docs भी बाद में देखूँगा/देखूँगी
  • cross-platform UI bugs के सवाल पर, नहीं, क्योंकि अभी हम सिर्फ़ Mac support करते हैं। अगर Windows और Linux तक support करना पड़ता, तो शायद यह लेख भी नहीं लिख पाता/पाती। Cross-platform UI सच में बहुत कठिन है, और अगर वही UI व feature set बनाए रखते हुए web version भी ध्यान में रखनी हो, तो और भी मुश्किल हो जाती है। यही वजह है कि बहुत लोग native से Qt या web stack की ओर गए। मेरे अनुभव में, मैं एक ऐसी कंपनी में काम करता/करती हूँ जो लाखों users वाला cross-platform desktop app बनाती है, और किसी दूसरे तरीके की कल्पना भी मुश्किल लगती है
  • जब मैंने लगभग 6 महीने पहले Tauri V2 इस्तेमाल किया था, तब documentation पूरी तरह अस्त-व्यस्त थी। प्रोजेक्ट में संभावना बहुत है, लेकिन refer करने लायक सामग्री न होने से इसे ठीक से implement करना बहुत कठिन था
  • हाल ही में Tauri ने यह घोषणा की: इस साल CEF और SERVO आधारित webview जैसी नई तकनीकें दिखाने की योजना है, ऐसा Discord पर बताया गया

• मैंने भी कुछ हद तक ऐसा ही रास्ता अपनाया है। USB microscope के लिए optimized एक simple webcam viewer बनाया, क्योंकि पहले से कोई ठीक विकल्प नहीं था, इसलिए खुद बनाना पड़ा। लगभग सारी functionality renderer में implement की। App Store submission की तैयारी करते समय लगा कि 500mb का webcam viewer कुछ ज़्यादा ही है, इसलिए उसे Tauri V2 पर port किया और size को घटाकर लगभग 15mb कर दिया

  • Tauri और Electron के फर्क के बारे में जानना चाहता/चाहती हूँ। मेरी समझ के अनुसार, दोनों rendering के लिए browser का इस्तेमाल करते हैं, लेकिन Electron अपना पूरा browser साथ bundle करता है जबकि Tauri सिस्टम में पहले से मौजूद browser का उपयोग करता है
  • यह सच में प्रभावशाली है। जानना चाहूँगा/चाहूँगी कि वह कौन-सा product है। हम भी इस हफ़्ते App Store submission की तैयारी कर रहे हैं

• मुझे इस ऐप का मकसद बहुत पसंद आया। इस क्षेत्र के दूसरे ऐप अक्सर बहुत सुस्त और असुविधाजनक होते हैं, इसलिए इस rewrite में काफ़ी दिलचस्पी है। लेकिन मैं photographer हूँ, इसलिए मेरे media का बड़ा हिस्सा RAW format में है, और मुझे यक़ीन नहीं कि यह supported है या नहीं (या शायद नहीं, क्योंकि “सभी प्रमुख image·video formats” में RAW का ज़िक्र नहीं है)। क्या इन details की पुष्टि करने के लिए कोई official docs, user forum, या कोई और channel है?

• मैं Mac user नहीं हूँ और हमारी टीम भी Rust rewrite पर विचार नहीं कर रही, लेकिन यह लेख बहुत अच्छा लगा। “Show HN” में मैं ठीक इसी तरह की post देखना चाहता/चाहती हूँ, जो वास्तविक समस्याओं को हल करने के लिए ज़रूरी technical trade-offs को इतनी संक्षिप्तता में समेट दे। धन्यवाद

  • अनुभव साझा कर पाने की खुशी है। जो चीज़ पहले से काम कर रही हो, उसे rebuild करने का फ़ैसला आसान नहीं था, लेकिन अंत में मैं इससे संतुष्ट हूँ

• अच्छा होगा अगर Tauri, Flutter, Electron, React Native और अन्य modern cross-platform frameworks की तुलना करने वाला कोई up-to-date benchmark resource हो। मुख्य metrics bundle size, memory usage (RAM), startup time, load के दौरान CPU usage, disk footprint वगैरह हो सकते हैं। ख़ास तौर पर Tauri जैसे frameworks के लिए, जहाँ webview version के अनुसार rendering और performance बदल सकती है, platform-specific compatibility matrix (WebView2, WKWebView आदि) भी साथ होनी चाहिए। अगर इन अंतरों को किसी visual table में दिखाया जाए, तो developers कहीं बेहतर फैसला कर पाएँगे

  • 2 हफ़्ते पहले पोस्ट की गई एक ताज़ा comparison resource है। इसे web-to-desktop-framework-comparison पर देखा जा सकता है। Runtime performance के मामले में Electron काफ़ी competitive है। मेरा मानना है कि disk space से ज़्यादा memory usage की चिंता करनी चाहिए।
    • Windows (x64) memory usage (single window, release build):
    1. Electron: लगभग 93MB
    2. NodeGui: लगभग 116MB
    3. NW.JS: लगभग 131MB
    4. Tauri: लगभग 154MB
    5. Wails: लगभग 163MB
    6. Neutralino: लगभग 282MB
    • Mac (arm64):
    1. NodeGui: लगभग 84MB
    2. Wails: लगभग 85MB
    3. Tauri: लगभग 86MB
    4. Neutralino: लगभग 109MB
    5. Electron: लगभग 121MB
    6. NW.JS: लगभग 189MB
    • Linux (x64):
    1. Tauri: लगभग 16MB
    2. Electron: लगभग 70MB
    3. Wails: लगभग 86MB
    4. NodeGui: लगभग 109MB
    5. NW.JS: लगभग 166MB
    6. Neutralino: लगभग 402MB
  • ऐसी comparison resources और देखना चाहूँगा/चाहूँगी

• पिछली कंपनी में मैं Windows और Mac के लिए एक desktop Electron app maintain करता/करती था/थी। ऐप बहुत भारी था, और Squirrel से updates देना काफ़ी पीड़ादायक था।
  आख़िरकार GUI को web SPA (Inferno आधारित) ही रखा, लेकिन webview loading वगैरह के लिए हर platform पर छोटे native apps (C# और Swift) से बदल दिया। इससे download size और memory usage लगभग 90% कम हो गए, और distribution-update को हर platform के app store के ज़रिए संभालने लगे। मेरे हिसाब से यह बेहतरीन फ़ैसला था

  • native app store के ज़रिए distribution/update की तारीफ़ करते किसी को शायद पहली बार देख रहा/रही हूँ।
    approval time और उसकी uncertainty चिंता की बात लगती है, तो Squirrel से native पर जाने के बाद क्या सुधार हुआ, यह जानना चाहता/चाहती हूँ
  • इस बदलाव में कितना समय लगा, यह भी जानना चाहता/चाहती हूँ

• अगर अंतिम ऐप Mac के लिए ही है, तो यह सच में जानने की उत्सुकता है कि आपने Swift/SwiftUI की बजाय Rust/Tauri क्यों चुना

  • यह point उठाने के लिए धन्यवाद। Desktop Docs का लक्ष्य cross-platform है। Windows support की माँग काफ़ी है, इसलिए भविष्य के Windows version को ध्यान में रखकर Rust चुना गया
  • मैं भी यही सवाल पूछना चाहता/चाहती था/थी। Swift काफ़ी अच्छी भाषा है और मुझे लगता है कि उसमें Rust जैसी कई खूबियाँ हैं। CLIP integration की बात भी दिलचस्प है, और porting की कहानी भी बहुत अच्छी लगी
  • मैं भी यही जानना चाहता/चाहती हूँ। मैं जल्द ही एक desktop app बनाने वाला/वाली हूँ, Swift इस्तेमाल किए काफ़ी समय हो गया है और Rust भी बहुत कम जानता/जानती हूँ। Tauri बहुत आकर्षक लग रहा है। Electron apps तेज़ PC पर भी बहुत धीरे start होते हैं। insights साझा करने के लिए धन्यवाद

• यह जानना चाहूँगा/चाहूँगी कि आपने egui की बजाय Tauri क्यों चुना। क्या इसकी वजह Electron का अनुभव था? मैं भी एक Python Qt app को Rust में port करना चाहता/चाहती हूँ, लेकिन चिंता है कि Rust की GUI libraries अभी Qt जितनी परिपक्व नहीं हैं, और कहीं बीच में जाकर अटक न जाऊँ

  • मूल रूप से porting पर विचार करने की वजह क्या थी, यह भी जानना चाहता/चाहती हूँ

• main landing page पर "Try" button देखकर users को लगता है कि शायद trial मिलेगा, लेकिन वास्तव में वह सीधे purchase पर ले जाता है। छोटा-सा 1 हफ़्ते का trial भी अच्छा रहेगा।
  perpetual fallback license policy का मैं प्रशंसक हूँ। $99 entry barrier काफ़ी ऊँचा है, लेकिन अगर target creators/studios हैं तो ठीक है; general consumers के लिए $20-$25 शायद बेहतर लगेगा।
  लेख में performance पर ज़ोर है, लेकिन landing page पर उसका कोई ज़िक्र नहीं। 38 मिनट के वीडियो की तरह, benchmarks, parallel work, VRAM requirements जैसी जानकारी भी महत्वपूर्ण है। सैकड़ों-हज़ारों घंटों के media को process करते समय यह वास्तव में कैसा काम करता है, यह जानना चाहूँगा/चाहूँगी।
  यह काफ़ी चौंकाने वाला है कि Electron में 10~14 मिनट लगने वाला काम Tauri में 3 मिनट में हो गया। अगर Electron सिर्फ़ CLIP और ffmpeg को orchestrate ही कर रहा था, तो इतना overhead कहाँ से आया, यह समझना दिलचस्प है।
  मैंने भी पहले Electron में video transcription आधारित media search tool बनाया था, और performance issues बहुत नहीं थे।
  आमतौर पर Electron या Tauri cross-platform होने की वजह से चुने जाते हैं, तो फिर शुरुआत से ही सिर्फ़ Mac-only क्यों, यह जानना चाहता/चाहती हूँ (ख़ासकर जब बड़े media processing में nvidia का फ़ायदा लिया जा सकता है)।
  मैंने भी हाल में 10 साल बाद Swift फिर से इस्तेमाल किया और Tauri के साथ तुलना करने के बाद Swift चुना (नए प्रोजेक्ट में), और 2014 के आसपास की तुलना में यह इतना बेहतर हो चुका है कि अनुभव लगभग सुखद रहा।
  अगर active users वाला सेक्शन सच है, तो लगता है कि आपने पहले ही काफ़ी सफलता पा ली है। क्या पहले से studio/creator industry में आपका कोई network या audience था? Marketing के बारे में भी सुनना चाहूँगा/चाहूँगी

  • feedback के लिए धन्यवाद। infrastructure के कारण अभी trial implement नहीं कर पाए हैं, लेकिन भविष्य में इस पर विचार करेंगे।
    आपने कहा कि आपने भी ऐसा tool बनाया था, तो उसे launch न करने की वजह जानना चाहूँगा/चाहूँगी।
    Windows और Linux versions भी माँग होने पर अगले कुछ महीनों में लाने की योजना है।
    Users HN, reddit launch, और कुछ LinkedIn promotion से आए। ज़्यादातर growth word of mouth से हुई।
    Electron और video processing performance पर और गहराई से जाऊँ तो बहुत कुछ कह सकता/सकती हूँ। मैं खुद Electron expert नहीं हूँ; हो सकता है हमने workers का सही उपयोग नहीं किया, इसलिए bottleneck बना।
    Rust पर जाने के बाद हमने scene detection भी जोड़ा, जिससे index करने वाले frames की संख्या कम हुई और processing load काफ़ी घटा। ffmpeg के GPU acceleration options भी जोड़े गए, जिससे performance में अच्छा सुधार आया। Image embedding generation को भी batch processing से optimize किया गया। हालाँकि बहुत ज़्यादा push करने पर model instance crash भी हो सकता है

[secret3056]

HN पर लिंक किए गए performance comparison chart में, ज़्यादातर मामलों में Electron, Tauri से बेहतर दिख रहा है....

[majorika]

कमेंट में दिया गया परफॉर्मेंस तुलना वाला हिस्सा काफी हद तक ऐसा लगता है कि उसने उस रिपॉज़िटरी में मौजूद मानों में से Electron के पक्ष में जाने वाले मान चुनकर पेश किए हैं। मान थोड़े अलग ज़रूर हैं, लेकिन सबसे मिलती-जुलती संख्या शायद वह हिस्सा है जहाँ 'चलाने से पहले उपलब्ध मेमोरी और चलाने के बाद उपलब्ध मेमोरी के बीच का अंतर' की तुलना की गई है। लेकिन ठीक उसके ऊपर वाले बिंदु में, रनिंग के दौरान main process और child process की कुल मेमोरी Electron के लिए 258M दर्ज है, इसलिए यह मान लेना मुश्किल लगता है कि रन से पहले और बाद के बीच मेमोरी उपयोग में बदलाव केवल 91MB था। HN की reply comments में भी यह बात आई है कि Tauri से बनाए गए ऐप का स्टार्टअप टाइम 7 सेकंड से ज़्यादा बताया गया था, जिससे यह कहना पड़ता है कि उस रिपॉज़िटरी के measurement numbers पर भरोसा करना कठिन है।

[wfedev]

हम्म, लगता है कि ज़्यादातर समस्याएँ Electron या Tauri के फ़र्क से नहीं, बल्कि WebView engine + OS/driver issues से ज़्यादा पैदा होती हैं।