Electron के बारे में लोग क्या गलत समझते हैं
(felixrieseberg.com)- लेखक Felix Rieseberg, Electron के development में 10 साल से ज़्यादा समय से जुड़े co-maintainer हैं
- Electron वेब technologies से UI बनाने देता है, और ज़रूरत पड़ने पर native code को भी खुलकर साथ मिलाने की सुविधा देता है
- कई apps (Visual Studio Code, Slack, Discord, Figma, ChatGPT, Claude, Notion, 1Password, Docker Desktop आदि) ने Electron को अपनाया है
- यह लेख Electron से जुड़ी मुख्य गलतफहमियों को देखता है और बताता है कि ये विकल्प क्यों चुने गए
Electron JavaScript और native code को आमने-सामने खड़ा करता है
- अक्सर यह कहा जाता है कि "Electron सिर्फ JavaScript इस्तेमाल करता है, इसलिए यह native से पीछे रह जाता है"
- वास्तव में Electron, JavaScript के साथ C++, Objective-C, Rust जैसे native code भी साथ में इस्तेमाल करने देता है
- उदाहरण के लिए 1Password ने अपने ज़्यादातर code को Rust में लिखा है, जबकि UI के लिए Electron का उपयोग किया है
- Electron की ताकत इसकी flexibility है: जितना ज़रूरी हो उतना native code मिलाइए, और UI layer में web technologies का उपयोग कीजिए
- SwiftUI, GTK, Win32 आदि का उपयोग करके आंशिक native UI देने वाले demo उदाहरण भी मौजूद हैं
Web apps खराब होते हैं
- कुछ लोगों का मानना है कि "हर native app हमेशा बेहतर होता है", लेकिन बाज़ार की स्थिति इतनी सीधी नहीं है
- NASA का Mission Control, Bloomberg Terminal, McDonald’s kiosk, और SpaceX का Dragon 2 भी Chromium-आधारित web technologies का उपयोग करते हैं
- web technologies दुनिया भर में सबसे व्यापक रूप से इस्तेमाल होती हैं, और अच्छी तरह बनाए गए web apps शानदार user experience दे सकते हैं
- "Web apps वे लोग बनाते हैं जिनकी skill कम होती है" जैसी बात, उपयोग के वातावरण की ज़रूरतों और developers के चयन की परिस्थितियों को नज़रअंदाज़ करने वाला सरलीकरण है
Operating system का WebView ज़्यादा performant होता है
- कुछ लोग कहते हैं कि macOS, Windows, Linux में built-in WebView अक्सर बेहतर होता है
- वास्तव में Slack ने शुरुआत में MacGap (WebView-आधारित) का उपयोग किया था, लेकिन performance समस्याओं के कारण आखिरकार Electron (Chromium) अपनाया
- आधुनिक Chromium engine ज़्यादा resources लेता है, लेकिन optimization भी उसी पर सबसे सक्रिय रूप से होती है
- OS में built-in WebView shared resources की वजह से कम memory usage दिखा सकता है, लेकिन security और stability कारणों से व्यवहार में वह अक्सर अलग-थलग होता है
- Electron के ज़रिए नवीनतम engine version को सीधे manage किया जा सकता है, जिससे stability और security को स्वतंत्र रूप से बनाए रखा जा सकता है
Bundle size महत्वपूर्ण है
- आम तौर पर Electron apps का आकार 100~300MB होता है, और इसी बात पर आलोचना की जाती है
- लेकिन users अक्सर app size से ज़्यादा features, convenience, stability जैसी चीज़ों को प्राथमिकता देते हैं
- उदाहरण के लिए 4K quality में Netflix streaming एक घंटे में कई GB data इस्तेमाल कर सकती है, और Call of Duty updates सैकड़ों GB तक पहुँच सकते हैं
- अंततः, वास्तविक user satisfaction की तुलना में app size कई मामलों में अपेक्षाकृत कम महत्वपूर्ण कारक बन जाता है
Electron को हराइए
- Electron की शुरुआत "चलो एक अच्छा desktop app बनाते हैं" जैसे लक्ष्य वाले लोगों के open source प्रयास से हुई थी
- Electron ने ऐसे समय में शुरुआत की जब इसके प्रतिस्पर्धी कम थे, और आज भी यह पर्याप्त features और stability देता आया है
- अगर Electron को ‘हराना’ है, तो ऐसा platform बनाना होगा जो Electron का काम उससे बेहतर कर सके
- Electron maintainers कहते हैं कि अगर कोई बेहतर विकल्प आता है, तो वे उसका खुशी से स्वागत करेंगे
15 टिप्पणियां
इसे Call of Duty से तुलना करना कुछ विषय से हटकर लगता है।
Electron को छोड़कर WebView पर शिफ्ट हुए Teams को देखने की ज़रूरत है,
https://techcommunity.microsoft.com/discussions/microsoftteams/…
उम्मीद है कि Tauri जल्दी mature हो जाए। हालांकि मैं इसे पहले से ही अच्छी तरह इस्तेमाल कर रहा हूँ।
जब यह Atom Shell था, तब की बात कल जैसी लगती है.. काफी विकास हुआ है।
कई आलोचना के बिंदु हैं, लेकिन जिस स्तर की परिपक्वता VSCode ऐप में दिखती है, जिसे हम रोज़ इस्तेमाल करते हैं, उसे देखते हुए यह निश्चित रूप से लगता है कि Electron का योगदान कम नहीं है।
मेरे PC पर इंस्टॉल किए गए Electron ऐप्स ही लगभग 10 हैं, तो इस स्तर पर लगता है कि इसे अलग से इंस्टॉल होने वाला framework होना चाहिए, है ना?
Bundle size भी ऐसा है, और
~~ Helperprocess को memory खाते हुए देखो तो बस आह ही निकलती है.मैं tauri को एक विकल्प के तौर पर सोच रहा हूँ, लेकिन डिप्लॉयमेंट के समय कहीं ऐसा कोई असामान्य केस न आ जाए जिसमें यह सामान्य रूप से काम न करे, यही चिंता है। (पहले win32 environment में msxml.dll जैसी डिफ़ॉल्ट रूप से registered DLLs को refer करने वाले प्रोग्राम को डिप्लॉय किया था और तब बहुत परेशान होना पड़ा था, इसलिए उसे internalize करके डिप्लॉय किया था... कहीं वैसी ही समस्या फिर न आ जाए।)
electron वाली राय के मुताबिक, शायद size को बस नज़रअंदाज़ कर देना ही सही है, लेकिन bundle size बहुत बड़ा है।
लगता है Tauri में वही समस्या है..
हर platform के webview और embedded program अलग-अलग होते हैं, इसलिए यही सबसे बड़ी समस्या है। deploy करने के बाद क्या होगा, इसका पता नहीं चलता।
लेकिन अगर Tauri में webview खुद ही embed करें, तो bundle size Electron से भी बड़ा हो जाता है..
इसलिए production cross-platform app development के लिए मुझे लगता है कि Tauri अभी तक mature नहीं है।
McDonald’s का kiosk है...उम्....पता नहीं यह अच्छा उदाहरण है या नहीं
मेरे मन में भी अचानक यही ख़याल आया। क्या विदेशों में McDonald's के kiosk फिर भी थोड़े अलग होते हैं? एक पल के लिए यही सवाल उठा, हाहा
हाहाहा, मैंने भी बिल्कुल यही सोचा था
ऐसा लगता है कि memory usage कम करना सबसे बड़ी चुनौती होगी, लेकिन अफसोस की बात है कि किसी भी stakeholder के पास इसे वास्तव में लागू करने की कोई खास प्रेरणा नहीं दिखती।
मैंने मुख्य लेख में दिए गए असल demo code लिंक को देखकर जाँचा, लेकिन यह इतना आसान नहीं लगा कि बस बहुत साधारण तरीके से साथ में इस्तेमाल किया जा सके। फिलहाल इसे कम-से-कम संभव है, इसी बात के लिहाज़ से देखना होगा...
लगता है कि आम तौर पर ऐप का बड़ा होना सच ही है..
हाँ, bundle size वाली बात तो वे सीधे-सीधे मान ही लेते हैं।