क्यों जावा दुनिया में एक आदमी Node.js और जावास्क्रिप्ट का एक प्रबल समर्थक बन गया है?

आज हम जो सामग्री प्रकाशित कर रहे हैं, उसके लेखक डेविड हैरोन ने निम्नलिखित प्रश्न पूछा: "क्या एक व्यक्ति जिसने जावा एसई टीम में सन माइक्रोसिस्टम्स में 10 से अधिक वर्षों तक काम किया है, जब तक कि अंतिम सांस तक, केवल जावा बाइटकोड के बारे में सोचें और अमूर्त इंटरफेस के उदाहरण बनाएं? "। उन्होंने यह सवाल खुद के संबंध में पूछा, और उनके लिए Node.js मंच, जावा के बाद, ताजी हवा की सांस की तरह निकला। डेविड का कहना है कि जब जनवरी 2009 में उन्हें सन से निकाल दिया गया था (इस ओरेकल कंपनी के अधिग्रहण से ठीक पहले), तो उन्हें नोड्स के बारे में पता चला। इस तकनीक ने उसे झुका दिया। इसका क्या मतलब है "झुका हुआ"? 2010 से, उन्होंने Node.js. के लिए प्रोग्रामिंग के बारे में बहुत कुछ लिखा अर्थात्, उन्होंने कई किताबें लिखीं, जिनमें Node.js वेब डेवलपमेंट भी शामिल है, जिसका चौथा संस्करण इस साल जारी किया गया था। उन्होंने इंटरनेट पर प्रकाशित Node.js के बारे में कई छोटी सामग्री तैयार की है। वास्तव में, उन्होंने Node.js प्लेटफ़ॉर्म और जावास्क्रिप्ट सुविधाओं के बारे में बात करने में बहुत समय और प्रयास बिताया। ऐसा क्यों है कि जो लोग पहले जावा में विशेष रूप से काम करते थे, वे Node.js और जावास्क्रिप्ट के लिए बहुत आकर्षित थे?

जावा वर्ल्ड के बारे में

सन में काम करते हुए, मुझे जावा तकनीक पर विश्वास था। मैंने जावाऑन में प्रस्तुतियां दीं, java.awt.Robot वर्ग के विकास में भाग लिया, मस्टैंग रेजिशन प्रतियोगिता प्रतियोगिता का आयोजन किया (यह जावा 1.6 में बग खोजने के उद्देश्य से एक प्रतियोगिता थी), जावा प्रोजेक्ट के लिए डिस्ट्रीब्यूशन लाइसेंस लॉन्च करने में मदद की, जो एक जवाब के रूप में सेवा प्रदान करता है। OpenJDK के आगमन से पहले लिनक्स JDK वितरण के बारे में सवाल। बाद में, मैंने OpenJDK परियोजना शुरू करने में भूमिका निभाई। जिस तरह से, लगभग 6 वर्षों के लिए, मैंने java.net पर ब्लॉग सामग्री प्रकाशित की (अब यह साइट बंद है)। ये प्रति सप्ताह 1-2 लेख जावा पारिस्थितिकी तंत्र में महत्वपूर्ण घटनाओं के लिए समर्पित थे। मेरे काम में एक महत्वपूर्ण भूमिका जावा की रक्षा करने वालों द्वारा निभाई गई थी जिन्होंने इस तकनीक के लिए एक धूमिल भविष्य की भविष्यवाणी की थी।


यह पुरस्कार, ड्यूक पुरस्कार, सूर्य के सबसे प्रतिष्ठित कर्मचारियों को दिया गया था। मस्टैंग रिग्रेशन कॉन्टेस्ट आयोजित करने के बाद मुझे यह मिला

उस व्यक्ति के साथ क्या हुआ जिसने जावा से संबंधित हर चीज के साथ बहुत कुछ किया है? दरअसल, यहां मैं बात करना चाहता हूं कि मैं एक जावा भक्त से Node.js और जावास्क्रिप्ट के प्रबल समर्थक में कैसे बदल गया।

