क्या गैर-रियलटाइम वेब ऐप के लिए नोड.जेएस से बचने का एक अच्छा कारण है?

Question

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

मैंने अधिक सरल, 'पारंपरिक', गैर-रियलटाइम ऐप (उदाहरण के लिए, मानक ब्लॉग उदाहरण, जो कि ऐप डेवलपमेंट सीखने वाले लोगों के लिए मानक 'हैलो वर्ल्ड' लगता है) के लिए Node.js ट्यूटोरियल भी देखा है। और मुझे यह भी पता है कि नोड-स्टैटिक आपको स्थैतिक संपत्ति की सेवा करने की अनुमति देता है।

मेरा प्रश्न है: क्या पारंपरिक वेब ऐप्स, जैसे क्लासीफाइड, फ़ोरम, उपरोक्त ब्लॉग उदाहरण या आंतरिक व्यापार अनुप्रयोगों के लिए आपके द्वारा बनाए गए CRUD ऐप के लिए Node.js से बचने का कोई अच्छा कारण है ? सिर्फ इसलिए कि यह सभी कायरता realtime सामान पर excels, करता है कि इसे और अधिक उपयोग करता है के लिए contraindicated है?

केवल एक चीज जिसके बारे में मैं सोच सकता हूं, वह बल्ले से, परिपक्व पुस्तकालयों की कमी है (हालांकि यह बदल रहा है)।

