इस लेख में, अपने वेब ऐप्लिकेशन में इस्तेमाल करने के लिए लाइब्रेरी या फ़्रेमवर्क चुनने के बारे में अहम जानकारी दी गई है. यहां दी गई जानकारी से आपको 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 एनवायरमेंट होते हैं. जैसे, सर्वर (क्लाउड एनवायरमेंट में चलाया जाता है) या Raspberry Pi पर. इनमें आपको लाइब्रेरी और फ़्रेमवर्क की जांच करने के लिए इस्तेमाल की जाने वाली शर्तों में बदलाव करना पड़ सकता है.
परफ़ॉर्मेंस
क्लाइंट-साइड वेब ऐप्लिकेशन पर JavaScript लाइब्रेरी की परफ़ॉर्मेंस के असर को अनदेखा नहीं किया जाना चाहिए. बड़ी JavaScript लाइब्रेरी, आपके पेज के लोड होने की परफ़ॉर्मेंस पर असर डाल सकती है. याद रखें, मिलीसेकंड से लाखों लोग जुड़ते हैं.
मान लें कि आपने ऐनिमेशन के लिए JavaScript लाइब्रेरी का इस्तेमाल किया है. कुछ लाइब्रेरी आसानी से कई किलोबाइट जोड़ सकती हैं. कुछ मामलों में, सैकड़ों किलोबाइट भी जोड़ सकती हैं. इस तरह के JavaScript रिसॉर्स, आपके पेज लोड होने में काफ़ी समय लगा सकते हैं. ऐसा इसलिए होता है, क्योंकि ब्राउज़र को कोड डाउनलोड, पार्स, कंपाइल, और एक्ज़ीक्यूट करना पड़ता है.
JavaScript लाइब्रेरी जितनी बड़ी होगी, उपयोगकर्ताओं के लिए परफ़ॉर्मेंस पर उतना ही ज़्यादा असर पड़ेगा.
किसी JavaScript लाइब्रेरी या फ़्रेमवर्क का आकलन या इस्तेमाल करते समय, परफ़ॉर्मेंस को बेहतर बनाने के लिए इन सुझावों को अपनाएं:
- अगर आपके पास बड़ी JavaScript लाइब्रेरी है, तो इसके बजाय किसी छोटी लाइब्रेरी का इस्तेमाल करें. उदाहरण के लिए, date-fns कुछ अन्य विकल्पों की तुलना में ज़्यादा सही साइज़ में कई सुविधाएं देता है.
- date-fns के पिछले उदाहरण के मुताबिक, सिर्फ़ वे फ़ंक्शन इंपोर्ट करें जिनकी आपको ज़रूरत है. जैसे:
import { format } from 'date-fns'. इस तरीके को ट्री शेकिंग के साथ ज़रूर इस्तेमाल करें, ताकि कम से कम JavaScript पेलोड बनाया जा सके और आपके उपयोगकर्ताओं को भेजा जा सके. - परफ़ॉर्मेंस की जांच करने वाले टूल, जैसे कि Lighthouse का इस्तेमाल करके, किसी JavaScript लाइब्रेरी का इस्तेमाल करने से परफ़ॉर्मेंस पर पड़ने वाले असर को देखें. अगर कोई लाइब्रेरी आपके पेज लोड होने में एक सेकंड की देरी करती है, तो आपको अपनी चुनी हुई लाइब्रेरी का फिर से आकलन करना पड़ सकता है. टेस्टिंग के दौरान, अपने नेटवर्क और सीपीयू को थ्रॉटल करना न भूलें. पेज लोड होने की जांच करने के साथ-साथ, उस वेब पेज के व्यवहार की प्रोफ़ाइल भी बनाएं जो लाइब्रेरी से कोड को शुरू करता है. पेज लोड होने की परफ़ॉर्मेंस से पूरी जानकारी नहीं मिलती.
- अगर लाइब्रेरी के लेखक को टिप्पणियां पसंद हैं, तो परफ़ॉर्मेंस से जुड़ी अपनी राय, सुझाव, और प्रोजेक्ट में योगदान सबमिट करें. यहीं पर ओपन सोर्स कम्यूनिटी की अहमियत पता चलती है! अगर आपको योगदान देना है, तो पहले अपने एम्प्लॉयर से संपर्क करें.
- bundlesize जैसे ऑटोमेटेड बंडल ट्रैकिंग टूल का इस्तेमाल करें, ताकि लाइब्रेरी में होने वाले बड़े अपडेट पर नज़र रखी जा सके. यह आम बात है कि JavaScript लाइब्रेरी समय के साथ बड़ी होती जाएगी. नई सुविधाएं जोड़ने, गड़बड़ियां ठीक करने, और अन्य वजहों से लाइब्रेरी की फ़ाइल का साइज़ बढ़ सकता है. जब आप/आपकी टीम किसी लाइब्रेरी का इस्तेमाल करने के लिए सहमत हो जाती है, तो लाइब्रेरी को अपडेट करना आसान हो सकता है. साथ ही, इससे जुड़े सवाल भी कम हो सकते हैं. ऐसे में, ऑटोमेशन का इस्तेमाल करना मददगार साबित होता है.
- लाइब्रेरी के लिए अपनी ज़रूरी शर्तों को देखें और आकलन करें कि वेब प्लैटफ़ॉर्म, नेटिव तौर पर वही सुविधा देता है या नहीं. उदाहरण के लिए, वेब प्लैटफ़ॉर्म पर पहले से ही कलर पिकर मौजूद है. इससे, इस सुविधा को लागू करने के लिए तीसरे पक्ष की JavaScript लाइब्रेरी का इस्तेमाल करने की ज़रूरत नहीं पड़ती.
सुरक्षा
तीसरे पक्ष के मॉड्यूल का इस्तेमाल करने से, सुरक्षा से जुड़े कुछ जोखिम हो सकते हैं. आपके वेब ऐप्लिकेशन के कोड बेस में मौजूद नुकसान पहुंचाने वाला पैकेज, आपकी डेवलपमेंट टीम और आपके उपयोगकर्ताओं, दोनों की सुरक्षा को खतरे में डाल सकता है.
मान लें कि NPM नेटवर्क पर कोई लाइब्रेरी पब्लिश की गई है. ऐसा पैकेज कानूनी तौर पर सही हो सकता है. हालांकि, समय के साथ पैकेज में गड़बड़ी हो सकती है.
तीसरे पक्ष के कोड का इस्तेमाल या आकलन करते समय, सुरक्षा से जुड़ी इन बातों का ध्यान रखें:
- अगर GitHub का इस्तेमाल किया जा रहा है, तो कोड की सुरक्षा से जुड़ी सुविधाओं का इस्तेमाल करें. जैसे, Dependabot. इसके अलावा, आपके पास ऐसी अन्य सेवाओं का इस्तेमाल करने का विकल्प है जो आपके कोड में मौजूद कमियों को स्कैन करती हैं. जैसे, snyk.io.
- कोड की जांच करने वाली सेवाओं का इस्तेमाल करें. इनमें इंजीनियर की एक टीम होती है, जो तीसरे पक्ष के कोड की मैन्युअल तरीके से जांच कर सकती है.
- यह तय करें कि आपको अपनी डिपेंडेंसी को किसी खास वर्शन पर लॉक करना चाहिए या तीसरे पक्ष के कोड को अपने वर्शन कंट्रोल में शामिल करना चाहिए. इससे, डिपेंडेंसी को किसी एक वर्शन पर लॉक किया जा सकता है. ऐसा वर्शन जो सुरक्षित माना जाता है. हालांकि, इससे सुरक्षा पर बुरा असर पड़ सकता है, क्योंकि हो सकता है कि आपको लाइब्रेरी के ज़रूरी अपडेट न मिलें.
- प्रोजेक्ट के होम पेज या GitHub पेज को स्कैन करें, अगर कोई पेज मौजूद है. यह पता लगाना कि सुरक्षा से जुड़ी समस्याएं अब भी मौजूद हैं या नहीं. साथ ही, यह देखना कि सुरक्षा से जुड़ी पिछली समस्याओं को तय समयसीमा के अंदर हल किया गया था या नहीं.
- तीसरे पक्ष का ऐसा कोड जो तीसरे पक्ष के किसी अन्य कोड का इस्तेमाल करता है, उसमें ज़ीरो डिपेंडेंसी वाली लाइब्रेरी की तुलना में ज़्यादा जोखिम हो सकता है. इस जोखिम का ध्यान रखें.
सुलभता
आपके मन में यह सवाल उठ सकता है कि सॉफ़्टवेयर लाइब्रेरी, वेब सुलभता से कैसे जुड़ी हैं. सॉफ़्टवेयर लाइब्रेरी का इस्तेमाल अलग-अलग एनवायरमेंट में किया जा सकता है. हालांकि, क्लाइंट-साइड JavaScript-आधारित लाइब्रेरी के संदर्भ में, वेब सुलभता बहुत ज़रूरी है.
क्लाइंट-साइड JavaScript-आधारित लाइब्रेरी (या फ़्रेमवर्क) आपकी वेबसाइट की सुलभता को बढ़ा या घटा सकती है. मान लें कि तीसरे पक्ष की कोई JavaScript लाइब्रेरी, किसी पेज पर इमेज स्लाइडर जोड़ती है. अगर इमेज स्लाइडर में वेब सुलभता की सुविधा नहीं है, तो हो सकता है कि वेब डेवलपर के तौर पर आपसे यह अहम सुविधा छूट जाए. साथ ही, ऐसा प्रॉडक्ट रिलीज़ हो जाए जिसमें ज़रूरी सुविधाएं न हों. जैसे, स्लाइडर को कीबोर्ड से नेविगेट करने की सुविधा!
- क्या रिस्पॉन्सिव टाइपोग्राफ़ी प्लगिन, पेज को ज़ूम इन या ज़ूम आउट करने वाले उपयोगकर्ताओं के लिए काम करता है?
- क्या फ़ाइल अपलोडर प्लग इन, सहायक डिवाइसों से फ़ाइल अपलोड करने की सुविधा देता है?
- क्या ऐनिमेशन लाइब्रेरी, उन उपयोगकर्ताओं को सहायता देती है जो कम मोशन वाले ऐनिमेशन पसंद करते हैं?
- क्या इंटरैक्टिव मैप प्लगिन को सिर्फ़ कीबोर्ड से इस्तेमाल किया जा सकता है?
- क्या ऑडियो प्लेयर लाइब्रेरी, स्क्रीन रीडर पर सही अनुभव देती है?
यह उम्मीद करना सही है कि सुलभता से जुड़ी इन ज़रूरी शर्तों को पूरा करने के लिए, वेब डेवलपर के तौर पर आपको कुछ हद तक शामिल होना पड़ेगा. उदाहरण के लिए:
- अगर आपको कोई सुविधा नहीं मिल रही है, तो उसे अपने कोड बेस में लागू किया जा सकता है. भले ही, उस लाइब्रेरी का इस्तेमाल जारी रखा जा रहा हो.
- अगर लाइब्रेरी का लेखक अनुमति देता है, तो अपनी कंपनी की मदद से, लाइब्रेरी में ऐसी सुविधा जोड़ी जा सकती है जो उसमें मौजूद नहीं है.
- लाइब्रेरी के लेखक से बातचीत शुरू की जा सकती है. उदाहरण के लिए, क्या आपके रोडमैप में सुलभता की ये सुविधाएं शामिल हैं? क्या आप इस बात से सहमत हैं कि ये आइटम लाइब्रेरी में होने चाहिए?
- लोकप्रिय इस्तेमाल के उदाहरणों के लिए, लाइब्रेरी के ऐसे अन्य विकल्प एक्सप्लोर किए जा सकते हैं जो ज़्यादा सुलभ हों. ऐसा हो सकता है कि वे मौजूद हों, लेकिन उन्हें ढूंढना मुश्किल हो.
- कुछ मामलों में, आपको किसी लाइब्रेरी को पूरी तरह से हटाना पड़ सकता है और अपनी सुविधाओं को नए सिरे से लागू करना पड़ सकता है. ऐसा तब हो सकता है, जब किसी लाइब्रेरी या फ़्रेमवर्क को पहली बार इस्तेमाल करने पर, सुलभता से जुड़ी खराब सुविधाएं मिलती हों. साथ ही, आपको लाइब्रेरी या फ़्रेमवर्क से मिलने वाली कई सुविधाओं को पहले जैसा करना पड़े.
कन्वेंशन
ऐसी सॉफ़्टवेयर लाइब्रेरी के साथ काम करना आसान होता है जो पहले से तय कोडिंग कन्वेंशन का इस्तेमाल करती है. अगर कोई लाइब्रेरी, कोडिंग के ऐसे तरीके का इस्तेमाल करती है जिसके बारे में आपने कभी नहीं सुना, तो आपके और आपकी टीम के लिए ऐसी लाइब्रेरी के साथ काम करना मुश्किल हो सकता है.
अगर कोई लाइब्रेरी, कोडिंग के सामान्य नियमों (उदाहरण के लिए, कोई सामान्य स्टाइल गाइड) का पालन नहीं करती है, तो तुरंत समस्या को ठीक करने के लिए ज़्यादा कुछ नहीं किया जा सकता. हालांकि, आपके पास अब भी कुछ विकल्प हैं:
- लाइब्रेरी के सोर्स कोड और आपको दिखाए गए एपीआई के बीच के अंतर को समझें. ऐसा हो सकता है कि इंटरनल सोर्स कोड में ऐसे कन्वेंशन इस्तेमाल किए गए हों जिनके बारे में आपको जानकारी न हो. हालांकि, अगर एपीआई (लाइब्रेरी का वह हिस्सा जिससे इंटरैक्ट किया जाता है) में ऐसे कन्वेंशन इस्तेमाल किए गए हैं जिनके बारे में आपको जानकारी है, तो चिंता करने की कोई बात नहीं है.
- अगर लाइब्रेरी एपीआई, कोडिंग के सामान्य नियमों का पालन नहीं करता है, तो JavaScript डिज़ाइन पैटर्न का इस्तेमाल किया जा सकता है. जैसे, प्रॉक्सी पैटर्न. इससे लाइब्रेरी के साथ होने वाले सभी इंटरैक्शन को कोड बेस में मौजूद एक फ़ाइल में रैप और सेव किया जा सकता है. इसके बाद, आपका प्रॉक्सी आपके कोड बेस में मौजूद कोड के अन्य हिस्सों को ज़्यादा आसान एपीआई उपलब्ध करा सकता है.
इस्तेमाल में आसानी के लिए, कन्वेंशन अहम भूमिका निभाते हैं. इस्तेमाल करने में आसान एपीआई वाली लाइब्रेरी, लोगों के कई घंटे या दिन बचा सकती है. वहीं, इस्तेमाल करने में मुश्किल एपीआई को समझने के लिए, लोगों को काफ़ी एक्सपेरिमेंट करने पड़ते हैं.
अपडेट
उदाहरण के लिए, कुछ गणितीय गणनाएं करने वाली पूरी तरह से काम करने वाली लाइब्रेरी को अपडेट की ज़रूरत शायद ही कभी पड़े. असल में, वेब डेवलपमेंट की लगातार बदलती दुनिया में, सभी सुविधाओं वाली लाइब्रेरी मिलना बहुत मुश्किल है! हालांकि, कभी-कभी आपको लाइब्रेरी के लेखक से जवाब चाहिए होता है और आपको यह उम्मीद होती है कि वह अपडेट करने के लिए तैयार हो. नई रिसर्च और नतीजों से, काम करने के बेहतर तरीके सामने आ सकते हैं. इसलिए, लाइब्रेरी और फ़्रेमवर्क में इस्तेमाल की जाने वाली तकनीकों में हमेशा बदलाव हो सकता है.
कोई लाइब्रेरी या फ़्रेमवर्क चुनते समय, इस बात पर ध्यान दें कि अपडेट कैसे मैनेज किए जाते हैं. साथ ही, ध्यान रखें कि ऐसे फ़ैसलों का असर आप पर पड़ सकता है:
- क्या लाइब्रेरी में रिलीज़ करने का शेड्यूल सही है? उदाहरण के लिए, सोर्स कोड रिपॉज़िटरी में अक्सर अपडेट किए जा सकते हैं. हालांकि, अगर ऐसे अपडेट "पब्लिश" या "रिलीज़" नहीं किए जाते हैं, तो आपको उन्हें डाउनलोड करने में परेशानी हो सकती है.
- क्या लाइब्रेरी, सॉफ़्टवेयर के वर्शन की सही स्कीम के साथ अपडेट रिलीज़ करती है? लाइब्रेरी से आपका समय बचना चाहिए. अगर आपको लाइब्रेरी का वर्शन अपडेट करने पर, हर बार अपने कोड में बदलाव करना पड़ता है, तो हो सकता है कि उस लाइब्रेरी को इस्तेमाल करने का मकसद ही पूरा न हो. कभी-कभी नुकसान पहुंचा सकने वाले बदलावों से बचना मुमकिन नहीं होता. हालांकि, आम तौर पर बदलाव कम ही होते हैं और लाइब्रेरी के उपभोक्ताओं पर इन्हें ज़बरदस्ती लागू नहीं किया जाता.
- क्या लाइब्रेरी, पुराने सिस्टम के साथ काम करने की सुविधा पर काम करती है? कभी-कभी, सॉफ़्टवेयर अपडेट में नुकसान पहुंचा सकने वाले बदलाव शामिल हो सकते हैं. हालांकि, इनमें पुराने सिस्टम के साथ काम करने की सुविधा भी होती है. इससे लाइब्रेरी का इस्तेमाल करने वाले लोग, लाइब्रेरी के नए वर्शन का इस्तेमाल कर सकते हैं. इसके लिए, उन्हें अपने कोड में मामूली बदलाव करने होंगे.
लाइसेंस देना
तीसरे पक्ष की सॉफ़्टवेयर लाइब्रेरी का इस्तेमाल करने के लिए, सॉफ़्टवेयर लाइसेंसिंग एक अहम पहलू है. लाइब्रेरी का लेखक, अपनी लाइब्रेरी को लाइसेंस असाइन कर सकता है. अगर आपको लाइब्रेरी का इस्तेमाल करना है, तो उनके लाइसेंस के विकल्प से आप पर असर पड़ सकता है.
उदाहरण के लिए, हो सकता है कि किसी JavaScript लाइब्रेरी के पास ऐसा सॉफ़्टवेयर लाइसेंस हो जो आपको उसे गैर-व्यावसायिक माहौल में इस्तेमाल करने की अनुमति देता हो. अगर आपको निजी तौर पर कोई प्रोजेक्ट बनाना है, तो यह एक बेहतरीन विकल्प हो सकता है. अगर आपके प्रोजेक्ट में कोई व्यावसायिक एलिमेंट है, तो आपको एंटरप्राइज़ लाइसेंस लेने के बारे में सोचना पड़ सकता है.
अगर आपको कोई संदेह है, तो किसी पेशेवर से कानूनी सलाह लें या अपनी कंपनी की कानूनी टीम से संपर्क करें.
कम्यूनिटी
ऐसी लाइब्रेरी या फ़्रेमवर्क का इस्तेमाल करना फ़ायदेमंद हो सकता है जिसमें उपयोगकर्ताओं/योगदान देने वाले लोगों की बड़ी कम्यूनिटी हो. हालांकि, इसकी कोई गारंटी नहीं है. आम तौर पर, किसी लाइब्रेरी या फ़्रेमवर्क के जितने ज़्यादा उपयोगकर्ता होते हैं, उसे उतना ही ज़्यादा फ़ायदा मिलता है. डेवलपमेंट कम्यूनिटी में शामिल होने के ये फ़ायदे और नुकसान हो सकते हैं:
फ़ायदे:
- उपयोगकर्ताओं का ग्रुप ज़्यादा होने का मतलब है कि गड़बड़ी का पता जल्दी और अक्सर लगाया जा सकता है.
- एक बड़ी और सक्रिय कम्यूनिटी का मतलब है कि उस लाइब्रेरी या फ़्रेमवर्क के बारे में ज़्यादा ट्यूटोरियल, गाइड, वीडियो, और कोर्स उपलब्ध होंगे.
- एक बड़ी और सक्रिय कम्यूनिटी का मतलब है कि फ़ोरम और सवाल-जवाब वाली वेबसाइटों पर ज़्यादा सहायता मिलेगी. इससे, सहायता से जुड़े सवालों के जवाब मिलने की संभावना बढ़ जाती है.
- अगर कम्यूनिटी के लोग आपके प्रोजेक्ट में दिलचस्पी लेते हैं, तो हो सकता है कि वे लाइब्रेरी या फ़्रेमवर्क में योगदान दें. इनकी मदद से, ऐसी सुविधाएं उपलब्ध कराई जा सकती हैं जो लेखक के रोडमैप में शामिल नहीं हैं.
- जब कोई लाइब्रेरी या फ़्रेमवर्क किसी कम्यूनिटी में लोकप्रिय होता है, तो इस बात की संभावना बढ़ जाती है कि आपके साथियों और सहकर्मियों ने ऐसी लाइब्रेरी या फ़्रेमवर्क के बारे में सुना हो या वे उससे पहले से ही परिचित हों.
नुकसान:
- अगर किसी प्रोजेक्ट के उपयोगकर्ताओं की संख्या ज़्यादा है और वे अलग-अलग तरह के हैं, तो लगातार नई सुविधाएं जोड़ने से प्रोजेक्ट का साइज़ काफ़ी बढ़ सकता है. बहुत ज़्यादा लाइब्रेरी होने से, वेब की परफ़ॉर्मेंस पर असर पड़ सकता है.
- किसी ऐसे प्रोजेक्ट पर काम करना जिसमें कम्यूनिटी के लोग काफ़ी सक्रिय हों और दिलचस्पी दिखाते हों, लेखकों और उसे मैनेज करने वाले लोगों के लिए तनाव भरा हो सकता है. साथ ही, इसमें कम्यूनिटी को मॉडरेट करने की ज़्यादा ज़रूरत पड़ सकती है.
- अगर कोई प्रोजेक्ट तेज़ी से आगे बढ़ रहा है, लेकिन उसे सही तरीके से सपोर्ट नहीं मिल रहा है, तो हो सकता है कि उसकी कम्यूनिटी में गलत व्यवहार करने वाले लोग शामिल हो जाएं. उदाहरण के लिए, गेटकीपिंग की वजह से, नए या जूनियर वेब डेवलपर को किसी कम्यूनिटी में शामिल होने से रोका जा सकता है.
दस्तावेज़
JavaScript लाइब्रेरी या फ़्रेमवर्क कितना भी आसान या मुश्किल क्यों न हो, सॉफ़्टवेयर दस्तावेज़ हमेशा मदद कर सकता है. यहां तक कि बहुत अनुभवी डेवलपर भी कोड को खुद समझने के बजाय, दस्तावेज़ का इस्तेमाल करते हैं. दस्तावेज़ में बताया गया है कि आपको कौनसा एपीआई इस्तेमाल करना चाहिए और उसे इस्तेमाल करने का तरीका क्या है.
दस्तावेज़ में सैंपल कोड भी मिल सकता है. इससे आपको तुरंत शुरुआत करने में मदद मिलती है. किसी लाइब्रेरी या फ़्रेमवर्क का आकलन करते समय, ये सवाल पूछे जा सकते हैं:
- क्या लाइब्रेरी में दस्तावेज़ शामिल हैं? अगर ऐसा नहीं है, तो आपको खुद ही चीज़ों को समझना होगा.
- क्या दस्तावेज़ साफ़ तौर पर लिखा गया है, आसानी से समझ में आता है, और इसमें कोई भ्रम नहीं है? कई डेवलपर, दस्तावेज़ बनाने में काफ़ी समय लगाते हैं. यह बात भले ही छोटी लगे, लेकिन टेक्स्ट वाले दस्तावेज़ों में साफ़ तौर पर जानकारी देने से, आपकी प्रॉडक्टिविटी पर काफ़ी असर पड़ सकता है.
- क्या दस्तावेज़ पूरी तरह से अपने-आप जनरेट होता है? इस तरह के दस्तावेज़ को समझना मुश्किल हो सकता है. साथ ही, इनमें एपीआई इस्तेमाल करने के तरीके के बारे में हमेशा साफ़ तौर पर जानकारी नहीं दी जाती.
- क्या दस्तावेज़ अप-टू-डेट है? दस्तावेज़ों के रखरखाव को कभी-कभी बाद में किए जाने वाले काम के तौर पर देखा जाता है. अगर लाइब्रेरी को अपडेट किया जाता है, लेकिन दस्तावेज़ को अपडेट नहीं किया जाता, तो इससे डेवलपमेंट में लगने वाला समय बर्बाद हो सकता है.
- क्या दस्तावेज़ पूरी जानकारी देने वाला और कई फ़ॉर्मैट में उपलब्ध है? इस्तेमाल के लिए गाइड, सैंपल कोड, रेफ़रंस दस्तावेज़, लाइव डेमो, और ट्यूटोरियल, सभी अहम दस्तावेज़ फ़ॉर्मैट हैं. इनकी मदद से, किसी लाइब्रेरी या फ़्रेमवर्क का इस्तेमाल करके बेहतर नतीजे पाए जा सकते हैं.
यह ज़रूरी नहीं है कि दस्तावेज़ हमेशा पूरा हो. आपको अपने संगठन की ज़रूरतों, प्रोजेक्ट की ज़रूरी शर्तों, और सॉफ़्टवेयर की जटिलता का आकलन करना होगा. इसके बाद, यह तय करना होगा कि आपको किस लेवल के दस्तावेज़ की ज़रूरत है.
नतीजा
पहली बार कोई लाइब्रेरी या फ़्रेमवर्क चुनते समय, घबराहट होना सामान्य बात है. किसी भी काम को जितना ज़्यादा सीखा और प्रैक्टिस किया जाता है, वह उतना ही बेहतर होता जाता है. अगली बार जब आपको इस्तेमाल करने के लिए कोई लाइब्रेरी या फ़्रेमवर्क चुनना हो, तो इस पोस्ट को देखें. इससे आपको मदद मिल सकती है. इस पोस्ट में मौजूद हेडिंग को चेकलिस्ट के तौर पर इस्तेमाल किया जा सकता है. उदाहरण के लिए: क्या यह लाइब्रेरी बेहतर परफ़ॉर्म करती है? क्या यह लाइब्रेरी, वेब सुलभता के लिए मेरे कारोबार के मानकों को पूरा करती है?
लाइब्रेरी और फ़्रेमवर्क के कुछ अन्य पहलू भी हैं जिन पर आपको विचार करना चाहिए. इस पोस्ट में उनके बारे में ज़्यादा चर्चा नहीं की गई है:
- एक्सटेंड करने की सुविधा: कस्टम लॉजिक और/या व्यवहार के साथ लाइब्रेरी को एक्सटेंड करना कितना आसान है?
- टूल: अगर लागू हो, तो क्या लाइब्रेरी में कोड एडिटर प्लग इन, डीबग करने वाले टूल, और बिल्ड सिस्टम प्लग इन जैसे टूल हैं?
- आर्किटेक्चर: साफ़ कोड ज़रूरी है, लेकिन क्या लाइब्रेरी का पूरा आर्किटेक्चर सही है?
- टेस्ट: क्या प्रोजेक्ट में कोई टेस्ट सुइट है? क्या प्रोजेक्ट की वेबसाइट पर ऐसे बैज या इंडिकेटर इस्तेमाल किए जाते हैं जो टेस्ट सुइट, कमिट के नए वर्शन के लिए पास कर रहा है?
- साथ काम करना: क्या लाइब्रेरी, उन अन्य लाइब्रेरी और/या फ़्रेमवर्क के साथ अच्छी तरह से काम करती है जिनका इस्तेमाल फ़िलहाल किया जा रहा है?
- लागत: फ़्रेमवर्क की लागत क्या है? क्या यह ओपन-सोर्स है या इसे खरीदा जा सकता है?
- वैनिटी मेट्रिक: यह आपकी शर्तों की सूची में सबसे नीचे होनी चाहिए या इसे पूरी तरह से अनदेखा किया जाना चाहिए. हालांकि, आपके पास प्रोजेक्ट के "वोट", प्रोजेक्ट को दिखाने वाले सोशल मीडिया खातों, और/या प्रोजेक्ट पेज पर मौजूद ओपन बग/समस्याओं की संख्या पर विचार करने का विकल्प है.