सबने हमसे कहा Electron इस्तेमाल करो। एक बार बनाओ, हर जगह चलाओ। तेज़ी से आगे बढ़ो। हमने उलटा किया — Apple पर SwiftUI, Android पर Jetpack Compose, Windows पर C++/WinRT, और जहाँ घड़ी की सुई पर पिक्सेल चाहिए थे वहाँ सीधे Metal और Vulkan। एक प्रोडक्ट के लिए चार नेटिव क्लाइंट बनाते हुए हमने जो सीखा, वह यह है।
आसान रास्ता बनाम सही रास्ता
जब आप लोगों को बताते हैं कि आप 2024 में शुरू से एक रिमोट डेस्कटॉप ऐप बना रहे हैं, तो पहला सवाल हमेशा यही होता है: "Electron ही क्यों न इस्तेमाल करें?"
यह जायज़ सवाल है। Electron धरती के कुछ सबसे सफल ऐप्स को चलाता है — VS Code, Slack, Discord, Figma का डेस्कटॉप रैपर। यह आपको एक बार लिखकर हर जगह तैनात करने देता है। आपके वेब डेवलपर रातों-रात डेस्कटॉप डेवलपर बन जाते हैं। बाज़ार तक पहुँचने के समय का फ़ायदा असली है।
हमने आँकड़े देखे, समझौते तौले, और सबसे कठिन संभव रास्ता चुना: हर प्लेटफ़ॉर्म पर पूरी तरह नेटिव। iOS और macOS पर SwiftUI। Android पर Jetpack Compose। Windows पर C++/WinRT। Apple पर रेंडरिंग के लिए Metal। बाक़ी सब पर Vulkan। और केंद्र में एक कस्टम Go सर्वर।
इसलिए नहीं कि हमें तकलीफ़ में मज़ा आता है, हालाँकि कुछ दिन ऐसा ही लगता है। बल्कि इसलिए कि इस तरह के ऐप के लिए नेटिव कोई विलासिता नहीं है। यह ज़रूरत है।
Electron का टैक्स असली है
पहले यह समझ लें कि Electron असल में है क्या: एक Chromium ब्राउज़र विंडो जो डेस्कटॉप ऐप होने का दिखावा करती है। यह कोई आलोचना नहीं — यह आर्किटेक्चर है। और बहुत-से ऐप्लिकेशन के लिए यह बिल्कुल ठीक है।
लेकिन रिमोट डेस्कटॉप के लिए? आप किसी दूसरे कंप्यूटर से पिक्सेल स्ट्रीम कर रहे हैं और उन्हें रीयल टाइम में रेंडर कर रहे हैं, साथ ही हर इनपुट इवेंट कैप्चर करके वापस भेज रहे हैं। लेटेंसी कोई अतिरिक्त चीज़ नहीं है। वही पूरा प्रोडक्ट है।
जब हमने दोनों तरीक़ों के प्रोटोटाइप बनाए, तो हमने यह नापा:
- मेमोरी — नेटिव क्लाइंट की स्थिर अवस्था: ~45 MB। Electron प्रोटोटाइप: ~380 MB। निष्क्रिय अवस्था में 8.4× का अंतर, इससे पहले कि कोई भी ऐप एक भी फ़्रेम डिकोड करना शुरू करे।
- कोल्ड स्टार्ट — नेटिव macOS ऐप 200 ms से कम में कोल्ड-स्टार्ट होता है। Electron प्रोटोटाइप को 2 से 3 सेकंड लगे। जिस टूल को आप दिन में बीस बार खोलते हैं, उसके लिए यह जुड़कर असली झंझट बन जाता है।
- बैटरी — बैटरी पर चलते Mac पर, Electron बिल्ड ने निष्क्रिय कनेक्शन के दौरान लगभग 3× वॉटेज खींची। Chromium सस्ते में नहीं सोता।
380 MB का मतलब यह नहीं कि Electron फूला हुआ है। यह Chromium अपना काम कर रहा है — V8, एक GPU प्रोसेस, यूटिलिटी प्रोसेस, पूरा ब्राउज़र इंजन। यह प्रभावशाली इंजीनियरिंग है। बस यह एक अलग समस्या के लिए डिज़ाइन की गई इंजीनियरिंग है।
फ़्रेम फ़ीचर से ज़्यादा मायने रखते हैं
रिमोट डेस्कटॉप उन गिने-चुने ऐप वर्गों में से है जहाँ हर एक फ़्रेम मायने रखता है। एक फ़्रेम गिराइए और यूज़र को महसूस होता है। 16 ms की इनपुट लेटेंसी जोड़िए और डिज़ाइनर चिकने कर्व नहीं खींच सकता। 32 ms जोड़िए और गेमर खेल नहीं सकता।
नेटिव रेंडरिंग के साथ हम सीधे GPU से बात करते हैं। Apple प्लेटफ़ॉर्म पर, VideoToolbox हमें हार्डवेयर वीडियो डिकोडिंग तक सीधी पहुँच देता है। हम नेटवर्क से एक H.265 फ़्रेम लेते हैं, उसे हार्डवेयर में डिकोड करते हैं, और दिखाते हैं — फ़्रेम कभी मुख्य मेमोरी को छुए बिना। आधुनिक Mac पर डिकोड-से-डिस्प्ले पाइपलाइन 4 ms से कम में चलती है।
Electron में वही फ़्रेम Chromium के कंपोज़िटर से गुज़रता है, IPC ब्रिज से जाता है, Skia से पेंट होता है, फिर OS द्वारा दोबारा कंपोज़ किया जाता है। हर हॉप लेटेंसी जोड़ता है। हर हॉप जिटर जोड़ता है। और जिटर — फ़्रेम की असंगत टाइमिंग — ही वह चीज़ है जो रिमोट डेस्कटॉप को गड़बड़ महसूस कराती है, भले औसत FPS ठीक दिखे।
हमने नेटिव शुद्धतावादी होने के लिए नहीं चुना। हमने इसलिए चुना क्योंकि हमारी समस्या का भौतिक नियम यही माँगता था — LAN पर करीब 8 ms की प्रोसेसिंग (बाक़ी आपके डिस्प्ले की अपनी 60 Hz रिफ़्रेश लय है) बीच में ब्राउज़र के लिए कोई जगह नहीं छोड़ती।
नेटिव बनाम वेब क्षमता का खाता
Electron बनाम नेटिव की बहस अक्सर महसूस होने वाली बातों में अटक जाती है। इसलिए हमने वे सात OS क्षमताएँ लिखीं जिन पर Remio हर सत्र के हर सेकंड निर्भर रहता है, और सीधे पूछा: हर एक हर रनटाइम के तहत कैसा करती है?
| क्षमता | नेटिव | वेब / Electron |
|---|---|---|
| 60 fps हार्डवेयर डिकोड | ● सीधे VideoToolbox / D3D11VA | ○ WebCodecs के ज़रिए, जिटर |
| कम-लेटेंसी USB ऑडियो | ● CoreAudio / WASAPI | — सैंडबॉक्स्ड, 40 ms+ |
| कीबोर्ड इनपुट मॉनिटरिंग | ● CGEvent / SendInput | — फ़ोकस से बाहर ब्लॉक |
| Metal / D3D11 GPU पहुँच | ● ज़ीरो-कॉपी टेक्सचर | ○ WebGPU, कॉपी के हॉप |
| लोकल फ़ाइल सिस्टम | ● पूरा, OS द्वारा सीमित दायरे में | ○ सिर्फ़ पिकर, प्रॉम्प्ट |
| मल्टी-विंडो, मल्टी-डिस्प्ले | ● OS-नेटिव विंडोइंग | ○ BrowserWindow के शिम |
| बैकग्राउंड में बने रहना | ● LaunchAgent / सर्विस | — छिपाने पर सस्पेंड |
हर पंक्ति एक ऐसा फ़ीचर है जो हम आज भेजते हैं। वेब कॉलम में हर — एक ऐसा जुगाड़ है जिसे हमें गढ़ना, दर्ज करना और जिसके लिए माफ़ी माँगनी पड़ती। नेटिव जाने का मतलब है कि हम उन क्षमताओं को पॉलीफ़िल नहीं, बुनियादी इकाइयाँ मानते हैं।
प्लेटफ़ॉर्म की नागरिकता
यह वह बात है जिसकी लिखो-एक-बार-चलाओ-कहीं-भी वाली भीड़ शायद ही कभी चर्चा करती है: यूज़र्स को पता चल जाता है।
उन्हें पता चल जाता है जब कोई ऐप सिस्टम डार्क-मोड ट्रांज़िशन का सम्मान नहीं करता। जब स्क्रोल फ़िज़िक्स थोड़ा गलत लगती है। जब ऐप Spotlight में नहीं दिखता या macOS विंडो मैनेजमेंट को ठीक से नहीं सँभालता। जब कॉन्टेक्स्ट मेन्यू नेटिव मेन्यू की जगह वेब पेज जैसा दिखता है।
ये कोई अतिरिक्त चीज़ें नहीं हैं। यही फ़र्क़ है उस ऐप में जिसे लोग बर्दाश्त करते हैं और उस ऐप में जिसे लोग पसंद करते हैं। iOS पर यह ख़ास तौर पर अहम है — App Store रिव्यू उन ऐप्स को अस्वीकार करेगा जो नेटिव नहीं लगते, और सही भी है।
SwiftUI के साथ, यह सब हमें मुफ़्त मिलता है। Dynamic Type, VoiceOver एक्सेसिबिलिटी, सिस्टम हैप्टिक्स, iPad पर मल्टीटास्किंग, Mac पर कीबोर्ड शॉर्टकट। हम प्लेटफ़ॉर्म के फ़ीचर दोबारा नहीं बना रहे। हम उन्हें इस्तेमाल कर रहे हैं।
क़ीमत भी असली है
आइए नुक़सान के बारे में ईमानदार हों: नेटिव जाना महँगा है। डॉलरों में नहीं — समय और जटिलता में।
हम चार UI कोडबेस सँभालते हैं। हमारी नेटवर्किंग और कोडेक परत साझा है (सिग्नलिंग के लिए Go, स्ट्रीमिंग प्रोटोकॉल के लिए C++), लेकिन स्क्रीन पर दिखने वाला हर पिक्सेल प्लेटफ़ॉर्म-विशेष कोड है। जो फ़ीचर Electron में एक दिन लेता है, उसमें हमें तीन से पाँच दिन लगते हैं, क्योंकि हम उसे चार बार बनाते हैं, हर प्लेटफ़ॉर्म के लिए ट्यून करके।
हमारे ऐसे हफ़्ते भी गुज़रे हैं जब एक ही एनिमेशन iOS पर बढ़िया चला, Android पर टूटा हुआ था और Windows पर अटकता था। डिबगिंग की मैट्रिक्स बेरहम है।
लेकिन हमने यह सीखा है: सबसे कठिन रास्ता और सही रास्ता अक्सर एक ही रास्ता होता है। हमारे यूज़र्स हमारे आर्किटेक्चर के बारे में न जानते हैं न परवाह करते हैं। वे जानते हैं कि Remio तेज़ लगता है, सही लगता है, और नाश्ते में उनकी बैटरी नहीं खा जाता।
क्या हम फिर यही करेंगे
बिना हिचकिचाए।
नेटिव तरीक़े ने हमें वह परफ़ॉर्मेंस दी जिसकी इस उपयोग-मामले के लिए Electron मूल रूप से बराबरी नहीं कर सकता। इसने हमें ऐसे ऐप दिए जो हर प्लेटफ़ॉर्म पर अपने लगते हैं। इसने हमें 380 MB की जगह 45 MB से कम का मेमोरी फ़ुटप्रिंट दिया। इसने हमें LAN पर करीब 8 ms की प्रोसेसिंग दी (बाक़ी आपके डिस्प्ले की अपनी 60 Hz रिफ़्रेश लय है), जहाँ ब्राउज़र में लिपटा प्रतिस्पर्धी 60 ms से ऊपर बैठता है।
सबसे अहम बात, इसने हमें एक तकनीकी खाई दी। चार प्लेटफ़ॉर्म पर नेटिव बनाना इतना कठिन है कि ज़्यादातर प्रतिस्पर्धी ऐसा नहीं करेंगे। वही कठिनाई हमारा फ़ायदा है।
रिमोट डेस्कटॉप श्रेणी पर Electron में लिपटे वेब ऐप और पुराने नेटिव ऐप हावी रहे हैं, जिन्हें सालों से सार्थक रूप से अपडेट नहीं किया गया। कुछ ऐसा जो आधुनिक भी हो और नेटिव भी — आज के हार्डवेयर को ध्यान में रखकर शुरू से बना — उसके लिए जगह है।
यही Remio है। कठिन तरीक़े से बना, क्योंकि कुछ चीज़ें सही करने लायक़ होती हैं।
