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 एनवायरमेंट हैं जो क्लाइंट-साइड के नहीं होते. जैसे, सर्वर (क्लाउड एनवायरमेंट में चलने वाला) या Raspberry Pi. इनमें लाइब्रेरी और फ़्रेमवर्क की जांच करने के लिए, आपको इस्तेमाल की जाने वाली शर्तों में बदलाव करना पड़ सकता है.

परफ़ॉर्मेंस

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

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

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

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

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

सुरक्षा

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

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

तीसरे पक्ष के कोड का इस्तेमाल करते समय या उसका आकलन करते समय, सुरक्षा से जुड़ी इन बातों का ध्यान रखें:

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

सुलभता

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

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

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

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

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

कॉन्वेंशन

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

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

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

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

अपडेट

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

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

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

लाइसेंस देना

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

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

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

कम्यूनिटी

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

फ़ायदे:

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

नुकसान:

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

दस्तावेज़

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

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

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

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

नतीजा

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

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

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