हाल ही में, मैंने गलती से एक साधारण विज्ञापन नोट पर ठोकर खाई , "न्यूट्रेलिनोजस इलेक्ट्रॉन का एक विकल्प है जो कम मेमोरी का उपभोग करता है," जो कहता है कि न्यूट्रिनोइंज के रूप में ऐसी शांत चीज है। नोट, जैसा कि यह होना चाहिए, बहुत छोटा है और किसी भी उपयोगी जानकारी को नहीं ले जाता है, केवल विज्ञापन के नारे के अलावा "कुछ लोकप्रिय से बेहतर!"

मोटे तौर पर यह समझना कि कैसे इलेक्ट्रॉन और NW.js काम करते हैं और लेख में इस नए और सुपर-कूल "चमत्कार जानवर" के संचालन के सिद्धांत का बिल्कुल उल्लेख नहीं है, मैंने शोध शुरू किया।

वास्तव में मैं आपको अपने सूक्ष्म अनुसंधान के परिणाम प्रस्तुत करता हूं!

चूंकि मैं किसी भी नई तकनीक को एक संभावित उपकरण मानता हूं, इसलिए मैंने तुरंत कई सवाल पूछे:

• यह कई बार कम मेमोरी क्यों खाती है?
• अन्य बन्स क्या देता है?
• मुझे इस चमत्कार का उपयोग क्यों करना चाहिए?

हम स्मृति क्यों नहीं खाते हैं?

स्रोत कोड और वास्तुकला के बारे में दो काफी जानकारीपूर्ण चित्रों के माध्यम से अफवाह करते हुए, मुझे एहसास हुआ कि यह परियोजना बिल्कुल यूनिक्स मार्ग पर काम करती है, जिसे सभी लिनक्सॉइड प्यार करते हैं। परियोजना का दर्शन सरल है: यदि आप एक तैयार किए गए का उपयोग कर सकते हैं तो एक नई बाइक के साथ क्यों आएं?

इलेक्ट्रॉन की विपक्ष क्या हैं:

• क्रोम खींच रहा है
• Node.js ले जा रहा है
• अपने साथ एक लेयर ले जाना ताकि दोनों पिछले वाले एक साथ काम करें

इसके बजाय, सब कुछ इस तरह किया जाता है:

• हम क्रोम को नहीं खींच रहे हैं
• हम Node.js को नहीं खींच रहे हैं
• हम केवल कुछ ब्राउज़र और कुछ OS के बीच एक परत को खींचते हैं

आइए देखें कि यह कैसे लागू किया जाता है।

आर्किटेक्चर

पूरे प्रोजेक्ट में 2 भाग होते हैं: सर्वर और क्लाइंट।

सर्वर तुरंत शुरू होता है और ओएस के पीछे एक वास्तविक पक्षपातपूर्ण है। वह जानता है कि डेटा को कैसे स्टोर किया जाए, फाइलों को खोलें, फाइलों को लिखें, चलाएं kriptor शेल कमांड्स। वास्तव में, वह वह सब कुछ करता है जिसकी आवश्यकता हो सकती है, ऑपरेटिंग सिस्टम के लिए एक एपीआई प्रदान करता है और क्लाइंट के साथ HTTP के माध्यम से संचार करता है । वह क्लाइंट को वह सब कुछ देता है जो उसे स्क्रीन पर प्रदर्शित करना चाहिए। सर्वर के लिए काफी मानक कार्यक्षमता।

प्रत्येक ऑपरेटिंग सिस्टम के लिए, इसका C ++ सर्वर एक फ़ाइल के साथ कांटा और संशोधित किया गया था। मैक के तहत, उन्हें अभी तक कांटा के लिए कुछ नहीं मिला है, इसलिए कोई समर्थन नहीं है।

3 प्रकार के ग्राहक हो सकते हैं:

• cloud - कोई भी प्रोग्राम जो पोर्ट को जानता है जिस पर सर्वर चल रहा है वह कमांड निष्पादित कर सकता है
• browser - सर्वर खुद ही वांछित URL के साथ एक मानक सिस्टम ब्राउज़र की प्रक्रिया शुरू करता है। यहां सर्वर को पहले से ही एक विशेष टोकन की आवश्यकता होती है, जो स्वयं दिए गए HTML पृष्ठों में सम्मिलित करता है।
• window - सर्वर एक विशेष रेंडर प्रक्रिया शुरू करता है जो सिस्टम WebView को प्रदर्शित करता है। यहां आपको टोकन की भी आवश्यकता है