मुझे कहना होगा कि मेरे साथ जो हुआ, उसे जावा का पूर्ण परित्याग नहीं कहा जा सकता। पिछले 3 वर्षों में, मैंने बहुत सारे जावा कोड लिखे हैं, स्प्रिंग और हाइबरनेट का उपयोग किया है। हालाँकि अब मैं इस क्षेत्र में क्या कर रहा हूँ जो मुझे वास्तव में पसंद है (मैं सौर ऊर्जा उद्योग में काम करता हूँ, मुझे वह करने में मज़ा आता है, उदाहरण के लिए - मैं ऊर्जा क्षेत्र से डेटा के साथ काम करने के लिए अनुरोध लिखता हूं), मेरी आँखों में अब जावा प्रोग्रामिंग अपने पूर्व वैभव को खो दिया।

वसंत का उपयोग करते हुए दो साल के विकास ने मुझे एक महत्वपूर्ण बात स्पष्ट रूप से स्पष्ट करने की अनुमति दी: जटिल तंत्र को छिपाने का प्रयास सरलता की ओर नहीं जाता है, यह केवल और भी अधिक जटिल संरचनाओं की उपस्थिति की ओर जाता है।

यहाँ, संक्षेप में, मुख्य विचार हैं जो मैं इस सामग्री पर स्पर्श करूँगा:

• जावा प्रोग्राम बॉयलरप्लेट कोड से भरा हुआ है जो प्रोग्रामर के इरादों को छुपाता है।
• स्प्रिंग और स्प्रिंग बूट के साथ काम करने से मुझे एक अच्छा सबक मिला है, जो यह है कि जटिल तंत्र को छिपाने की कोशिश करने से और भी अधिक जटिल निर्माण होते हैं।
• जावा ईई प्लेटफ़ॉर्म एक प्रोजेक्ट था, जिसे "सामान्य प्रयासों" द्वारा बोलना था, जो एंटरप्राइज़ एप्लिकेशन डेवलपमेंट की सभी जरूरतों को पूरा करता है। नतीजतन, जावा ईई प्लेटफॉर्म निषेधात्मक साबित हुआ है।
• वसंत के साथ विकसित करना, एक बिंदु तक, एक सुखद अनुभव है। यह भ्रम उस दिन गायब हो जाता है जब एक अपवाद जो समझना पूरी तरह से असंभव है एक उपतंत्र की गहराई से आता है जिसे आपने कभी नहीं सुना है, और यह पता लगाने में कम से कम तीन दिन लगते हैं कि समस्या क्या है।
• क्या सहायक तंत्र जो सिस्टम पर अत्यधिक भार पैदा करते हैं, क्या आपको एक रूपरेखा की आवश्यकता है जो प्रोग्रामर के लिए "कोड" लिख सकता है?
• हालांकि ग्रहण जैसे आईडीई शक्तिशाली अनुप्रयोग हैं, वे जावा पारिस्थितिकी तंत्र की जटिलता का सूचक हैं।
• Node.js प्लेटफ़ॉर्म एक व्यक्ति द्वारा हल्के इवेंट-संचालित आर्किटेक्चर के अपने दृष्टिकोण को बेहतर बनाने के प्रयासों के परिणामस्वरूप आया।
• जावास्क्रिप्ट समुदाय बॉयलरप्लेट कोड से छुटकारा पाने के बारे में उत्साही प्रतीत होता है, जो प्रोग्रामर को अपने इरादों को यथासंभव स्पष्ट रूप से व्यक्त करने की अनुमति देता है।
• Async / इंतजार जेएस कॉलबैक नरक समस्या का समाधान है, जो टेम्पलेट कोड को अस्वीकार करने और प्रोग्रामर के इरादों की अभिव्यक्ति की स्पष्टता में योगदान करने का एक उदाहरण है।
• Node.js के लिए प्रोग्रामिंग एक वास्तविक खुशी है।
• जावास्क्रिप्ट में जावा के लिए कोई विशिष्ट टाइपिंग नहीं है। यह जीभ का आशीर्वाद और अभिशाप है। इससे कोड लिखना आसान हो जाता है, लेकिन इसकी शुद्धता को सत्यापित करने के लिए, आपको परीक्षण के लिए अधिक समय देना होगा।
• Npm / यार्न द्वारा शुरू की गई पैकेज प्रबंधन प्रणाली प्रयोग करने में आसान और मजेदार है। उसकी तुलना मावेन से नहीं की जा सकती।
• Java और Node.js दोनों ही शानदार प्रदर्शन करते हैं। यह इस मिथक से जुड़ा है कि जावास्क्रिप्ट एक धीमी भाषा है, जिसके उपयोग से Node.js प्लेटफॉर्म का प्रदर्शन खराब होता है।
• प्रदर्शन Node.js, V8 को बेहतर बनाने के लिए Google के प्रयासों पर आधारित है, जो इंजन क्रोम ब्राउज़र की गति को प्रभावित करता है।
• ब्राउज़र-आधारित जेएस इंजन के निर्माताओं के बीच भयंकर प्रतिस्पर्धा जावास्क्रिप्ट के विकास में योगदान करती है, और यह Node.s.s. के लिए बहुत फायदेमंद है

