एन-टियर डेवलपमेंट में कोड-बेस के बराबर राशि क्यों है, यदि अधिक नहीं, तो जावास्क्रिप्ट कोड अभी?

Question

मैं एक लंबे समय से वेब प्रोग्रामिंग कर रहा हूं, और कहीं न कहीं, मैंने इस बात पर ध्यान दिया कि हम आज क्या कर रहे हैं (या हम इस तरह से चीजें करने के लिए कैसे आए)?

मैंने बुनियादी एएसपी वेब विकास के साथ शुरुआत की, और पृष्ठ पर बहुत जल्दी, प्रदर्शन और व्यापार तर्क मिलाया गया। क्लाइंट-साइड डेवलपमेंट में विभिन्न बेतहाशा (VBScript, जावास्क्रिप्ट के विभिन्न स्वाद), और सर्वर-साइड सत्यापन के बारे में हमारे पास बहुत चेतावनी थी (और इसलिए मैं क्लाइंट-साइड लॉजिक से दूर रहा)।

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

मैं फिर ASP.NET बैंड वैगन पर कूद गया और उनके MVC दृष्टिकोण का उपयोग करना शुरू कर दिया। मुझे यह भी एहसास हुआ कि जावा उद्यम प्रणालियों की एक हाथीदांत टॉवर भाषा प्रतीत होती है, और उनके एमवीसी दृष्टिकोण की भी कोशिश की। बाद में, ASP.NET ने इस MVVM डिज़ाइन पैटर्न को विकसित किया, और जावा (ठीक है, J2EE या JEE) ने भी संघर्ष किया और अपने MVC2 दृष्टिकोण के साथ बाहर आया।

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

सर्वर से क्लाइंट-साइड डेवलपमेंट के लिए यह आंदोलन क्यों हुआ है? मैंने अपनी JEE परियोजनाओं में से एक की सरल रेखा गणना की, और जावा की तुलना में जावास्क्रिप्ट में कोड की अधिक पंक्तियाँ हैं (तीसरे पक्ष के पुस्तकालयों को छोड़कर)। मुझे लगता है कि जावा या सी # जैसी प्रोग्रामिंग भाषाओं का उपयोग करने वाले अधिकांश बैकएंड विकास केवल एक आरईएस-जैसे इंटरफ़ेस का उत्पादन करने के लिए है, और यह कि डिस्प्ले, विज़ुअलाइज़ेशन, डेटा इनपुट / आउटपुट, उपयोगकर्ता इंटरैक्शन, आदि ... के सभी कठिन प्रयासों को संबोधित किया जा रहा है। कोणीय, बैकबोन, एम्बर, नॉकआउट आदि जैसे क्लाइंट-साइड ढांचे के माध्यम से ...

पूर्व jQuery के युग के दौरान, मैंने बहुत सारे आरेखों को देखा जहां n-स्तरीय विकास में MVC में M, V और C के बीच एक स्पष्ट, वैचारिक रेखा थी। पोस्ट- jQuery, ये रेखाएँ कहाँ खींची गई हैं? ऐसा लगता है कि एमवीसी और एमवीवीएम जावास्क्रिप्ट कोड, क्लाइंट-साइड में ठीक हैं।

जो मैं जानना चाहता हूं, हमने ऐसा परिवर्तन क्यों किया (सर्वर-साइड प्रोग्रामिंग से लेकर क्लाइंट-साइड तक, संकलित भाषाओं के अनुकूल भाषाओं से लेकर स्क्रिप्टिंग भाषाओं तक, जरूरी से कार्यात्मक प्रोग्रामिंग तक, ये सभी एक साथ हुए हैं। ) और इस संक्रमण / बदलाव से क्या समस्याएं हल हुईं?

Comments

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

— रवांग

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

— जोशुआ टेलर

मैं एक देशी अंग्रेजी वक्ता नहीं हूं, लेकिन शायद शीर्षक को स्पष्ट किया जा सकता है?

— बिगस्टोन्स

जावास्क्रिप्ट में एक प्रगति है? भाषा अभी भी ES5 (11/2014) है। अधिकांश प्रगति लगभग जावास्क्रिप्ट का उपयोग न करने की कोशिश करने के आसपास लगती है: डार्ट, टाइपस्क्रिप्ट, एटस्क्रिप्ट आदि

