इस पेज का अनुवाद Cloud Translation API से किया गया है.

JavaScript लाइब्रेरी या फ़्रेमवर्क चुनना

उमर हांसा

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

JavaScript लाइब्रेरी और फ़्रेमवर्क क्या होते हैं

JavaScript लाइब्रेरी क्या है? सबसे आसान रूप में, JavaScript लाइब्रेरी पहले से लिखा हुआ कोड होता है. इसे किसी खास टास्क को पूरा करने के लिए, अपने प्रोजेक्ट के कोड में कॉल किया जा सकता है.

इस पोस्ट में, मुख्य रूप से "लाइब्रेरी" के बारे में बताया गया है. हालांकि, यहां बताई गई कई बातचीत, फ़्रेमवर्क के लिए भी लागू होती हैं. बुनियादी तौर पर, दोनों के बीच के अंतर को इस तरह से समझा जा सकता है:

लाइब्रेरी के लिए, आपका ऐप्लिकेशन कोड, लाइब्रेरी कोड को कॉल करता है.
फ़्रेमवर्क के लिए, आपके ऐप्लिकेशन कोड को फ़्रेमवर्क कॉल करता है.

नीचे दिए गए व्यावहारिक उदाहरणों की मदद से अंतर समझा जा सकता है.

JavaScript लाइब्रेरी को कॉल करने का उदाहरण

JavaScript लाइब्रेरी कोई खास टास्क करती है और उसके बाद आपके ऐप्लिकेशन को कंट्रोल देती है. लाइब्रेरी का इस्तेमाल करने पर, ऐप्लिकेशन फ़्लो को कंट्रोल किया जा सकता है और यह भी चुना जा सकता है कि लाइब्रेरी को कब कॉल करना है.

नीचे दिए गए उदाहरण में, ऐप्लिकेशन कोड lodash लाइब्रेरी से एक तरीका इंपोर्ट करता है. फ़ंक्शन पूरा होने के बाद, कंट्रोल आपके ऐप्लिकेशन पर वापस आ जाता है.

import capitalize from 'lodash.capitalize';
capitalize('hello'); // Hello

lodash.capitalize वाला तरीका लागू होने पर, यह पहले से लिखे गए JavaScript कोड को कॉल करता है, जो स्ट्रिंग के पहले वर्ण को कैपिटल में रखता है.

JavaScript फ़्रेमवर्क के इस्तेमाल का उदाहरण

JavaScript फ़्रेमवर्क पहले से तय किया गया एक कोड टेंप्लेट होता है. इसकी मदद से ऐप्लिकेशन का व्यवहार तैयार किया जाता है. इसका मतलब है कि जब किसी फ़्रेमवर्क का इस्तेमाल किया जाता है, तो ऐप्लिकेशन फ़्लो को कंट्रोल करता है. फ़्रेमवर्क का इस्तेमाल करने के लिए, पसंद के मुताबिक बनाया गया ऐप्लिकेशन कोड लिखा जाता है. इसके बाद, फ़्रेमवर्क आपके ऐप्लिकेशन कोड को कॉल करता है.

इस उदाहरण में, एक ऐसा कोड स्निपेट दिखाया गया है जो Preact JavaScript फ़्रेमवर्क का इस्तेमाल करता है:

import { createElement } from 'preact';

export default function App() {
  return (
    <p class="big">Hello World!</p>
  )
}

उदाहरण में, ध्यान दें कि आपके लिखे गए कोड पर फ़्रेमवर्क काफ़ी ज़्यादा कंट्रोल होता है और कुछ मामलों में, फ़्रेमवर्क यह भी कंट्रोल करता है कि आपके कोड को कब एक्ज़ीक्यूट करना है.

लाइब्रेरी का इस्तेमाल क्यों करना चाहिए?

JavaScript लाइब्रेरी का इस्तेमाल करने से, बेवजह कोड के दोहराव से बचने में मदद मिल सकती है. लाइब्रेरी, तारीख में हेर-फेर या फ़ाइनेंशियल कैलकुलेशन जैसे मुश्किल लॉजिक को दूर कर सकती हैं. लाइब्रेरी का इस्तेमाल करके, अपने शुरुआती प्रॉडक्ट के बारे में बताया जा सकता है. आपको पूरे कोड को शुरुआत से लिखने की ज़रूरत नहीं होती. इसमें समय लग सकता है.