जावा विकास के मुद्दों के बारे में

कुछ उपकरण या वस्तुएं इंजीनियरों द्वारा उन्हें सुधारने के कई वर्षों के प्रयासों का परिणाम हैं। प्रोग्रामर विभिन्न विचारों को आज़माते हैं, अनावश्यक विशेषताओं को हटाते हैं, और परिणामस्वरूप उन्हें ऐसी संस्थाएँ मिलती हैं जिनमें एक विशेष रूप से एक निश्चित समस्या को हल करने की आवश्यकता होती है। अक्सर, ऐसी तकनीकों में एक बहुत ही आकर्षक सादगी होती है जो शक्तिशाली क्षमताओं को छुपाती है। यह जावा पर लागू नहीं होता है।

जावा-आधारित वेब अनुप्रयोगों को विकसित करने के लिए स्प्रिंग एक लोकप्रिय ढांचा है।

वसंत का मुख्य लक्ष्य, और विशेष रूप से स्प्रिंग बूट में, पूर्व-कॉन्फ़िगर जावा ईई स्टैक का उपयोग करने की क्षमता प्रदान करना है। प्रोग्रामर जो स्प्रिंग का उपयोग करता है, उसे तैयार सिस्टम बनाने के लिए नहीं करना चाहिए, सर्वलेट्स, लगातार स्टोरेज सिस्टम, एप्लिकेशन सर्वर का ध्यान रखना चाहिए, और जो अभी भी अज्ञात है। इन सभी चिंताओं को वसंत पर पारित किया जाता है, और प्रोग्रामर कोड लिख रहा है जो आवेदन के तर्क को लागू करता है। उदाहरण के लिए, JPARepository तंत्र उन विधियों के लिए डेटाबेस क्वेरी तैयार करने के लिए ज़िम्मेदार है जिनके नाम findUserByFirstName तरह findUserByFirstName । प्रोग्रामर को ऐसे तरीकों के लिए कोड लिखने की ज़रूरत नहीं है। सिस्टम के लिए विधि का वर्णन पास करने के लिए पर्याप्त है, और स्प्रिंग बाकी काम करेगा।

यह सब बहुत अच्छा लगता है, इस शैली में काम करना अच्छा है, लेकिन - जब तक कि कुछ अप्रत्याशित न हो जाए।

मेरा मतलब ऐसी स्थिति से है, उदाहरण के लिए, एक हाइबरनेट PersistentObjectException detached entity passed to persist संदेश के साथ फेंक detached entity passed to persist । इसका क्या मतलब हो सकता है? यह पता लगाने में कई दिन लग गए। जैसा कि यह पता चला है, यदि आप सब कुछ बहुत सरल तरीके से वर्णन करते हैं, तो इसका मतलब है कि REST समापन बिंदु पर प्राप्त JSON डेटा में कुछ मानों के साथ ID फ़ील्ड हैं। हाइबरनेट, फिर से, यदि विवरण में नहीं जा रहा है, तो आईडी मानों को नियंत्रित करने का प्रयास करता है, और, परिणामस्वरूप, उपरोक्त अस्पष्ट अपवाद को फेंकता है। ऐसे हजारों त्रुटि संदेश हैं जो भ्रमित और पढ़ने में मुश्किल हैं। यह ध्यान में रखते हुए कि वसंत में एक दूसरे के आधार पर उपप्रणालियों के पूरे कैस्केड हैं, स्प्रिंग स्टैक एक प्रोग्रामर के शत्रु की तरह दिखता है जो उसे देखता है और थोड़ी सी गलती करने के लिए प्रोग्रामर की प्रतीक्षा करता है, और जब ऐसा होता है, तो अपवादों को फेंकता है जो इसके अनुरूप नहीं हैं आवेदन के सामान्य संचालन।

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