यह ध्यान दिया जाना चाहिए कि सर्वर केवल एक प्रकार के क्लाइंट के साथ एक साथ काम कर सकता है, और आपको mode फ़ील्ड का उपयोग करके कॉन्फ़िगरेशन में क्लाइंट के प्रकार को निर्दिष्ट करना होगा।

जैसा कि आप देख सकते हैं, अधिक कुछ नहीं। इस "फ्रेमवर्क" के आवेदन में स्वयं सोर्स कोड होते हैं, जो क्लाइंट को स्टेटिक के रूप में प्राप्त होते हैं, और स्वयं सर्वर, जो ब्राउज़र या वेबव्यू को आवश्यक URL पर सेट कर सकता है। यही सच है DRY का मतलब!

किस तरह के बन्स?

बन्स की, ज़ाहिर है, कम मेमोरी खपत। चूँकि न तो Node.js और न ही Chrome अपने साथ काम करता है, इसलिए क्लाइंट को दिया गया डेटा वॉल्यूम में बहुत कम है। इसके अलावा, डेवलपर्स जोर देते हैं कि आपको किसी भी अजीब बिल्डरों को डाउनलोड करने की आवश्यकता नहीं है, आपको समय संकलन और वह सब बर्बाद करने की आवश्यकता नहीं है।

वास्तव में पेशेवरों से, बस इतना ही है, अब चलिए अंत तक चलते हैं।

मैं तुरंत एक आरक्षण करना चाहता हूं कि यह परियोजना बहुत युवा है, 5 महीने से थोड़ा अधिक समय तक रहता है, लेकिन यह पहले से ही गर्व से संस्करण 1.1.0 करता है, इसलिए मुझे लगता है कि मेरे पास उत्पाद को तैयार करने का मूल्यांकन करने और इसे अपने प्रतियोगियों के समान पेश करने का अधिकार है।

घावों NW.js

यहाँ हम तुरंत समस्याओं का एक प्रशंसक है जो धीरे धीरे NW.js. से चले गए

उपयोगकर्ता के लिए पहली और सबसे ध्यान देने योग्य बात है आवेदन का वितरण। क्लाइंट के लिए हमारे प्रोग्राम को उसके कंप्यूटर पर लॉन्च करने के लिए, उसके पास 2 मुख्य चीज़ें होनी चाहिए: neutralino.exe और app/ फ़ोल्डर। फ़ोल्डर के अंदर, सभी सेटिंग्स संग्रहीत की जाती हैं (जैसे कि सर्वर ऑपरेटिंग मोड और विंडो शीर्षक) और वास्तव में index.html , जो क्लाइंट को दी जाती है। सबसे आसान तरीका यह है कि उपयोगकर्ता को ज़िप आर्काइव दिया जाए और बताया जाए कि किस प्रोग्राम को पॉक करना है, लेकिन उपयोगकर्ता अभी भी पाएंगे कि निर्देशों से अलग क्या करना है और क्या तोड़ना है।

इस समस्या को हल करने के लिए, NW ने एक बिल्डर का निर्माण किया, जो ICO और अभिलेखागार के साथ, exe में सब कुछ पैक करने में सक्षम था। SFX अभिलेखागार एक कम स्पष्ट समाधान था, लेकिन एंटीवायरस उन पर ध्यान देते हैं, इसलिए यह भी एक अच्छा विकल्प नहीं है। डेवलपर्स खुद अपना पैकर बनाने की योजना बना रहे हैं, लेकिन अभी तक इसके बारे में केवल अफवाहें हैं।

दूसरी समस्या प्रवेश बिंदु है। यह हमेशा index.html । आप इसके बारे में कुछ नहीं कर सकते हैं और यहां तक ​​कि एक अलग फ़ाइल भी निर्दिष्ट कर सकते हैं। इस index.html में सभी लिपियों के लिए आवेदन की जरूरत है। समस्या बहुत बड़ी नहीं है, लेकिन यह कई बार सिस्टम के लचीलेपन को कम कर देता है।