कुछ क्लाइंट-साइड JavaScript लाइब्रेरी की मदद से, वेब प्लैटफ़ॉर्म की अनोखी गड़बड़ियों को दूर किया जा सकता है. लाइब्रेरी का इस्तेमाल एक लर्निंग टूल के तौर पर भी किया जा सकता है. उदाहरण के लिए, अगर आपको ऐनिमेशन ईज़िंग के फ़ंक्शन के बारे में कुछ भी नहीं पता है, तो लाइब्रेरी का सोर्स कोड आपको बता सकता है कि इस तरह की ईज़िंग कैसे काम करती हैं.

कुछ लाइब्रेरी का समर्थन बड़ी कंपनियां करती हैं, जो लाइब्रेरी को अप-टू-डेट और सुरक्षित रखने में अपना समय और पैसा खर्च करती हैं. कई लाइब्रेरी के साथ अलग से दस्तावेज़ दिए जाते हैं, जिनसे आपको और आपकी टीम को लाइब्रेरी के इस्तेमाल से जुड़ी जानकारी तुरंत मिल जाती है.

आखिरकार, JavaScript लाइब्रेरी का इस्तेमाल करने से आपका समय बचता है.

आपको लाइब्रेरी के इस्तेमाल पर क्यों ध्यान देना चाहिए?

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

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

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

कुछ नॉन क्लाइंट-साइड JavaScript एनवायरमेंट होते हैं, जैसे कि सर्वर पर (क्लाउड एनवायरमेंट में चलाया जाता है) या Raspबेरी Pi पर, जहां आपको लाइब्रेरी और फ़्रेमवर्क की जांच करने के लिए तय शर्तों में बदलाव करना पड़ सकता है.

परफ़ॉर्मेंस

क्लाइंट-साइड वेब ऐप्लिकेशन पर JavaScript लाइब्रेरी की परफ़ॉर्मेंस को अनदेखा नहीं किया जाना चाहिए. JavaScript की बड़ी लाइब्रेरी से आपके पेज की लोडिंग परफ़ॉर्मेंस में रुकावट आ सकती है. याद रखें, मिलीसेकंड से लाखों कमाए जाते हैं.

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

JavaScript लाइब्रेरी जितनी बड़ी होगी, आपके उपयोगकर्ताओं पर उतना ही ज़्यादा असर पड़ेगा.

JavaScript लाइब्रेरी या फ़्रेमवर्क का आकलन करते समय या उसका इस्तेमाल करते समय, परफ़ॉर्मेंस को बेहतर बनाने के लिए इन सुझावों को ध्यान में रखें:

JavaScript की बड़ी लाइब्रेरी को देखते हुए, कोई छोटा विकल्प इस्तेमाल करें. उदाहरण के लिए, date-fns कुछ दूसरे विकल्पों की तुलना में ज़्यादा सही साइज़ में कई सुविधाएं देता है.
पिछले तारीख-fns उदाहरण से, सिर्फ़ उन फ़ंक्शन को इंपोर्ट करें जिनकी आपको ज़रूरत है, जैसे कि: import { format } from 'date-fns'. इस तरीके को ट्री शेकिंग के साथ जोड़ना न भूलें. इससे, कम से कम JavaScript पेलोड बनाया जा सकेगा और आपके उपयोगकर्ताओं को भेजा जा सकेगा.
किसी खास JavaScript लाइब्रेरी का इस्तेमाल करने से परफ़ॉर्मेंस पर पड़ने वाले असर का पता लगाने के लिए, Lighthouse जैसे परफ़ॉर्मेंस टेस्टिंग टूल का इस्तेमाल करें. अगर कोई लाइब्रेरी आपके पेज लोड होने में एक सेकंड की देरी करती है (टेस्टिंग के दौरान अपने नेटवर्क और सीपीयू को थ्रॉटल करना न भूलें), तो आपको अपनी पसंद की लाइब्रेरी का फिर से आकलन करना पड़ सकता है. पेज लोड की जांच करने के अलावा, ऐसे किसी भी वेब पेज के व्यवहार की प्रोफ़ाइल पक्का करें जो विचाराधीन लाइब्रेरी से कोड शुरू करता है—पेज लोड परफ़ॉर्मेंस से पूरी जानकारी नहीं मिलती.
अगर लाइब्रेरी का लेखक अपनी टिप्पणियों को स्वीकार करता है, तो परफ़ॉर्मेंस की निगरानी, सुझाव, और प्रोजेक्ट में अपना योगदान भी सबमिट करें. ओपन सोर्स कम्यूनिटी यहां दिखती है! अगर आपको योगदान करना है, तो पहले आपको नौकरी देने वाली कंपनी से संपर्क करना होगा.
किसी लाइब्रेरी में अचानक होने वाले बड़े अपडेट देखने के लिए, अपने-आप पूरे होने वाले बंडल ट्रैकिंग टूल का इस्तेमाल करें, जैसे कि bundlesize. आम तौर पर, समय के साथ JavaScript लाइब्रेरी का विकास होता है. कई सुविधाएं जोड़ी जा सकती हैं, गड़बड़ियां ठीक की जा सकती हैं, एज केस वगैरह जोड़े जा सकते हैं. इन्हें लाइब्रेरी के साइज़ में जोड़ा जा सकता है. जब आप या आपकी टीम लाइब्रेरी का इस्तेमाल करने की सहमति दे देती है, तो लाइब्रेरी को अपडेट करने में कम समस्या हो सकती है. साथ ही, इस तरह के सवाल खड़े हो सकते हैं. ऐसी स्थिति में ऑटोमेशन पर भरोसा करना फ़ायदेमंद होता है.
लाइब्रेरी के लिए अपनी ज़रूरी शर्तों को देखें और आकलन करें कि वेब प्लैटफ़ॉर्म में भी वही सुविधाएं हैं या नहीं. उदाहरण के लिए, वेब प्लैटफ़ॉर्म पहले से ही कलर पिकर उपलब्ध कराता है. इससे उन सुविधाओं को लागू करने के लिए, तीसरे पक्ष की JavaScript लाइब्रेरी का इस्तेमाल करने की ज़रूरत नहीं होती.