यह कैसे पता चलता है कि प्रोग्रामर ने इस तरह की विधि के लिए कोड नहीं लिखा है, यह पता findUserByFirstName जाता है कि findUserByFirstName विधि कैसे findUserByFirstName जाती है? फ्रेमवर्क को विधि नाम को पार्स करने की जरूरत है, प्रोग्रामर के इरादे को समझें, अमूर्त सिंटैक्स ट्री की तरह कुछ बनाएं, कुछ प्रकार के एसक्यूएल कोड उत्पन्न करें, और इसी तरह। यह सब सिस्टम को कैसे लोड करता है? और यह सब केवल मौजूद है ताकि प्रोग्रामर को कोड लिखने की आवश्यकता न हो?

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

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


पिछड़ी संगतता बहुत महत्वपूर्ण है।

बेशक, पिछड़ी संगतता पर ध्यान देने का यह स्तर निरंतर चिंता का स्रोत हो सकता है, और समय-समय पर पुराने तंत्र से दूर जाने के लिए उपयोगी होता है जो अब लाभ नहीं करता है।

जावा और नोड.जेएस

स्प्रिंग और जावा ईई अत्यधिक जटिल हैं। उनकी पृष्ठभूमि के खिलाफ Node.js मंच को ताजी हवा की सांस के रूप में माना जाता है। जब आप Node.js से परिचित हो रहे हैं, तो पहली बात यह है कि मंच कोर के विकास के लिए रयान डाहल का दृष्टिकोण है। उनके अनुभव ने उन्हें बताया कि जटिल, हैवीवेट सिस्टम बनाने के लिए धाराओं का उपयोग करने वाले प्लेटफार्मों की आवश्यकता होती है। वह कुछ और की तलाश में था, और Node.js. में सन्निहित बुनियादी तंत्र के सेट को सुधारने में कुछ साल बिताए। नतीजतन, उन्हें एक हल्का सिस्टम मिला जो कि निष्पादन के एक एकल धागे की विशेषता है, अतुल्यकालिक कॉलबैक के रूप में अनाम जावास्क्रिप्ट कार्यों का आविष्कारशील उपयोग, और एक रनटाइम लाइब्रेरी जो मूल रूप से अतुल्यकालिक तंत्र को लागू करता है। इस तरह की प्रणाली बनाते समय प्रारंभिक संदेश कॉलबैक फ़ंक्शन में इन घटनाओं के वितरण के साथ उच्च-प्रदर्शन घटना प्रसंस्करण प्रदान करना था।

अगला, Node.js की एक महत्वपूर्ण विशेषता जावास्क्रिप्ट का उपयोग है। एक भावना है कि जेएस में लिखने वालों में टेम्पलेट कोड से छुटकारा पाने की प्रवृत्ति है, जो उन्हें प्रोग्रामर के इरादों का स्पष्ट रूप से वर्णन करने की अनुमति देता है।

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

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

इसलिए, यहां एक महत्वपूर्ण विचार है जो उपरोक्त तंत्रों के विश्लेषण से लिया जा सकता है: अधिकांश प्रोग्रामिंग भाषाएं प्रोग्रामर के इरादों को छिपाती हैं, जो इस तथ्य की ओर जाता है कि कोड को समझना मुश्किल है।

कॉलबैक फ़ंक्शंस के उपयोग के बारे में निर्णय जो कि Node.js ऑफ़र बहुत आकर्षक लगता है। लेकिन यह समस्याओं के बिना नहीं है।

समस्या का समाधान और समस्या का समाधान

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

जेएस पर अतुल्यकालिक विकास को सरल बनाने के लिए कई पुस्तकालय सामने आए हैं। लेकिन यह जटिल तंत्र को छिपाने के प्रयास का एक और उदाहरण है जो केवल और भी अधिक जटिल संरचनाओं की उपस्थिति की ओर जाता है।