(कारण मैं पूछ रहा हूं कि मैं Node.js के लिए PHP को डीपिंग करने पर विचार कर रहा हूं, ज्यादातर भाषाओं के बीच स्विच करने की प्रतिबाधा बेमेल पर पाने के लिए, लेकिन इसलिए भी मैं सत्यापन कोड और व्हाट्सएप का पुन: उपयोग कर सकता हूं। मेरे सुपरिगो ने मुझे चुनने के लिए मुझे बुलाया। नौकरी के लिए सबसे अच्छा साधन ; हालाँकि, मेरे पास पंद्रह भाषाएं और उनके सभी उपयोगकर्ता पुस्तकालयों को सीखने के लिए बहुत समय नहीं है, बस एक व्यापक शस्त्रागार है। यह भी आश्वस्त है कि Node.js मुझे PHP के लिए एक आसान अनुकूलन मार्ग दे सकता है। भविष्य में अपाचे जब मुझे भारी ट्रैफ़िक के बारे में सोचना शुरू करना होगा। ”

[संपादित करें] अब तक के जवाब के लिए धन्यवाद, लोग; मैं सिर्फ यह देखना चाहता हूं कि जवाब चुनने से पहले क्या कोई और तौलेगा। @ रेयानोस थोरा का उत्तर इस बात की पुष्टि करता है कि मैं क्या सोच रहा हूं, और टिप्पणीकारों के लिंक ने विचार के लिए अच्छा भोजन प्रदान किया, लेकिन मैं यह देखना चाहता हूं कि क्या किसी और के पास कोई नोड-विशिष्ट उत्तर हैं, जैसे PROBLEM X के लिए 'उपयोग न करें'। '। (उच्च CPU कार्यों के अलावा, मुझे पता है कि पहले से ही :-)

Comments

@ default.kramer: लिंक के लिए धन्यवाद, मुझे वास्तव में बहुत मज़ा आया!

— Zach

वाह! बल्कि चप, राय? अनुवर्ती लेख में, वह यह कहते हुए प्रतीत होता है कि, उच्च- I / O और निम्न-CPU अनुप्रयोगों के लिए, इवेंट किए गए और थ्रेडेड सिस्टम लगभग बराबर हैं, और यह समस्या नौसिखिए प्रोग्रामर के साथ है जो नहीं जानते कि कब घटनाओं पर छोड़ देना और एक नया धागा बनाना। लेकिन प्रोग्रामर की अज्ञानता का मतलब यह नहीं है कि उपकरण खराब है, क्या यह है? मैं इस बात से सहमत हूं कि ऐसे वातावरण का उपयोग करना जिसका सीपीयू-गहन कार्यों के लिए ईवेंट लूप है, थोड़ा अजीब है, लेकिन क्या यह बुराई है?

— पॉल डी'अवेस्ट नोव

जावास्क्रिप्ट से उसकी नफरत एक महत्वपूर्ण मुद्दा है, जो मुझे डर है कि उसके तर्क के पीछे ऊर्जा के लिए आंशिक रूप से जिम्मेदार हो सकता है।

— पॉल डी'अवेस्ट 18

@Paul - आपको इसे नमक के दाने के साथ लेना चाहिए। मैं Node.js के बारे में ज्यादा नहीं जानता; मुझे लगा कि यह हास्यजनक है। (उनके लेखन की तरह)

— default.kramer

@ default.kramer अनुस्मारक के लिए धन्यवाद; मैं लोगों की राय को सुसमाचार के रूप में लेता हूँ। उनकी प्रमुख वैध आलोचना यह प्रतीत होती है कि आपको CPU- गहन कार्यों के लिए Node.js का उपयोग नहीं करना चाहिए। मैं कार्यकर्ता प्रक्रियाओं की उनकी आलोचना के बारे में उलझन में हूं; क्या विशिष्ट कार्यों के लिए अलग श्रमिक बनाने में कोई बड़ी समस्या है?

— 20 अप्रैल को पॉल डी'अवेट

Answer 1

पारंपरिक वेब ऐप्स के लिए Node.js से बचने का कोई अच्छा कारण है

हां, यदि आपके पास वेब प्लेटफॉर्म X में N साल है तो स्पष्ट रूप से आप तेजी से प्लेटफॉर्म X में एक एप्लिकेशन डेवलपर कर सकते हैं।

यदि आप Y करना चाहते हैं और प्लेटफॉर्म X के पास एक पूर्व-निर्मित समाधान Y है जो X करता है तो ऐसा करें।

क्यों आप एक से अधिक एक मंच का उपयोग करना चाहिए के सभी सामान्य कारणों।

आंतरिक व्यावसायिक अनुप्रयोगों के लिए आपके द्वारा बनाए गए CRUD ऐप्स के प्रकार?

हाँ, ऐसे अन्य प्लेटफ़ॉर्म हैं जो आपको एक सामान्य एप्लिकेशन को तेज़ी से लिखने देते हैं, रेल पर रूबी का ध्यान आता है।

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

मूल रूप से यह एक सरल प्रश्न है

क्या एक उपकरण मौजूद है जो मेरे लिए यह सब करता है? नहीं, फिर टूल लिखने के लिए सबसे सुविधाजनक प्लेटफ़ॉर्म चुनें।

कोई ठोस कारण नहीं है कि नोड.जेएस एक असुविधाजनक मंच है (अन्य तो "आई हेट जावास्क्रिप्ट")

Comments

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

— योर-थिंक

@ Pauld'Aoust मैं एक रोल-योर-थिंक वाला लड़का हूं। हालाँकि मुझे कुछ नहीं हुआ और मेरे पास समय सीमा नहीं है।

— रेयनोस

हे, चेतावनी के लिए धन्यवाद। मुझे अन्य लोगों के मॉडल पुस्तकालयों (Backbone.js, इत्यादि) का उपयोग करने के बारे में आपकी टिप्पणी याद है। और यह महसूस करते हुए कि मैं Backbone.js सीखने में बहुत समय बिता रहा था और पर्याप्त समय नहीं था जिसका लाभ उठा रहा था (और सीखने) जावास्क्रिप्ट प्रोटोटाइपिक विरासत तंत्र। अच्छी सलाह; मैं अब और अधिक आराम महसूस करता हूं।

— 20

-1 अस्पष्ट। 1) सिर्फ इसलिए कि आपके पास एक्स में एन वर्षों का अनुभव है - इसका मतलब यह नहीं है कि आपको नोड से बचना चाहिए। जे.एस. क्या आप अनुभव के आधार पर विलफुल अज्ञानता का प्रस्ताव कर रहे हैं? और "सामान्य कारण" क्या हैं? 2) 'अन्य एप्लिकेशन जो आपको एक सामान्य एप्लिकेशन को तेजी से लिखने देते हैं' - विशुद्ध रूप से व्यक्तिपरक है। 3) '* * के अलावा "आई हेट * जावास्क्रिप्ट' - भी व्यक्तिपरक है और एक समृद्ध तकनीक से बचने का एक वैध कारण नहीं है। * वर्तनी

— जैक स्टोन

@ क्लिंटनैश आपके कुछ कारणों से अलग नहीं है। "मानव संसाधन" बनाम "एन वर्ष का अनुभव" एक समान हैं। "NodeJS पारंपरिक फ्रेमवर्क के रूप में परिपक्व नहीं है" बनाम "हां एक और मंच है जो आपको एक सामान्य एप्लिकेशन को तेजी से लिखने देता है, रेल पर रूबी का ख्याल आता है।" भी वही हैं। न केवल वे समान हैं, लेकिन तुम्हारा उससे अधिक मापनीय (उद्देश्य) नहीं है।