— Den

क्योंकि वितरित / मोबाइल उपकरणों में अब पर्याप्त सीपीयू शक्ति है कि वे स्थानीय रूप से वे काम कर सकते हैं जिनके लिए एक बड़े केंद्रीय सर्वर की आवश्यकता होती है।

— किलियन फोथ

Answer 1

सर्वर और क्लाइंट के बीच कंप्यूटिंग लोड को स्थानांतरित करना एक चक्रीय घटना है, और ऐसा कुछ समय से हो रहा है।

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

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

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

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

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

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

Comments

As the computers became increasingly more powerful, divisions of labor became possible [...] you have lots of choices about where you can execute your processing power, both on the client and on the server.- मैं कहता हूं कि ये दो बिंदु एक साथ सर्वर और क्लाइंट के बीच संतुलन बनाए रखने के लिए एक बड़ा मामला बनाते हैं: वे प्रत्येक एक विशेष कार्य के लिए अनुकूल हैं, और उन कार्यों को अब अच्छी तरह से परिभाषित और आसानी से लागू किया जाता है।

— जेस टेलफ़ोर्ड

Answer 2

आप दो बहुत अलग अवधारणाओं का मिश्रण कर रहे हैं:

1. अलग प्रस्तुति और व्यावसायिक तर्क (MVC) => रखरखाव में वृद्धि
2. निष्पादन को एक नोड => दक्षता में वृद्धि करना

उन दिनों में क्लाइंट / सर्वर कंप्यूटिंग अक्सर पहले की तुलना में भ्रमित था क्योंकि क्लाइंट आमतौर पर सर्वर की तुलना में बहुत अधिक कंप्यूटिंग शक्ति प्रदान नहीं करते थे। इसलिए "लाइट" व्यू प्रोसेसिंग (V) को क्लाइंट्स के पास रखते हुए "हेवी" बिजनेस लॉजिक कंपटीशन (M) को सर्वर पर ले जाना स्वाभाविक था। बदले में आपको दोनों के बीच अनुवाद करने के लिए किसी प्रकार के मध्यस्थ (C) को लागू करना होगा।

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

• क्लाइंट लेटेंसी बनाम जटिलता: सर्वर-साइड प्रोसेसिंग सिस्टम को सरल रखता है क्योंकि किसी भी कोड को क्लाइंट को तैनात / डाउनलोड करने की आवश्यकता नहीं होती है, हालांकि यह कम्प्यूटेशन के दौरान क्लाइंट-साइड लेटेंसी की लागत पर आता है।

• जटिलता बनाम सर्वर लोड: क्लाइंट-साइड कंप्यूटिंग सिस्टम जटिलता को बढ़ा सकता है लेकिन यह सर्वर लोड को कम करने में भी मदद कर सकता है।

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

यह कई ट्रेड-ऑफ की गैर-विस्तृत सूची है।

Answer 3

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

अधिकांश बैकएंड डेवलपमेंट का उपयोग प्रोग्रामिंग लैंग्वेज जैसे कि जावा या C # में बस एक REST जैसे इंटरफेस का निर्माण करना है, और यह कि डिस्प्ले, विज़ुअलाइज़ेशन, डेटा इनपुट / आउटपुट, उपयोगकर्ता इंटरैक्शन, आदि के सभी कठिन प्रयास क्लाइंट- के माध्यम से संबोधित किए जा रहे हैं। कोणीय, बैकबोन, एम्बर, नॉकआउट आदि जैसे साइड फ्रेमवर्क ...

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

Answer 4

आज, अधिकांश परियोजनाओं में जो मैं चालू हूं, मुझे पता चला कि जावास्क्रिप्ट फ्रेमवर्क और क्लाइंट-साइड विकास वह जगह है जहां सभी रोमांचक और अभिनव प्रगति की जा रही है।

सर्वर से क्लाइंट-साइड डेवलपमेंट के लिए यह आंदोलन क्यों हुआ है?

यहाँ वास्तव में दो प्रश्न हैं:

1. क्‍यों क्लाइंट-साइड प्रोग्रामिंग जहां प्रगति हो रही है?
2. सर्वर के बजाय क्लाइंट पर चलाने के लिए एप्लिकेशन क्यों लिखे गए हैं?