एक उदाहरण पर विचार करें:

 const async = require('async'); const fs = require('fs'); const cat = function(filez, fini) { async.eachSeries(filez, function(filenm, next) {   fs.readFile(filenm, 'utf8', function(err, data) {     if (err) return next(err);     process.stdout.write(data, 'utf8', function(err) {       if (err) next(err);       else next();     });   }); }, function(err) {   if (err) fini(err);   else fini(); }); }; cat(process.argv.slice(2), function(err) { if (err) console.error(err.stack); }); 

यह यूनिक्स cat की एक नॉन्डस्क्रिप्ट नकल है। एसिंक्रोनस कॉल सीक्वेंस को आसान बनाने में async लाइब्रेरी async । हालाँकि, इसके उपयोग के लिए बड़ी मात्रा में बॉयलरप्लेट कोड की आवश्यकता होती है जो प्रोग्रामर के इरादे को छुपाता है।

संक्षेप में, इस कोड में एक लूप होता है। यह एक नियमित चक्र के रूप में नहीं लिखा गया है, यह चक्रों के विवरण के प्राकृतिक निर्माण का उपयोग नहीं करता है। इसके अलावा, कोड निष्पादन और उनके द्वारा उत्पन्न त्रुटियों के परिणाम उन्हें नहीं मिलते, जहाँ वे सही होते। वे कॉलबैक में बंद हैं, जो असुविधाजनक है। लेकिन, Node.js में ES2015 / 2016 के मानकों के कार्यान्वयन से पहले, कुछ भी बेहतर नहीं किया जा सकता था।

यदि हम नई सुविधाओं को ध्यान में रखते हुए इस कोड को फिर से लिखते हैं, जो विशेष रूप से, Node.js 10.x में उपलब्ध हैं, तो हमें निम्नलिखित मिलते हैं:

 const fs = require('fs').promises; async function cat(filenmz) { for (var filenm of filenmz) {   let data = await fs.readFile(filenm, 'utf8');   await new Promise((resolve, reject) => {     process.stdout.write(data, 'utf8', (err) => {       if (err) reject(err);       else resolve();     });   }); } } cat(process.argv.slice(2)).catch(err => {   console.error(err.stack); }); 

इस उदाहरण में, हमने async/await निर्माण का उपयोग किया है। उसी अतुल्यकालिक तंत्र को पिछले उदाहरण के रूप में यहां प्रस्तुत किया गया है, लेकिन लूप के आयोजन में उपयोग की जाने वाली सामान्य संरचनाएं यहां उपयोग की जाती हैं। परिणाम और त्रुटियों के साथ काम करना काफी सामान्य लगता है। ऐसे कोड को पढ़ना और लिखना आसान है। यह दृष्टिकोण प्रोग्रामर के इरादे को समझना आसान बनाता है।

एकमात्र दोष यह है कि process.stdout.write में एक प्रोमिस इंटरफ़ेस नहीं है, परिणामस्वरूप, इस तंत्र का उपयोग async कार्यों में नहीं किया जा सकता है इसे वादे में लपेटे बिना।

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

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

मजबूत टाइपिंग, इंटरफेस और काल्पनिक कोड स्पष्टता

उन दिनों में जब मैं सभी प्रकार के हमलों से जावा की रक्षा कर रहा था, तो मैंने जोर दिया कि सख्त टाइपिंग आपको विशाल एप्लिकेशन लिखने की अनुमति देती है। उन दिनों में, अखंड प्रणालियों का विकास उपयोग में था (न कोई माइक्रोसर्विस थे, न ही डॉकटर और जैसा था)। चूँकि जावा एक दृढ़ता से टाइप की जाने वाली भाषा है, जावा कंपाइलर प्रोग्रामर को बहुत सारी समस्याओं से बचने में मदद करता है ताकि उसे गलत कोड के संकलन से रोका जा सके।

जावा के विपरीत जावास्क्रिप्ट, दृढ़ता से टाइप नहीं किया गया है। इससे हम स्पष्ट निष्कर्ष निकाल सकते हैं कि प्रोग्रामर को ठीक से पता नहीं है कि उसे किन वस्तुओं के साथ काम करना है। एक प्रोग्रामर कैसे जान सकता है कि क्या करना है, उदाहरण के लिए, किसी निश्चित वस्तु को कहीं से प्राप्त किया गया है?

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

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