— आचमन

Answer 2

कुछ हफ़्ते के लिए नोड के साथ काम करने के बाद, मैं कहूँगा हाँ, यह बहुत अच्छा है। लेकिन जरूरी नहीं कि आप अपने रन-ऑफ-द-मिल वेब ऐप्स को बदलने के लिए उपयोग करना चाहते हों ... और न ही, imo, क्या यह होना चाहिए।

याद रखें, नोड अपना स्वयं का सर्वर है। यदि आप अपने केवल एक नोड से अधिक आवेदन चलाना चाहते हैं तो यह जटिलता का परिचय देता है। यानी, यदि आपके पास मशीन पर एक से अधिक साइट / डोमेन होस्ट हैं। यह एक LAMP स्टैक की तरह नहीं है, जहाँ आपके पास एक ही सर्वर (पोर्ट 80, कम से कम) पर चलने वाले आधा दर्जन विभिन्न डोमेन के लिए एक दर्जन PHP अनुप्रयोग हो सकते हैं। नोड के लिए चौखटे हैं जो संभवत: इसे संभव बनाते हैं, लेकिन परंपरागत जटिलताएं जोड़ते हैं जो आपको बस जरूरत नहीं है यदि आप पारंपरिक वेब प्लेटफॉर्म से चिपके हुए हैं। (आप, निश्चित रूप से, नोड के सामने एक वेब सर्वर डालकर भी परदे के पीछे सेट कर सकते हैं, लेकिन उस तरह के नोड का उपयोग करने के लाभ को हरा देते हैं)।

imo, नोड एक पारंपरिक वेब सर्वर के साथ संयोजन के रूप में काम करने के लिए एकदम सही है। जिस तरह से मेरे पास अभी चीजें हैं, वह अपाचे के माध्यम से स्थिर एचटीएमएल / जेएस / छवियों की सेवा करने के लिए है, और नोड एप्लिकेशन को लंबे समय के मतदान से 'वास्तविक समय' डेटा की जरूरतों को संभालना है।

Comments

कई मेजबानों को स्थापित करने में +1 आसानी से उपयोग निश्चित रूप से विचार के लायक है।

— 16:13 बजे पॉल डी'अवेट

यह अपाचे httpd या nginx सर्वर के पीछे नोड एप्लिकेशन डालने के लिए बहुत आसान है और नोड पोर्ट (या पोर्ट) के लिए उस ऐप के यूआरआई हस्ताक्षर के साथ मार्ग अनुरोध करता है।

— टॉमजॉन

+1 - सर्वर-साइड प्रॉक्सी ('पारंपरिक वेब सर्वर के साथ संयोजन के रूप में' नोड की धारणा) ने इस साल की शुरुआत में कर्षण प्राप्त किया और यह देखने लायक है - खासकर यदि आपके पास प्रबंधन करने के लिए एक बड़ा पारंपरिक आर्किटेक्चर है। यह एक डिजाइन पैटर्न है जो उद्यम के लिए समझ में आता है। लेकिन, यह ध्यान देने योग्य है - यह AVOID Node.js के लिए नहीं बल्कि विशिष्ट उद्देश्य के लिए इसका उपयोग करने का एक कारण है।

— जैक स्टोन

-1 - नोड के सामने एक प्रॉक्सी (जैसे नेगनेक्स) रखना एक सही उपयोग का मामला है और वास्तव में कुछ मामलों में एक से अधिक नहीं होने की तुलना में बहुत अधिक सुरक्षित और प्रदर्शन योग्य है। यह नोड के किसी भी लाभ को पराजित नहीं करता है। मैं अपने नोड ऐप्स को यूनिक्स डोमेन सॉकेट्स पर चलाने के लिए प्रेरित करता हूं, और फिर एक गेटकीपर के रूप में nginx कार्य करता हूं।

— स्कॉट एंडरसन

Answer 3

नोड के बारे में सेकंड के विचार रखने का एक अच्छा कारण तकनीकी नहीं है - यह महान और आश्चर्यजनक है कि यह क्या करता है।

वे व्यवसाय और विशेष रूप से मानव पूंजी हैं, अर्थात प्रोग्रामर जो इसे जानते हैं, उनकी लागत और उनकी उपलब्धता कितनी है। यह सीखना मुश्किल नहीं है, लेकिन किसी भी नई तकनीक के साथ यह जानने वालों की संख्या अच्छी तरह से है (या चाहते हैं) श्रमिकों के बड़े पूल का एक उप है।

