JavaScript लाइब्रेरी और फ़्रेमवर्क के बीच अंतर

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

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

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

लाइब्रेरी और फ़्रेमवर्क के बारे में क्यों जानें?

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

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

"क्या मुझे आज किसी लाइब्रेरी या फ़्रेमवर्क का इस्तेमाल करना चाहिए?" एक आम सवाल है. लाइब्रेरी और फ़्रेमवर्क दो अलग-अलग चीज़ें हैं. हालांकि, लाइब्रेरी और फ़्रेमवर्क अक्सर आपस में मिल जाते हैं. साथ ही, आपके पास इन दोनों के बारे में जितनी ज़्यादा जानकारी होगी, इस बात की संभावना उतनी ही ज़्यादा होगी. इस बात की संभावना ज़्यादा है कि आप इन लाइब्रेरी के इस्तेमाल के बारे में सोच-समझकर फ़ैसले लें.

लाइब्रेरी और फ़्रेमवर्क के उदाहरण

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

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

लाइब्रेरी

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

lodash लाइब्रेरी का यह उदाहरण देखें:

import lodash from 'lodash'; // [1]
const result = lodash.capitalize('hello'); // [2]
console.log(result); // Hello

जैसा कि कई लाइब्रेरी के मामले में होता है, इस कोड को पढ़ना और समझना व्यावहारिक है कि यह क्या करता है. इसमें बहुत कम जादू है:

1. import स्टेटमेंट, lodash लाइब्रेरी को JavaScript प्रोग्राम में इंपोर्ट करता है.
2. capitalize() तरीके को शुरू किया गया है.
3. मेथड में एक आर्ग्युमेंट पास किया जाता है.
4. रिटर्न वैल्यू, वैरिएबल में कैप्चर की जाती है.

फ़्रेमवर्क

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

इस उदाहरण में एक सामान्य फ़्रेमवर्क दिखाया गया है, जिसमें लाइब्रेरी नहीं है. साथ ही, Vue का इस्तेमाल किया गया है, जो एक लोकप्रिय JavaScript फ़्रेमवर्क है:

<!-- index.html -->
<div id="main">
  {{ message }}
</div>

<script type="module">
import Vue from './node_modules/vue/dist/vue.esm.browser.js';

new Vue({
  el: '#main',
  data: {
    message: 'Hello, world'
  }
});
</script>

अगर आपने फ़्रेमवर्क के इस उदाहरण की तुलना लाइब्रेरी के पुराने उदाहरण से किया है, तो आपको ये अंतर दिख सकते हैं:

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

लाइब्रेरी बनाम फ़्रेमवर्क का इस्तेमाल कब करना चाहिए

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

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

ध्यान दें, आम तौर पर आप फ़्रेमवर्क वाली लाइब्रेरी की तुलना नहीं करें, क्योंकि वे अलग-अलग काम हैं, जिनसे अलग-अलग काम किए जा सकते हैं. हालांकि, आपके पास दोनों के बारे में जितनी ज़्यादा जानकारी होगी, आपके पास अपने लिए सबसे सही फ़ैसला लेने में उतनी ही ज़्यादा ताकत होगी. फ़्रेमवर्क या लाइब्रेरी का इस्तेमाल करने का फ़ैसला आपकी ज़रूरतों पर निर्भर करता है.

स्वैप करने की क्षमता

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

सोर्स कोड से जुड़े पैकेज को हटाना और दूसरे पैकेज से बदलना मुश्किल होता है. इन मामलों में आपको पैकेज स्वैप करना पड़ सकता है:

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

यह उदाहरण देखें:

// header.js file
import color from '@package/set-color';
color('header', 'dark');

// article.js file
import color from '@package/set-color';
color('.article-post', 'dark');

// footer.js file
import color from '@package/set-color';
color('.footer-container', 'dark');

पिछले उदाहरण में, तीसरे पक्ष के @package/set-color पैकेज का इस्तेमाल तीन अलग-अलग फ़ाइलों में किया गया है. अगर आप इस कोड पर काम करते हैं और तीसरे पक्ष के पैकेज को बदलना चाहते हैं, तो आपको कोड को तीन जगहों पर अपडेट करना होगा.

इसके अलावा, लाइब्रेरी के इस्तेमाल को एक ही जगह पर आसान और एब्सट्रैक्ट किया जा सकता है. यह जानकारी आपको इस उदाहरण में दिखेगी:

// lib/set-color.js file
import color from '@package/set-color';

export default function color(element, theme = 'dark') {
  color(element, theme);
}

// header.js file
import color from './lib/set-color.js';
color('header');

// article.js file
import color from './lib/set-color.js';
color('.article-post');

// footer.js file
import color from './lib/set-color.js';
color('.footer-container');

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

इस्तेमाल में आसानी

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

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

फ़्रेमवर्क इन सबसे सही तरीकों का इस्तेमाल करके इन चुनौतियों से बचा जा सकता है:

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

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

इसके अलावा, आम तौर पर फ़्रेमवर्क आपके वेब ऐप्लिकेशन के लिए एक आर्किटेक्चर का इस्तेमाल करता है, जबकि लाइब्रेरी आम तौर पर आपके मौजूदा आर्किटेक्चर के साथ काम करती है, चाहे वह कुछ भी हो.

परफ़ॉर्मेंस

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

पेड़ के हिलने की आवाज़

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

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

जब तीसरे पक्ष के कोड को अपने सोर्स कोड में इंपोर्ट किया जाता है, तो आम तौर पर उस कोड को एक या कुछ आउटपुट फ़ाइलों में बंडल कर दिया जाता है. उदाहरण के लिए, header.js, footer.js, और sidebar.js फ़ाइलों को output.js फ़ाइल में मिला दिया जाता है. यह ऐसी आउटपुट फ़ाइल है जिसे अपने वेब ऐप्लिकेशन में लोड किया जाता है.

पेड़ों के झटकों को बेहतर ढंग से समझने के लिए, इन कोड के उदाहरणों पर विचार करें:

// library.js file
export function add(a, b) {
  return a + b;
}

export function subtract(a, b) {
  return a - b;
}

// main.js file
import {add} from './library.js';

console.log(add(7, 10));

लोगों को दिखाने के लिए, library.js कोड सैंपल को जान-बूझकर छोटा रखा जाता है. इसके बाद, असल दुनिया में इसकी लाइब्रेरी का साइज़ बड़ा होता है, जिसमें हज़ारों लाइनें दिख सकती हैं.

सामान्य बंडल प्रोसेस, इस आउटपुट के साथ कोड को एक्सपोर्ट कर सकती है:

// output.js file
function add(a, b) {
  return a + b;
}

function subtract(a, b) {
  return a - b;
}

console.log(add(7, 10));

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

// output.js file
function add(a, b) {
  return a + b;
}

console.log(add(7, 10));

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

console.log(7+10);

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

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

सॉफ़्टवेयर अपडेट

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

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

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

रोज़गार

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

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

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

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

नतीजा

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

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