और ... मैं मावेन के बारे में बात नहीं करूंगा। यह सिर्फ एक बुरा सपना उपकरण है।

जावास्क्रिप्ट में, चर प्रकार निर्दिष्ट नहीं होते हैं जब वे घोषित होते हैं, तो टाइप कास्टिंग आमतौर पर उपयोग नहीं की जाती है, और इसी तरह। नतीजतन, कोड को पढ़ना आसान है, लेकिन इस स्थिति का मतलब प्रोग्रामिंग त्रुटियों का जोखिम भी है जो पता लगाना मुश्किल है।

चाहे पूर्वगामी जावा के pluses से संबंधित हो या minuses के दृष्टिकोण पर निर्भर करता है।

दस साल पहले, मेरा मानना ​​था कि ये सभी कठिनाइयाँ प्रोग्रामर को अपने द्वारा लिखे गए कोड पर अधिक विश्वास दिलाकर खुद को सही ठहराती हैं। आज, मेरा मानना ​​है कि मजबूत टाइपिंग से प्रोग्रामर का वर्कलोड बढ़ जाता है और प्रोजेक्ट्स को विकसित करना बहुत आसान हो जाता है क्योंकि वे जावास्क्रिप्ट में काम करते हैं।

छोटे मॉड्यूल के साथ त्रुटियों से लड़ें जो परीक्षण करना आसान है

Node.js प्रोग्रामर को छोटे-छोटे टुकड़ों में, तथाकथित मॉड्यूल में तोड़ने के लिए धक्का देता है। आप इस तथ्य को महत्वहीन पा सकते हैं, लेकिन यह आंशिक रूप से हमारे द्वारा बताई गई समस्या को हल करता है।

यहाँ मॉड्यूल की मुख्य विशेषताएं हैं:

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

यह सब स्पष्ट रूप से परिभाषित सीमाओं के साथ Node.js मॉड्यूल संस्थाओं को बनाता है, जिनमें से कोड लिखना, पढ़ना और परीक्षण करना आसान है।

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

जावास्क्रिप्ट में डायनामिक टाइपिंग की समस्या का एक और समाधान कोड का पूरी तरह से परीक्षण करना है।

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

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

अंत में, हम कह सकते हैं कि विकास के लिए एक मॉड्यूलर दृष्टिकोण का उपयोग करना Node.js और जावास्क्रिप्ट की ताकत है।

पैकेज प्रबंधन

मुझे मावेन के बारे में सोचना बुरा लगता है, इसलिए मैं इसके बारे में सामान्य रूप से नहीं लिख सकता। और, जैसा कि मैं इसे समझता हूं, मावेन, समझौता किए बिना, या तो प्यार करता है या नफरत करता है।

यहां समस्या यह है कि जावा वातावरण में संकुल के प्रबंधन के लिए कोई समग्र प्रणाली नहीं है। मावेन पैकेज मौजूद हैं, आप सामान्य रूप से उनके साथ काम कर सकते हैं, वे ग्रेडल द्वारा समर्थित हैं। लेकिन जिस तरह से उनके साथ काम किया जाता है, वह उस उपयुक्तता से निकट से मेल नहीं खाता है जो Node.js के लिए पैकेज प्रबंधन प्रणाली डेवलपर को देती है।

Node.js की दुनिया में, दो महान पैकेज प्रबंधक हैं जो एक दूसरे के साथ मिलकर काम करते हैं। सबसे पहले, एकमात्र ऐसा उपकरण एनपीएम रिपॉजिटरी और उसी नाम का कमांड लाइन टूल था।

Npm के लिए धन्यवाद, हमारे पास पैकेज निर्भरता का वर्णन करने के लिए एक उत्कृष्ट योजना है। निर्भरताएं सख्त हो सकती हैं (कहते हैं, यह इंगित किया जाता है कि एक निश्चित पैकेज के केवल 1.2.3 संस्करण की आवश्यकता है), या स्वतंत्रता के कई डिग्री के साथ दिया गया - * , जिसका अर्थ है एक निश्चित पैकेज के नवीनतम संस्करण का उपयोग करना।