Comments

इसलिए आपको लगता है कि अधिक पारंपरिक ऐप स्टैक के स्थान पर नोड का उपयोग करने के खिलाफ वास्तव में बहुत कुछ नहीं है; वास्तविक दुनिया की चिंताओं के साथ मुद्दे अधिक हैं?

— पॉल डी'अवेस्ट

+1। मानव संसाधन - और जावास्क्रिप्ट सीखने के लिए कुछ की अनिच्छा - एक असुविधाजनक सच्चाई है। यह उत्तर यह अच्छी तरह से बताता है। लेकिन, नोड से बचना "क्योंकि लोग हेट जावास्क्रिप्ट" तार्किक प्रगति भी नहीं है। यदि हम तकनीकी रूप से हर नवाचार को टालेंगे - तो हमें किसी और से घृणा कैसे होगी? कहीं भी नहीं। नोड के साथ चुनौती ए) नई प्रतिभा प्राप्त करना है, या बी) नई प्रतिभाओं में पारंपरिक प्रतिभा को शिक्षित करना। उस बिंदु पर - हम खान अकादमी की स्थापना में जॉन रेजिग की दूरदर्शिता के बाद से हर जगह जावास्क्रिप्ट कोड स्कूलों को पॉप-अप कर रहे हैं। संक्षेप में, यह चीजों का तरीका है। +1। अच्छी तरह से कहा हुआ।

— जैक स्टोन

Answer 4

यह एक बहुत अच्छा सवाल है, जिसे हमें कला की स्थिति को आगे बढ़ाने के लिए पूछना चाहिए।

मैं यह जानने के लिए बहुत उत्सुक था (जैसे पॉल डी'अवेड) जहां नोड.जेएस की सीमाएं मौजूद हैं। अफसोस की बात है, कई जवाब व्यक्तिपरक पूर्वाग्रह और अस्थायी रूप से प्रासंगिक तर्क से भरे हुए हैं।

मैंने अपने आप से पूछा: क्या हम सब्‍जीक्टिव बायस का लाभ उठा सकते हैं और इस प्रश्‍न को हल करने के लिए क्‍या कहेंगे?

शेष बिंदु निम्न प्रतीत होते हैं:

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

2. NodeJS एक प्रॉक्सी सर्वर के रूप में। पूर्व-चर्चा का एक बुद्धिमान सुझाव, यह समीक्षा और विचार के लायक है। यह फ्रंट-एंड इंटरफ़ेस प्रॉक्सी डिज़ाइन पैटर्न के रूप में मौजूदा प्रौद्योगिकियों के साथ सहसंबंध में नोड का उपयोग करने की धारणा है। लेकिन यह भी, नोड का उपयोग करके AVOID के लिए एक कारण नहीं है, बल्कि एक पूर्ण प्रतिस्थापन के रूप में इसका उपयोग करने से बचने का एक कारण है। इसके बजाय एक corollary दृष्टिकोण के लिए चयन।

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

4. मानव संसाधन। इस पृष्ठ पर JS का उपयोग करके AVOID के लिए यह सबसे अच्छा कारण है, और मेरी विनम्र राय में यह एक निरा और असुविधाजनक सत्य है। यह सवाल है: क्या आपकी कंपनी के पास पूरे जीवन चक्र के माध्यम से परियोजना को देखने के लिए सही प्रतिभाशाली पेशेवर हैं? यदि नहीं, तो कोई सवाल नहीं है कि आपको NodeJS से बचने की आवश्यकता है। या इसके बजाय ए) सही प्रतिभा का पता लगाने, या बी) मौजूदा प्रतिभा को शिक्षित करना।

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

अंत में, सही उत्तर हो सकता है - AVOID NodeJS के लिए कोई अच्छे कारण नहीं हैं । शायद यही कारण है कि यह तेजी से विकास, गोद लेने और योगदान का अनुभव कर रहा है। लेकिन हम सभी के लिए शायद यहाँ उत्तर का मूल्यांकन, अनुसंधान, और NodeJS को बेहतर ढंग से समझने के लिए जारी है - और ठोस अवतरणों की तलाश करें। यह समझने के लिए खुले रहने की खोज में कि Node.JS अपरिपक्व है - हम ठीक उसी जगह पाते हैं जहां हमें इसे बेहतर बनाने की आवश्यकता है। और वह एक आशीर्वाद है।

अच्छा प्रश्न। मैं किसी के लिए उत्सुक हूं कि वह NodeJS से बचने के लिए एक बेहतर कारण लाए।

