suji - Electron का विकल्प

यह Zig से बनाया गया Electron-जैसा टूल है.
शीर्षक तो थोड़ा स्टाइलिश लिखा है, लेकिन असल में यह Zig से बना एक डेस्कटॉप framework है.
मेरा मानना है कि डेस्कटॉप ऐप डेवलपमेंट करते समय Electron एक ऐसा विकल्प है जिसे practically टालना मुश्किल है.

खासकर जब Mac और Windows दोनों environments को साथ में ध्यान में रखना हो और तेज productivity चाहिए हो, तब Electron जितना आकर्षक framework मुझे कोई और नहीं लगता.

आप JS ecosystem को उसी रूप में इस्तेमाल कर सकते हैं, यह बाज़ार में पहले से proven है (vscode, slack, discord आदि)

और इसकी versatility और खूबियों जितने ज़्यादा use cases हैं, उतनी ही इसकी कमियाँ भी अच्छी तरह जानी जाती हैं, इसलिए यह काफ़ी आलोचना भी झेलने वाला framework है.

मैं भी उन्हीं असंतुष्ट users में से एक हूँ,

इससे परेशान होकर मैंने Tauri भी इस्तेमाल किया, लेकिन Tauri में भी system webview जैसी

पुरानी/मूलभूत सीमाएँ(?) हैं, और backend language भी Tauri इस्तेमाल करने पर Rust तक सीमित हो जाती है,

Electron इस्तेमाल करें तो Node तक सीमित,

Wails इस्तेमाल करें तो Go तक सीमित — यह बात मुझे पसंद नहीं आई.

बेशक FFI इस्तेमाल करें तो दूसरी languages भी जोड़ी जा सकती हैं, लेकिन..

असल में, खासकर आज के समय में जब language barriers काफ़ी टूट चुके हैं, framework की वजह से language constraints होना मुझे पसंद नहीं था.

zig, rust, go, lua, node

इनमें से हर एक को backend language के रूप में चुना जा सकता है, और एक साथ कई languages चुनकर backend को multi-language setup के रूप में भी सेट किया जा सकता है.

मेरा इरादा है कि backend languages में आगे भी लगातार और विकल्प जोड़ूँ.
python और Ruby भी.

चूँकि इसमें कई languages शामिल हो सकती हैं, इसलिए हर backend language आपस में IPC के ज़रिए communicate भी कर सकती है.

उदाहरण के लिए, SQLite को call करते समय Node में

better-sqlite3 install करके काम करना पड़ता है, लेकिन SQLite जैसे cases में यह built-in plugin के रूप में शामिल है, और Node सीधे Zig को call करके इसका उपयोग करता है.

मोबाइल के लिए भी build किया जा सकता है, लेकिन अभी Mac को छोड़कर बाकी platforms अस्थिर हैं.
policy के कारण सिर्फ iOS में backend language के रूप में Node का उपयोग नहीं किया जा सकता.

अभी Mac पर यह वास्तविक build और product production के लिए usable स्थिति में है, जबकि Windows और Linux में कुछ और सुधार की ज़रूरत है.
मोबाइल support भी योजना में है.

Tauri में system webview की जो कमियाँ मैंने झेली हैं,

उनकी वजह से Mac पर system webview इस्तेमाल करने का इरादा नहीं है.

API और usage को मैंने यथासंभव Electron की API के समान रखा है,

और इसमें ऐसे docs और specs हैं जिनसे AI के लिए development आसान हो जाता है; सच कहूँ तो सिर्फ documentation link दे देने पर यह अपने-आप E2E तक verify कर लेता है, इसलिए दूसरे competing(?) frameworks की तुलना में AI productivity यहाँ बहुत ज़्यादा बेहतर कही जा सकती है.

सच में, मैंने इसे बस Electron और Tauri से झुंझलाकर बनाया था,
और व्यक्तिगत रूप से अब DX tools या डेस्कटॉप ऐप बनाते समय मैं suji का इस्तेमाल करके development करता हूँ.

हो सकता है मैंने measurement गलत किया हो, लेकिन FFI के ज़रिए call करने की तुलना में इस structure में languages के बीच communication ज़्यादा तेज़ लगता है, इसलिए मैं इससे और संतुष्ट हूँ.

सरल ऐप बनाना हो और language constraints के बिना कुछ तेज़ी से ship करना हो, तो मुझे व्यक्तिगत रूप से यह Electron या Tauri से भी तेज़ लगता है.

लेकिन मैं यह जानना चाहता हूँ कि क्या यह सिर्फ इसलिए मुझे अच्छा लग रहा है क्योंकि मैंने इसे खुद बनाया है, या सच में इसमें बात है — और दूसरे लोग इस idea और approach के बारे में क्या सोचते हैं, यह सुनना चाहता हूँ, इसलिए पोस्ट कर रहा हूँ!

suji - Electron का विकल्प

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

2 टिप्पणियां