बहुत सारी Mac ऐप्स Electron के साथ बनाई जा रही हैं
कई Mac उपयोगकर्ता इस बात से निराश हैं कि Slack, WhatsApp और Teams जैसे लोकप्रिय desktop apps Electron पर बनाए जाते हैं, क्योंकि उनका तर्क है कि ये web-based shells native macOS software की तुलना में bloated, launch में धीमे और RAM की बर्बादी करने वाले होते हैं। दूसरे लोग जवाब देते हैं कि Electron development cost को काफ़ी कम करता है, Windows, macOS, Linux और web पर feature parity सक्षम करता है, और अक्सर desktop client ship करने का एकमात्र व्यावहारिक तरीका होता है। यह बहस व्यापक सवाल उठाती है कि क्या platforms को efficiency और native UX को प्राथमिकता देनी चाहिए, बेहतर cross-platform toolkits में निवेश करना चाहिए, या increasingly web-centric apps को व्यावहारिक default के रूप में स्वीकार करना चाहिए।
Electron का उद्देश्य और समझौते
- कई लोग तर्क देते हैं कि Electron स्वीकार्य या यहाँ तक कि अनिवार्य है: यह साझा कोड के साथ क्रॉस‑प्लैटफ़ॉर्म ऐप्स और वेब वर्ज़न सक्षम करता है, खासकर स्टार्टअप्स और VC‑funded कंपनियों के लिए।
- आम फ्रेमिंग: तीन में से दो चुनें—कम कीमत, फीचर पैरिटी, परफ़ॉर्मेंस। Slack, Discord, Spotify, WhatsApp जैसी ऐप्स के लिए उपयोगकर्ताओं और व्यवसायों ने ज़्यादातर परफ़ॉर्मेंस की तुलना में कीमत + पैरिटी को चुना है।
- दूसरे लोग जवाब देते हैं कि यह “काफ़ी अच्छा है” वाला रवैया bloating और खराब UX को सामान्य बनाता है, जिससे उपयोगकर्ताओं को साथ चलने के लिए और तेज़ मशीनें खरीदनी पड़ती हैं।
नेटिव बनाम क्रॉस‑प्लैटफ़ॉर्म डेवलपमेंट
- नेटिव Mac ऐप्स को तेज़, हल्की और अधिक एकीकृत माना जाता है (BBEdit, iTerm, Transmit, Telegram के नेटिव क्लाइंट्स)।
- लेकिन हर प्लेटफ़ॉर्म के लिए अलग नेटिव ऐप बनाना और संभालना बहुत महँगा और संगठनात्मक रूप से जटिल बताया जाता है; Apple पर प्लेटफ़ॉर्म churn (Toolbox/Carbon/AppKit/SwiftUI, Objective‑C/Swift) इसे और बदतर बनाती है।
- वैकल्पिक टूलकिट्स (Qt, wxWidgets, QML, Avalonia, Flutter, Godot) को “मिडिल ग्राउंड” के रूप में उल्लेख किया गया है; कुछ का कहना है कि वे आधुनिक दिख सकते हैं और बहुत कुशल हो सकते हैं, जबकि दूसरे कहते हैं कि वे अभी भी Electron से बस “कम बुरे” हैं।
परफ़ॉर्मेंस, संसाधन उपयोग, और UX
- अनुभवजन्य उदाहरण हाल के Macs पर WhatsApp के लगभग 1 सेकंड में लॉन्च होने से लेकर बड़ी histories को sync करने में 16 सेकंड या कई मिनट लगने तक फैले हैं। कुछ लोग ऐप को दोष देते हैं, कुछ हार्डवेयर या सेटअप को।
- Electron की multi-process overhead और ऊँचे RAM/CPU उपयोग के लिए आलोचना की जाती है; विरोधी दावे नोट करते हैं कि कुछ नेटिव ऐप्स भी उतनी ही भारी हैं और Electron हमेशा bottleneck नहीं होता।
- उदाहरण: नया Teams बेहद धीमा माना जाता है; Slack और Outlook स्वीकार्य माने जाते हैं; Apple Music को एक laggy, buggy नेटिव ऐप के रूप में आलोचना मिलती है, Electron-आधारित Spotify की तुलना में।
ब्राउज़र टैब्स, PWAs, और “बस वेब इस्तेमाल करो”
- कुछ लोग Slack/WhatsApp जैसी सेवाओं को ब्राउज़र टैब्स में चलाना पसंद करते हैं, क्योंकि एक्सटेंशन, tabbed workflow, और कई सौ MB की ऐप installs से बचाव मिलता है।
- दूसरे लोग desktop apps को dock icons, Cmd-Tab switching, OS-level app management, badges, और notifications के लिए महत्व देते हैं।
- PWAs पर राय बँटी हुई है: कॉन्सेप्ट पसंद किया जाता है, लेकिन कुछ लोग इसे user-controlled browser environments को कमजोर करने और exclusive APIs हासिल करने के रूप में देखते हैं। Firefox का PWA support हटाना निराशा के साथ नोट किया गया है।
अर्थशास्त्र और व्यावसायिक प्रोत्साहन
- कई टिप्पणियाँ इस पर ज़ोर देती हैं कि Electron ऐप्स अक्सर “अस्तित्व में ही न होने” के ख़िलाफ़ प्रतिस्पर्धा करते हैं, खासकर macOS और Linux पर।
- समानांतर नेटिव टीमों का समन्वय, feature parity बनाए रखना, और platform differences को संभालना, एकल Electron/Web stack की तुलना में बड़ा overhead माना जाता है।
- कुछ सुझाव देते हैं कि Apple Swift/SwiftUI को अधिक cross-platform बनाकर इसे कम कर सकता है, लेकिन उन्हें संदेह है कि Apple ऐसा करेगा।
APIs और Third-Party नेटिव क्लाइंट्स
- एक तर्क यह है: services को native apps ship ही नहीं करनी चाहिए; उन्हें full APIs expose करनी चाहिए और independent developers को native clients बनाने देना चाहिए।
- ऐतिहासिक उदाहरण: Twitter का third-party app ecosystem कंपनी द्वारा curtail किए जाने से पहले फलता-फूलता था।
- आपत्तियाँ: ऐसे wrapper apps “boring” होते हैं, बड़े पैमाने पर monetize करना कठिन होता है, और जब platforms auth rules बदलते हैं या unofficial clients को ban करते हैं, तब वे undermined हो सकते हैं। एक बंद किया गया lightweight Slack/Discord client अर्थशास्त्र और platform policy दोनों का शिकार बताया गया है।
लेख और Apple की आलोचनाएँ
- कुछ लोग इस लेख को biased “Mac-native boosterism” मानते हैं, खासकर क्योंकि यह एक Mac-only app के blog पर होस्ट है और एक local text editor की तुलना एक rich, cloud-syncing messenger से करता है।
- दूसरे Apple पर overpriced, low-RAM machines रखने का आरोप लगाते हैं, जो उपयोगकर्ताओं को bloat के प्रति असामान्य रूप से संवेदनशील बनाती हैं, और नोट करते हैं कि Apple के अपने नेटिव apps (जैसे Music, Reminders) अक्सर धीमे या खराब engineered महसूस होते हैं।
- फिर भी, एक छोटा समूह इस बात पर ज़ोर देता है कि native UX सचमुच बेहतर है, भले ही market forces के कारण कई apps कभी native न बनें।