सुरक्षा

तीसरे पक्ष के मॉड्यूल का इस्तेमाल करने पर, सुरक्षा से जुड़े कुछ जोखिम हो सकते हैं. आपके वेब ऐप्लिकेशन कोडबेस में नुकसान पहुंचाने वाला पैकेज आपकी डेवलपमेंट टीम और आपके उपयोगकर्ताओं, दोनों की सुरक्षा को जोखिम में डाल सकता है.

NPM नेटवर्क में पब्लिश की गई किसी लाइब्रेरी का इस्तेमाल करें. ऐसा पैकेज वैध हो सकता है. हालांकि, समय के साथ पैकेज के साथ छेड़छाड़ हो सकती है.

तीसरे पक्ष के कोड का इस्तेमाल या उसका आकलन करते समय, सुरक्षा से जुड़े कुछ सुझाव यहां दिए गए हैं:

अगर GitHub का इस्तेमाल किया जाता है, तो कोड की सुरक्षा से जुड़ी ऑफ़र, जैसे कि Dependabot को देखें. इसके अलावा, आपके कोड में जोखिम की आशंकाओं का पता लगाने के लिए, snyk.io जैसी वैकल्पिक सेवाओं का इस्तेमाल किया जा सकता है.
कोड ऑडिट करने वाली सेवाओं का इस्तेमाल करें. इंजीनियरों की ऐसी टीम जो तीसरे पक्ष के जिस कोड का इस्तेमाल कर रही है उसे मैन्युअल तौर पर ऑडिट कर सकती है.
इसका आकलन करें कि आपको किसी खास वर्शन की डिपेंडेंसी लॉक करनी चाहिए या अपने वर्शन कंट्रोल के अंदर ही तीसरे पक्ष के कोड का इस्तेमाल करना चाहिए. इससे आपको किसी एक खास वर्शन पर डिपेंडेंसी लॉक करने में मदद मिल सकती है. इस वर्शन को सुरक्षित माना जाता है. दिलचस्प बात यह है कि इसका असर आपके खाते की सुरक्षा पर भी पड़ सकता है, क्योंकि हो सकता है कि आप लाइब्रेरी के ज़रूरी अपडेट न देख पाएं.
अगर प्रोजेक्ट का होम पेज या GitHub पेज मौजूद है, तो उसे स्कैन करें. रिसर्च करें कि सुरक्षा से जुड़ी समस्याएं मौजूद हैं या नहीं. साथ ही, यह भी रिसर्च करें कि सुरक्षा से जुड़ी पिछली समस्याओं को उचित समयसीमा में हल किया गया था या नहीं.
किसी तीसरे पक्ष के कोड का इस्तेमाल करने वाले तीसरे पक्ष के कोड में, उस लाइब्रेरी की तुलना में ज़्यादा जोखिम हो सकता है जिसमें शून्य डिपेंडेंसी होती हैं. इस जोखिम को ध्यान में रखें.

सुलभता

आप सोच रहे होंगे कि सॉफ़्टवेयर लाइब्रेरी वेब सुलभता से कैसे जुड़ी हैं. सॉफ़्टवेयर लाइब्रेरी का इस्तेमाल अलग-अलग माहौल में किया जा सकता है. हालांकि, क्लाइंट-साइड JavaScript पर आधारित लाइब्रेरी के मामले में, वेब सुलभता बहुत ज़रूरी है.