किसी प्रकार का ब्राउज़र

यह अभी भी NW.js या इलेक्ट्रॉन से भी बदतर है। यदि उत्तरार्द्ध में हम निश्चित रूप से उस ब्राउज़र के संस्करण को जानते हैं जो हमारा एप्लिकेशन प्रदर्शित करेगा, तो यहां, सिद्धांत रूप में, हम यह सुनिश्चित नहीं कर सकते हैं कि ओएस हमें एक WebView प्रदान करेगा जो JS के साथ काम कर सकता है। यही है, हम डैशिंग शून्य पर लौट रहे हैं और बहुत ही IE 8 में आने के लिए सभी संभव तरीकों से चतुर हैं, जो विंडोज पर मानक वेबव्यू होगा।

यह हमारे एप्लिकेशन को कुछ प्रकार की मीडिया फ़ाइलों को प्रदर्शित करने और चलाने के संदर्भ में सीमित करता है, और यह "वेब फॉर डेस्कटॉप" के सिद्धांत पर विकसित अनुप्रयोगों का मुख्य कार्य है।

एपीआई

जैसा कि लेखक अतिसूक्ष्मवाद के लिए प्रयास करते हैं, सर्वर द्वारा प्रदान की गई एपीआई विभिन्न तरीकों से भिन्न नहीं होती है। मैं यहां तक ​​कहूंगा कि इसे सोचा नहीं गया है। यह सभी अविवेक एक ही अल्प प्रलेखन में वर्णित हैं।

केवल वही जो सिस्टम के साथ संचार कर सकता है, वह न्यूट्रालिनो सर्वर है, फिर हमें किसी तरह इसके साथ संवाद करना चाहिए। एक तरफ़ा संचार चैनल - एचटीटीपी। वास्तव में, हमें जेएस में उपयोग करने की अनुमति दी गई है, बस बाकी एपीआई सर्वर के आसपास आवरण है।

पूरे एपीआई को 3 भागों में विभाजित किया जा सकता है: स्टोरेज के साथ काम करना, एफएस के साथ बहुत बुनियादी काम (केवल हटाएं और कोई तामझाम न पढ़ें) और सिस्टम विंडो और कमांड को कॉल करना।

अब जेएस से सुलभ एपीआई के बहुत डिजाइन पर चलते हैं।

चलो कॉलबैक से शुरू करते हैं। चूंकि हमारे पास कुछ प्रकार के ब्राउज़र हैं, इसलिए हम ES5 और दोनों का उपयोग करने में सक्षम नहीं होंगे, तदनुसार, वादा करें। और चूंकि Node.js के डेवलपर्स इसे बर्दाश्त नहीं कर सकते हैं, वे नोड-जैसे कॉलबैक का उपयोग नहीं करना चाहते हैं। इसलिए, प्रत्येक विधि में 2 कॉलबैक होते हैं: परिणाम के लिए एक, और त्रुटि से निपटने के लिए दूसरा, प्रारूप, जिस तरह से, ज्ञात नहीं है।

परिणामों की कीमत पर: अधिकांश आदेशों के लिए, उदाहरण के लिए, ओएस के साथ काम करना, एक stdout फ़ील्ड के साथ एक वस्तु, जिसके अंदर एक स्ट्रिंग स्थित है, कॉलबैक में स्थानांतरित हो जाती है। जैसा कि आप पहले से ही समझ चुके हैं, बड़ी फ़ाइलों को पढ़ना और इससे भी अधिक उन्हें किसी बफ़र जैसी वस्तु में संसाधित करना विफल हो जाएगा। सिस्टम विंडो में एक अलग प्रारूप में परिणाम होता है, file फ़ील्ड के साथ एक ऑब्जेक्ट का उपयोग किया जाता है। सवाल "क्यों, सिद्धांत रूप में, एक क्षेत्र के साथ वस्तुओं की आवश्यकता है" अनुत्तरित रहता है।

अब हम Storage पर चलते हैं। इसमें बकेट्स जैसी इकाइयाँ होती हैं जिन्हें एप्लिकेशन स्रोत के बगल में JSON फ़ाइलों के रूप में सहेजा जाता है। उसी समय, कुछ बाल्टी में डेटा लिखने के लिए, हमें एक वस्तु को बाल्टी नाम और उसकी नई सामग्री के साथ पास करना होगा। डेटा प्राप्त करने के लिए, हम केवल स्ट्रिंग पास करते हैं - बाल्टी का नाम। मानक भंडारण इंटरफ़ेस के साथ समानता का कोई संकेत नहीं है , क्यों, अपनी बाइक करें ...