Node.js समुदाय ने npm रिपॉजिटरी में सैकड़ों हजारों पैकेज प्रकाशित किए हैं। इसी समय, उन पैकेजों का उपयोग करना जो npm में नहीं हैं, npm से संकुल का उपयोग करना उतना ही आसान है।

एनपीएम प्रणाली इतनी सफल रही कि नोड.जेएस पर न केवल सर्वर उत्पादों के डेवलपर्स इसका उपयोग करते हैं, बल्कि फ्रंट-एंड प्रोग्रामर भी हैं। पहले, पैकेज प्रबंधित करने के लिए Bower जैसे टूल का उपयोग किया जाता था। बोवर को हटा दिया गया था, और अब आप पा सकते हैं कि फ्रंट डेवलपमेंट के लिए सभी जेएस लाइब्रेरी npm पैकेज के रूप में मौजूद हैं। क्लाइंट के विकास के कई सहायक उपकरण, जैसे कि Vue.js CLI और वेबपैक, को Node.js एप्लिकेशन के रूप में लिखा जाता है।

Node.js, यार्न के लिए एक और पैकेज प्रबंधन प्रणाली, npm रिपॉजिटरी से संकुल डाउनलोड करता है और उसी विन्यास फाइल का उपयोग करता है। एनपीएम पैकेज मैनेजर पर यार्न का मुख्य लाभ इसकी उच्च गति है।

Npm रिपॉजिटरी, चाहे npm पैकेज मैनेजर या यार्न पैकेज मैनेजर का उपयोग कर रही है, जो कि Node.js के लिए इतना आसान और सुखद विकसित करने के लिए एक शक्तिशाली आधार है।


एक बार, मैंने java.awt.Robot को विकसित करने में मदद करने के बाद, मुझे इस चीज को बनाने के लिए प्रेरित किया। जबकि आधिकारिक ड्यूक छवि वक्रों से बनी है, रोबो ड्यूक सीधी रेखाओं से निर्मित है। इस रोबोट के केवल कोहनी के जोड़ गोल हैं

उत्पादकता

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

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

JDK Sun/Oracle HotSpot — , -. , , , , , . HotSpot — , .

JavaScript, , JS-, , , - . , JavaScript . , , . , , Google Docs, . JS .

Node.js , V8 Google Chrome.

, Google, V8, . , V8 Crankshaft Turbofan.

— , , R Python. , , . JavaScript, , , JavaScript.

JavaScript , TensorFlow.js. API API TensorFlow Python, . , , , .

IBM, Node.js, , , Docker/Kubernetes. , Node.js Spring Boot. -, . , Node.js , , , V8.

, Node.js . . - , Node.js , . , «Node.js Web Development», , :

• — .
• , Node.js .
• .

JavaScript , Node.js. — Node.js-. Node.js- node-gyp , . , Rust- Node.js.

WebAssembly , , JavaScript, . WebAssembly , JavaScript-. WebAssembly Node.js.

-

- (Rich Internet Applications, RIA) . , , ( ) JS-, .

, 20 . Sun Netscape Java- Netscape Navigator. JavaScript , , Java-. , Java-, — Java-. , . .

JavaScript , . RIA, , - Java -.

, RIA . Node.js , , , . JavaScript.

यहाँ कुछ उदाहरण हैं:

• Google Docs ( ), , .
• , React, Angular Vue.js, , HTML, CSS JavaScript.
• Electron — Node.js Chromium. - . , Visual Studio Code, Atom, GitKraken, Postman.
• Electron/NW.js , -, , React, Angular, Vue, .

Java, , - -, JavaScript. , , - Sun Microsystems. Sun , . . Java- , Java Java Web Start. Java- Webstart-.

Java, , , IDE NetBeans Eclipse . Java , , Java.

JavaFX.

JavaFX, 10 , Sun iPhone. , Java, , , . Flash iOS. . JavaFX , , . - React, Vue.js .

JavaScript Node Java.

Java, - JavaONE. Java . , , , .


Java

परिणाम

. «P-» (Perl, PHP, Python) Java, Node.js, Ruby, Haskell, Go, Rust, . .

, , , Java, Node.js, , , Node.js-. Java , Node.js . , , , Java, .

. , , Node.js - , - . . , XBRL-. XBRL Python, , , Python. , , , .

प्रिय पाठकों! , , JavaScript - , - Node.js, .