क्लाइंट-साइड JavaScript पर आधारित लाइब्रेरी (या उस मामले के लिए फ़्रेमवर्क) की मदद से, आपकी वेबसाइट की सुलभता सुविधाओं में बढ़ोतरी या कमी हो सकती है. किसी पेज में इमेज स्लाइडर जोड़ने वाली तीसरे पक्ष की JavaScript लाइब्रेरी का इस्तेमाल करें. अगर इमेज स्लाइडर वेब सुलभता के बारे में नहीं बताता है, तो वेब डेवलपर के तौर पर आप ऐसी अहम सुविधा को नज़रअंदाज़ कर सकते हैं और एक ऐसा प्रॉडक्ट रिलीज़ कर सकते हैं जिसमें स्लाइडर, कीबोर्ड नेविगेट करने लायक होने जैसी ज़रूरी सुविधाएं नहीं होती हैं!

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

इस तरह की सुलभता ज़रूरतों को पूरा करने के लिए, वेब डेवलपर यानी वेब डेवलपर को कुछ स्तर की भागीदारी की ज़रूरत हो सकती है. उदाहरण के लिए:

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

सम्मेलन

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

अगर कोई लाइब्रेरी, कोडिंग के सामान्य तरीकों (उदाहरण के लिए, सामान्य स्टाइल गाइड) का पालन नहीं करती है, तो तुरंत सुधार करने के लिए कुछ नहीं किया जा सकता. हालांकि, आपके पास अब भी कुछ विकल्प हैं:

पक्का करें कि लाइब्रेरी के सोर्स कोड और आपको, लाइब्रेरी के उपयोगकर्ता के तौर पर ऐक्सेस किए गए एपीआई में अंतर हो. वैसे तो इंटरनल सोर्स कोड में आम तौर पर इस्तेमाल होने वाले तरीकों का इस्तेमाल हो सकता है, लेकिन अगर एपीआई (जिस लाइब्रेरी से इंटरैक्ट किया जा रहा है) जाने-पहचाने तरीकों का इस्तेमाल करता है, तो आपको चिंता करने की कोई ज़रूरत नहीं है.
अगर लाइब्रेरी एपीआई, कोडिंग के सामान्य तौर-तरीकों का पालन नहीं करता है, तो JavaScript डिज़ाइन पैटर्न का इस्तेमाल किया जा सकता है, जैसे कि प्रॉक्सी पैटर्न. ऐसा करने पर, आपका प्रॉक्सी आपके कोड बेस में कोड के अन्य हिस्सों को ज़्यादा बेहतर एपीआई उपलब्ध करा सकता है.

इस्तेमाल में आसान होने की वजह से, कन्वेंशन की अहम भूमिका होती है. आसान एपीआई वाली लाइब्रेरी, कई घंटे या यहां तक कि लोगों के घंटों की बचत कर सकती है. ऐसी लाइब्रेरी की तुलना ऐसे एपीआई से की जाती है जिसे समझने के लिए काफ़ी प्रयोग करने की ज़रूरत होती है.

अपडेट देखें

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

कोई लाइब्रेरी या फ़्रेमवर्क चुनते समय, अपडेट को मैनेज करने के तरीके पर ध्यान दें. साथ ही, ध्यान रखें कि इस तरह के फ़ैसले आप पर असर डाल सकते हैं:

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

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

लाइसेंस

सॉफ़्टवेयर का लाइसेंस देना, तीसरे पक्ष की सॉफ़्टवेयर लाइब्रेरी का इस्तेमाल करने का एक अहम पहलू है. लाइब्रेरी का लेखक अपनी लाइब्रेरी को लाइसेंस असाइन कर सकता है. अगर आपको लाइब्रेरी का इस्तेमाल करना है, तो उनके लिए लाइसेंस का विकल्प आपके चैनल पर असर डाल सकता है.

उदाहरण के लिए, किसी JavaScript लाइब्रेरी में ऐसा सॉफ़्टवेयर लाइसेंस हो सकता है जो आपको गैर-व्यावसायिक माहौल में उसका इस्तेमाल करने की अनुमति देता है. अपने शौक के लिए इस्तेमाल किए जाने वाले प्रोजेक्ट के लिए, यह एक बेहतरीन विकल्प हो सकता है. अगर आपके प्रोजेक्ट में कोई व्यावसायिक एलिमेंट शामिल है, तो आपको एंटरप्राइज़ लाइसेंस लेने की ज़रूरत पड़ सकती है.