खैर, आइए ओएस के साथ एकीकरण के बारे में थोड़ा बात करते हैं। याद रखें कि इलेक्ट्रॉन और यहां तक ​​कि एनडब्ल्यू ने अपने संदर्भ मेनू बनाने का अवसर दिया, खिड़की को छिपाने और यहां तक ​​कि ट्रे में एक आइकन बनाने की अनुमति दी। यह सिर्फ वहां नहीं है। और, समाधान की वास्तुकला को देखते हुए, यह कभी नहीं होगा। केवल ब्राउज़र और केवल REST API, केवल हार्डकोर।

मैं किस चीज का उपयोग कर सकता हूं?

लंबे समय से मैंने सोचा था कि यदि आपको साइट से डेस्कटॉप एप्लिकेशन में पंजीकरण फॉर्म को स्थानांतरित करने की आवश्यकता है, तो आप NW.js का उपयोग कर सकते हैं और भाप स्नान नहीं कर सकते। यदि आपको कुछ अधिक जटिल चाहिए, कुछ ऐसा जो ग्राफिक शब्दों में सिस्टम के साथ एकीकरण की आवश्यकता है, तो यह इलेक्ट्रॉन है। हां, प्रत्येक के अपने नुकसान हैं, लेकिन ये कम से कम कुछ उत्पाद हैं जिन पर आप अपना आवेदन कर सकते हैं।

लेकिन Netralinojs भी इस्तेमाल किया जा सकता है। उदाहरण के लिए, कुछ चैट काफी अच्छी तरह से काम करेंगे, केवल CORS को सर्वर पर कॉन्फ़िगर करने की आवश्यकता होगी। कुछ छोटे चित्रमय पाठ विन्यास जनरेटर बहुत अच्छा होगा। खुद के लिए, मैं इस रूपरेखा को केवल एक ग्राफिकल इंटरफ़ेस के साथ छोटी उपयोगिताओं के लिए एक मंच के रूप में देखता हूं जिसे अक्सर लॉन्च करने की आवश्यकता नहीं होती है और लंबे समय तक नहीं। मुझे लगता है कि आप भी, अपनी व्यावसायिक गतिविधि से कम से कम एक छोटे उत्पाद को याद कर सकते हैं जो इस तरह के न्यूनतर प्लेटफॉर्म पर काम कर सकता है।

निष्कर्ष

ढांचा वास्तव में बहुत, बहुत कच्चा है। इसका अतिसूक्ष्मवाद इसका मजबूत बिंदु हो सकता है, लेकिन जैसे ही सुविधाओं की आवश्यकता होती है जो एपीआई के दायरे से परे जाते हैं, आपको इलेक्ट्रॉन या NW.js.

मुझे वास्तव में उम्मीद है कि v1.1.0 अंतिम नहीं है, और डेवलपर्स अपने एपीआई के डिजाइन में कई खामियों को फिर से करेंगे और आवेदन को अनुकूलित और व्यवहार करने के लिए अधिक लचीले विकल्प प्रदान करेंगे। मुझे यह भी उम्मीद है कि वे अभी भी उन पेशेवरों पर एक स्थिर सर्वर ढूंढेंगे जिन्हें फोर्क और मैक पर इस्तेमाल किया जा सकता है।

खैर, संदर्भ, इसे और अधिक स्पष्ट करने के लिए:

• https://neutralino.js.org/ - परियोजना स्थल
• https://neutralino.js.org/docs/ - JS API दस्तावेज़ीकरण
• https://github.com/neutralinojs/neutralinojs - GitHub पर रिपोजिटरी
• https://github.com/neutralinojs/evaluation - डेवलपर्स से प्रतियोगियों के साथ हैलो वर्ल्ड की तुलना
• तटस्थ 2019 - रोडमैप - आधिकारिक सुधार योजना

युपीडी:

• https://habr.com/ru/post/443572/ - हैबर पर डेवलपर के लेख से लिंक