- ब्राउज़र को एम्बेड किए बिना, OS में पहले से इंस्टॉल ब्राउज़र का उपयोग करता है (webview नहीं)
- Chromium और Firefox सपोर्ट
- bundle size छोटा है और build तेज़ है
- सरल लेकिन शक्तिशाली API के साथ तेज़ prototyping का समर्थन
- Node.js के बजाय Deno सपोर्ट (प्रायोगिक चरण)
- Windows/Linux सपोर्ट, Mac पर काम जारी
6 टिप्पणियां
यह Go से बने समान कॉन्सेप्ट वाले Wails जैसा लगता है।
तकनीक दिलचस्प लगती है, लेकिन मुझे इसके लिए कोई ज़रूरी उपयोग का मामला समझ नहीं आता।
क्या यह ऐसा रूप नहीं है जिसमें वेब ब्राउज़र को एम्बेड करने के तरीके और WebView इस्तेमाल करने के तरीके—दोनों की कमियाँ ही एक साथ इकट्ठी कर दी गई हों..?
क्या यह bundle size कम करने और memory बचाने के लिए नहीं है?
मुझे दोनों बातों पर संदेह है।
Gluon को ऐसी संरचना के रूप में समझाया गया है जिसमें web browser भी चलता है, और उस web browser को नियंत्रित करने वाला NodeJS भी चलता है। पूरे web browser का memory उपयोग WebView component के बराबर या उससे अधिक होने की संभावना है (UI/UX हिस्से की वजह से), और उसके ऊपर NodeJS भी जुड़ता है, तो क्या इससे वाकई memory की बचत होगी... समझ नहीं आता।
यहाँ तक कि वेबसाइट पर दिखाया गया bundle size भी इस मान्यता पर आधारित है कि 'NodeJS पहले से ही system में installed है', इसलिए size वैसा दिख रहा है, और build time में tauri की तरफ़ वाला तो Rust crate तक शुरू से शुरू होने वाला पूरी तरह cold build है..
लगता है कि यह Tauri जैसे कॉन्सेप्ट (सिस्टम में मौजूद browser का उपयोग) को node से इम्प्लीमेंट करता है...
अगर मौजूदा browser instance को दोबारा इस्तेमाल किया जाए, तो मेमोरी बचाई जा सकती है। अभी Electron app के मामले में समस्या यह है कि हर app को अपना Electron engine मेमोरी में लोड करना पड़ता है।