दोनों वास्तव में अलग हैं।

क्‍यों क्लाइंट-साइड प्रोग्रामिंग जहां प्रगति हो रही है?

क्योंकि पिछले तीन वर्षों में रनटाइम, पर्यावरण और पारिस्थितिक तंत्र काफी हद तक परिपक्व हो गए हैं, और इसने नए नए रास्ते खोले हैं, जिनका नवोन्मेषकों ने शोषण करने के लिए इंतजार किया है।

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

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

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

सर्वर के बजाय क्लाइंट पर चलाने के लिए एप्लिकेशन क्यों लिखे गए हैं?

कई अनुमानित कारण हैं, लेकिन हाल के वर्षों में सबसे अलग स्मार्टफोन का उदय है।

स्मार्टफोन मध्यम-शक्तिशाली कंप्यूटिंग को सस्ता, सर्वव्यापी और उपयोगी बनाते हैं। वे ग्रह भर में अरबों लोगों के स्वामित्व में हैं, और अनिवार्य रूप से उभरती अर्थव्यवस्थाओं के मध्यम वर्गों के लिए कंप्यूटिंग लाए हैं। लेकिन मोबाइल नेटवर्क भौगोलिक, इंजीनियरिंग और राजनीतिक हार्ड समस्याओं से सुस्त, थके हुए और विवश हैं। इस माहौल में, स्थानीय स्तर पर स्टेट को स्टोर करना और डेटा को अनिच्छा से और स्टेटलेस ऑपरेशंस में पैच करना अपरिहार्य है।

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

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

इसे बहुत व्यापक शब्दों में कहें: क्लाइंट-साइड विकास मध्य-शक्ति व्यक्तिगत कंप्यूटिंग की कम लागत का शोषण करता है और उच्च-शक्ति केंद्रीकृत कंप्यूटिंग की उच्च लागत से बचा जाता है।

Answer 5

आपने कई सवाल पूछे, जिनमें से कुछ के जवाब पहले से ही अच्छे हैं। कुछ ने अभी तक अपने जवाब नहीं दिए हैं:

जो मैं जानना चाहता हूं, हमने इस तरह का एक संक्रमण क्यों किया (सर्वर-साइड प्रोग्रामिंग के जोर से क्लाइंट-साइड तक, ... ये सभी एक साथ हुए लगते हैं) और इस संक्रमण / बदलाव से क्या समस्याएं हल हुईं?

रॉबर्ट हार्वे ने एक उत्कृष्ट उत्तर दिया।

... संकलित भाषाओं के पक्ष से लेकर स्क्रिप्टिंग भाषाओं तक,

संकलित भाषाओं की तुलना में स्क्रिप्टिंग भाषाएँ कई फायदे ( भी ) प्रदान करती हैं, जैसे:

• सीखना और उपयोग करना आसान है
• संकलित समय (तेजी से विकास) को खत्म करना
• अधिक सुविधाएँ प्रदान करें (उच्च-अंत अनुप्रयोग नियंत्रण)
• रनिंग कोड में त्वरित बदलाव की अनुमति दें
• आदि।

... अनिवार्य प्रोग्रामिंग से,

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

Comments

अगर डाउन-वोटर मेरे जवाब के कौन से हिस्से (ओं) को कहने की हिम्मत रखता है तो उसे अच्छा नहीं लगेगा?

— फ्यूहरमैनटर

मैं यह नहीं बता सकता कि पिछले दो मतदाताओं ने ऐसा क्यों किया, लेकिन मेरा कारण यह है कि यह पहले के उत्तरों में से एक की तरह एक टिप्पणी की तरह दिखता है , बल्कि पूछे गए प्रश्न से संबंधित है (देखें उत्तर कैसे दें )

— gnat

@gnat मैं प्रतिक्रिया की सराहना करता हूं। मैंने प्रश्न के विभिन्न भागों (अर्थात संकलित लिपि और अनिवार्य बनाम कार्यात्मक) का हवाला दिया, जिनका कहीं और जवाब नहीं दिया गया था। मैं इस पर 3 upvotes मिल गया है, तो मैं देख सकता हूँ कि यह एक मिश्रित प्रतिक्रिया है।

— 23