Answer 5

क्या गैर- realtime अनुप्रयोगों के लिए X पर नोड का उपयोग करने का कोई लाभ है:

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

गैर-रीयलटाइम अनुप्रयोगों के लिए एक्स ओवर नोड का उपयोग करने का लाभ:

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

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

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

Comments

-1। मैं मानता हूं कि यह उत्तर 2015 में मान्य नहीं होगा। लेकिन यह भी नीचता का कारण है। संक्षेप में- आज के निर्णय कल के निर्णय हैं। यह ऊपर 8 बुलेट बिंदुओं को शून्य करता है - अगर हम देख सकते हैं कि वे केवल अस्थायी रूप से प्रासंगिक हैं। 1) स्केलिंग - वॉलमार्ट मोबाइल तराजू, नोड से बचने का कारण नहीं। 2) आइसोमॉर्फिक जेएस कोई मजाक नहीं है। कारण नहीं है। 3) सर्वर सेक्सीनेस? अधिकांश उपयोगकर्ता केवल ux जानते हैं। 4) सर्वश्रेष्ठ अभ्यास व्यक्तिपरक है, 5) हॉट नहीं है? सहज 6) आसान? -subjective। 7) स्थिरता एक अस्थायी रूप से प्रासंगिक बिंदु है। 8) एनपीएम ने 2014 में मावेन को पारित करने का अनुमान लगाया। यहां कोई कारण नहीं है। Downvote।

— जैक स्टोन

Answer 6

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

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

Comments

-1 - विशेषण बिंदु। "पसंदीदा सिंटैक्स", "डॉक्यूमेंटेशन उतना अच्छा नहीं", "ऑब्सेसिव कॉलबैक", और "पहले से ही मेरी भाषा में" - सभी अस्पष्ट और व्यक्तिपरक हैं। हमने ये पहले सुना है। वे निर्वस्त्र हैं। यहाँ Node.JS से बचने का कोई कारण नहीं। Downvote।

— जैक स्टोन

सभी बिंदु मेरी व्यक्तिगत पसंद हैं जिन्हें मैंने खुले तौर पर कहा था। इसके अलावा, आप व्यक्तिगत प्राथमिकता को कैसे डिबेक करते हैं?

— डेविड सेर्गेई

Answer 7

HTTP स्टेटलेस है, इसलिए वास्तव में एक गैर-रियलटाइम वेब ऐप जैसी कोई चीज नहीं है और इसलिए कोई कारण नहीं कि आप हर चीज के लिए नोड का उपयोग नहीं कर सकते।

उस ने कहा, नोड एक विशेष प्रकार के एप्लिकेशन आर्किटेक्चर के लिए बेहतर अनुकूल है। PHP html फाइल है जिसमें थोड़ा सा कोड होता है। नोड कोड वैकल्पिक रूप से HTML का एक सा है।

इसका मतलब यह है कि यदि आपका ऐप बिना किसी क्लाइंट साइड स्क्रिप्ट के मानक HTML फॉर्म है, तो PHP आसान हो जाएगी। नोड में टेम्प्लेटिंग टूल नहीं हैं, लेकिन जाहिर है कि यह पीएचपी की तरह परिपक्व नहीं है।

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

Comments

HTTP को स्टेटलेस और रियलटाइम-ईश के बारे में लिया गया बिंदु; हालाँकि, मैं वास्तविक समय की विशिष्ट परिभाषा के बारे में व्यावहारिक चिंताओं में अधिक दिलचस्पी रखता हूं: कम वजन वाले अनुरोधों की उच्च मात्रा। कभी-कभी JSON की तीन या चार पंक्तियों को उगलने के लिए एक नए PHP उदाहरण को स्पिन करना थोड़ा कठिन लगता है। क्या मैं सही हूं, या क्या मैं सिर्फ तोता सिंड्रोम से पीड़ित हूं?

— 20 अप्रैल को पॉल डी'अवेट

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

— टॉम क्लार्कसन 23

मुझे पता है कि मुझे कुछ समय के लिए एक दुभाषिया को लोड करना होगा, लेकिन मुझे हर समय (कम-सीपीयू ऐप्स के लिए) निश्चित रूप से व्याख्या करने वाले स्पिन के बजाय Node.js में चलने वाले दुभाषिया के एक उदाहरण होने का एक लाभ दिखाई देता है। PHP में, हर अनुरोध के साथ ऊपर और समाप्त करें।

— पॉल डी'अवेस्ट

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

— टॉम क्लार्कसन