किसी भी तरह का संदेह होने पर, किसी पेशेवर कानूनी सलाह लें या अपनी कंपनी की कानूनी टीम से संपर्क करें.

कम्यूनिटी

ऐसी लाइब्रेरी या फ़्रेमवर्क जिससे लोगों/योगदान देने वालों का एक बड़ा समुदाय फ़ायदा हो सकता है, लेकिन इसकी कोई गारंटी नहीं है. आम तौर पर, किसी लाइब्रेरी या फ़्रेमवर्क के उपयोगकर्ताओं की संख्या जितनी ज़्यादा होगी, उसे फ़ायदा मिलने की संभावना उतनी ही ज़्यादा होगी. डेवलपमेंट से जुड़े कम्यूनिटी में हिस्सा लेने के इन फ़ायदों और नुकसान के बारे में सोचें:

फ़ायदे:

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

नुकसान:

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

ध्यान दें: वेब डेवलपमेंट कम्यूनिटी वाकई शानदार है! हर कम्यूनिटी की परेशानियां होती हैं. हालांकि, यहां दी गई जानकारी के हिसाब से आपको किसी खास कम्यूनिटी में दिलचस्पी दिखाने से खुद को निराश नहीं होना चाहिए. किसी नए वेब डेवलपर के लिए, किसी कम्यूनिटी का हिस्सा होना खास तौर पर चुनौती भरा हो सकता है. खास तौर पर, अलग-अलग विचार रखने वाले समुदायों को ऐसा महसूस कराना. आपको पता होना चाहिए कि यह वेब समुदाय में एक आम चुनौती है और इसमें एक ऐसा क्षेत्र है जिसमें ज़्यादा खुली बातचीत की ज़रूरत होती है.

दस्तावेज़

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

दस्तावेज़ में सैंपल कोड भी मिल सकता है, जिससे आपको अपना काम जल्दी से शुरू करने में आसानी होती है. किसी लाइब्रेरी या फ़्रेमवर्क का आकलन करते समय, इनमें से कुछ सवाल पूछे जा सकते हैं:

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

दस्तावेज़ हमेशा पूरे नहीं हो सकते और इसमें कोई दिक्कत नहीं है. आपको अपने संगठन की ज़रूरतों, अपने प्रोजेक्ट की ज़रूरतों, और अपने सॉफ़्टवेयर की जटिलता का आकलन करना होगा. साथ ही, इसका इस्तेमाल करके यह तय करना होगा कि आपको किस लेवल के दस्तावेज़ की ज़रूरत है.

नतीजा

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

लाइब्रेरी और फ़्रेमवर्क के कुछ अन्य पहलुओं पर भी ध्यान दिया जा सकता है. साथ ही, इनके बारे में इस पोस्ट में बहुत ज़्यादा चर्चा नहीं की गई है:

एक्सटेंडेडबिलिटी: अपनी पसंद के लॉजिक और/या बिहेवियर का इस्तेमाल करके लाइब्रेरी को बढ़ाना कितना आसान है?
टूलिंग: अगर लागू हो, तो क्या लाइब्रेरी में कोड एडिटर प्लगिन, डीबग करने वाले टूल, और सिस्टम प्लगिन बनाने जैसे टूल मौजूद हैं?
स्ट्रक्चर: साफ़ कोड ज़रूरी है, लेकिन क्या लाइब्रेरी का पूरा आर्किटेक्चर काम का है?
टेस्ट: क्या प्रोजेक्ट में टेस्ट सुइट है? क्या प्रोजेक्ट की वेबसाइट पर ऐसे बैज या इंडिकेटर का इस्तेमाल किया गया है जिन्हें टेस्ट सुइट ने हाल ही में जारी किया है?
यह किन सुविधाओं के साथ काम करती है: क्या लाइब्रेरी, फ़िलहाल इस्तेमाल की जा रही दूसरी लाइब्रेरी और/या फ़्रेमवर्क के साथ ठीक से काम करती है?
लागत: फ़्रेमवर्क की कीमत कितनी है? क्या यह ओपन सोर्स है या खरीदारी के लिए उपलब्ध है?
वैनिटी मेट्रिक: यह आपकी शर्तों की सूची में कम होनी चाहिए या इसे पूरी तरह से अनदेखा किया जाना चाहिए, लेकिन हो सकता है कि आप प्रोजेक्ट के "वोट", प्रोजेक्ट से जुड़े सोशल मीडिया खातों, और/या प्रोजेक्ट पेज पर मौजूद कितनी गड़बड़ियों/समस्याओं पर विचार करना चाहें.