इस लेख में, क्लाइंट-साइड JavaScript एनवायरमेंट के संदर्भ में, फ़्रेमवर्क और लाइब्रेरी के बीच के अंतर के बारे में बताया गया है. यह वह कोड है जो आपके वेब ब्राउज़र में चलता है. हालांकि, इस लेख में बताए गए कुछ पॉइंट दूसरे एनवायरमेंट पर भी लागू होते हैं. इसकी वजह यह है कि लाइब्रेरी और फ़्रेमवर्क, सॉफ़्टवेयर इंजीनियरिंग के कई फ़ील्ड का हिस्सा हैं. जैसे, नेटिव मोबाइल ऐप्लिकेशन डेवलपमेंट.
इस पोस्ट में, लाइब्रेरी और फ़्रेमवर्क के बीच संख्या के बजाय, क्वालिटी के अंतर पर फ़ोकस किया गया है. उदाहरण के लिए:
- संख्या के हिसाब से: फ़्रेमवर्क आम तौर पर कंट्रोल के इनवर्ज़न सिद्धांत का पालन करते हैं.
- गुणवत्ता: नौकरी ढूंढते समय, फ़्रेमवर्क का अनुभव आपके लिए फ़ायदेमंद हो सकता है.
लाइब्रेरी और फ़्रेमवर्क के बारे में क्यों जानना चाहिए?
JavaScript लाइब्रेरी और फ़्रेमवर्क का इस्तेमाल, पूरे वेब पर बहुत ज़्यादा किया जाता है. ऐसा लगता है कि हर दूसरी वेबसाइट, अपने JavaScript संसाधनों के हिस्से के तौर पर, तीसरे पक्ष के किसी कोड का इस्तेमाल करती है. समय के साथ वेब पेज का वेट खराब हो रहा है. इससे उपयोगकर्ताओं पर असर पड़ता है. JavaScript, पेज के कुल साइज़ में काफ़ी योगदान देता है. साथ ही, यह वही JavaScript है जिसमें अक्सर तीसरे पक्ष की लाइब्रेरी और फ़्रेमवर्क शामिल होते हैं.
"JavaScript फ़्रेमवर्क का इस्तेमाल बंद करें" कहना काफ़ी नहीं है, क्योंकि फ़्रेमवर्क से डेवलपर को काफ़ी फ़ायदा मिलता है. फ़्रेमवर्क की मदद से, बेहतर तरीके से कोडिंग की जा सकती है और सुविधाओं को तेज़ी से डिलीवर किया जा सकता है. इसके अलावा, आपको और भी फ़ायदे मिल सकते हैं. इसके बजाय, आपको खुद को इस बारे में जानकारी देनी चाहिए, ताकि ज़रूरत पड़ने पर आप सही फ़ैसला ले सकें.
"क्या मुझे आज किसी लाइब्रेरी या फ़्रेमवर्क का इस्तेमाल करना चाहिए?" यह एक असामान्य सवाल है. लाइब्रेरी और फ़्रेमवर्क, दोनों अलग-अलग चीज़ें हैं. हालांकि, लाइब्रेरी और फ़्रेमवर्क को अक्सर एक ही समझा जाता है. इन दोनों के बारे में ज़्यादा जानकारी होने पर, इनके इस्तेमाल के बारे में सही फ़ैसले लिए जा सकते हैं.
लाइब्रेरी और फ़्रेमवर्क के उदाहरण
आपको तीसरे पक्ष के कोड को अन्य नामों से भी दिख सकता है, जैसे कि विजेट, प्लग इन, पॉलीफ़िल या पैकेज. हालांकि, आम तौर पर ये सभी लाइब्रेरी या फ़्रेमवर्क की कैटगरी में आते हैं. इन दोनों के बीच का अंतर इस तरह समझा जा सकता है:
- किसी लाइब्रेरी के लिए, आपका ऐप्लिकेशन कोड लाइब्रेरी कोड को कॉल करता है.
- फ़्रेमवर्क के लिए, फ़्रेमवर्क आपके ऐप्लिकेशन कोड को कॉल करता है.
लाइब्रेरी
लाइब्रेरी, फ़्रेमवर्क के मुकाबले आसान होती हैं और इनमें फ़ंक्शन का दायरा कम होता है. अगर किसी तरीके में इनपुट डालने पर आपको आउटपुट मिलता है, तो हो सकता है कि आपने लाइब्रेरी का इस्तेमाल किया हो.
lodash
लाइब्रेरी का यह उदाहरण देखें:
import lodash from 'lodash'; // [1]
const result = lodash.capitalize('hello'); // [2]
console.log(result); // Hello
कई लाइब्रेरी की तरह, इस कोड को पढ़कर यह समझना आसान है कि यह क्या करता है. इसमें बहुत कम जादू शामिल है:
import
स्टेटमेंट, lodash लाइब्रेरी को JavaScript प्रोग्राम में इंपोर्ट करता है.capitalize()
तरीका शुरू किया जाता है.- इस तरीके में, एक आर्ग्युमेंट पास किया जाता है.
- रिटर्न वैल्यू को किसी वैरिएबल में कैप्चर किया जाता है.
फ़्रेमवर्क
फ़्रेमवर्क, लाइब्रेरी से बड़े होते हैं और पेज के कुल साइज़ में ज़्यादा योगदान देते हैं. असल में, फ़्रेमवर्क में लाइब्रेरी शामिल हो सकती है.
इस उदाहरण में, लाइब्रेरी के बिना एक सादा फ़्रेमवर्क दिखाया गया है. साथ ही, इसमें 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, Webpack, और Rollup जैसे आधुनिक बंडल टूल, एक कदम आगे बढ़ते हैं. ये टूल, ज़्यादा ऑप्टिमाइज़ किए गए बंडल बनाने के लिए, छोटा करने और ट्री शेकिंग को जोड़ते हैं. बंडल टूल के असर को दिखाने के लिए, हमने पिछले कोड के उदाहरणों के साथ बंडल फ़ाइल बनाने के लिए, Parcel का इस्तेमाल किया. Parcel ने इस्तेमाल न किए गए सभी कोड हटा दिए और इस एक मॉड्यूल को एक्सपोर्ट कर दिया:
console.log(7+10);
Parcel, ज़्यादा ऑप्टिमाइज़ किया गया कोड बनाने के लिए, इंपोर्ट स्टेटमेंट, फ़ंक्शन की परिभाषाओं, और अन्य आइटम के व्यवहार को हटाने में सक्षम है.
बंडलिंग, वेब परफ़ॉर्मेंस का सिर्फ़ एक पहलू है. हालांकि, इसका परफ़ॉर्मेंस पर काफ़ी असर पड़ता है. खास तौर पर, बड़ी लाइब्रेरी के लिए. आम तौर पर, फ़्रेमवर्क के मुकाबले लाइब्रेरी के साथ ट्री शेकिंग करना आसान होता है.
सॉफ़्टवेयर अपडेट
कई लाइब्रेरी और फ़्रेमवर्क के लिए, सॉफ़्टवेयर अपडेट से फ़ंक्शन जोड़े जाते हैं, गड़बड़ियां ठीक की जाती हैं, और आखिर में समय के साथ इनका साइज़ बढ़ जाता है. अपडेट डाउनलोड करना ज़रूरी नहीं है. हालांकि, अगर अपडेट में गड़बड़ियों को ठीक करने, सुविधाओं को बेहतर बनाने या सुरक्षा से जुड़ी समस्याओं को ठीक करने से जुड़ी जानकारी शामिल है, तो आपको अपडेट करना चाहिए. हालांकि, जितने ज़्यादा डेटा को वायर पर भेजा जाता है, आपके ऐप्लिकेशन की परफ़ॉर्मेंस उतनी ही खराब होती है. साथ ही, उपयोगकर्ता अनुभव पर भी इसका बुरा असर पड़ता है.
अगर किसी लाइब्रेरी का साइज़ बढ़ जाता है, तो ट्री शेकिंग का इस्तेमाल करके, साइज़ को कम किया जा सकता है. इसके अलावा, JavaScript लाइब्रेरी के बजाय, किसी छोटी लाइब्रेरी का इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, स्वाप करने की सुविधा देखें.
अगर किसी फ़्रेमवर्क का साइज़ बड़ा हो जाता है, तो ट्री शेकिंग की प्रोसेस ज़्यादा मुश्किल हो जाती है. साथ ही, एक फ़्रेमवर्क को दूसरे से बदलना भी मुश्किल हो सकता है. ज़्यादा जानकारी के लिए, स्वाप करने की सुविधा देखें.
नौकरी पाने की संभावना
यह एक सार्वजनिक बात है कि कई कंपनियों के लिए, किसी खास फ़्रेमवर्क के बारे में जानने वाले डेवलपर को हायर करना ज़रूरी है. वेब की बुनियादी बातों के बारे में आपकी जानकारी को अनदेखा करके, सिर्फ़ किसी खास JavaScript फ़्रेमवर्क के बारे में आपकी जानकारी पर फ़ोकस किया जा सकता है! सही या गलत, कई नौकरियों के लिए यह सच है.
कुछ JavaScript लाइब्रेरी के बारे में जानने से, नौकरी के लिए आवेदन करने पर कोई नुकसान नहीं होगा. हालांकि, इस बात की कोई गारंटी नहीं है कि इससे आपको दूसरों से अलग दिखाया जा सकेगा. अगर आपको कुछ लोकप्रिय JavaScript फ़्रेमवर्क के बारे में अच्छी तरह से पता है, तो हो सकता है कि नौकरी देने वाली कंपनियां, वेब डेवलपर के लिए मौजूदा जॉब मार्केट में इस जानकारी को फ़ायदेमंद मानें. कुछ बड़े एंटरप्राइज़ संगठन, बहुत पुराने JavaScript फ़्रेमवर्क का इस्तेमाल कर रहे हैं. हो सकता है कि वे ऐसे उम्मीदवारों को ढूंढ रहे हों जो ऐसे फ़्रेमवर्क का इस्तेमाल करने में माहिर हों.
इस सार्वजनिक जानकारी का इस्तेमाल अपने फ़ायदे के लिए किया जा सकता है. हालांकि, नौकरी के अवसरों को ढूंढते समय इन बातों का ध्यान रखें:
- याद रखें कि अगर आपने अपने करियर में ज़्यादातर समय सिर्फ़ एक फ़्रेमवर्क पर बिताया है, तो हो सकता है कि आपको दूसरे और ज़्यादा आधुनिक फ़्रेमवर्क के बारे में जानने का मौका न मिले.
- मान लें कि किसी डेवलपर को सॉफ़्टवेयर डेवलपमेंट या वेब डेवलपमेंट की बुनियादी बातों की पूरी जानकारी नहीं है. इसके बावजूद, उसे फ़्रेमवर्क डेवलपर के तौर पर काम करने के लिए हायर किया जाता है. यह डेवलपर असरदार कोड नहीं लिखता. ऐसे कोडबेस पर काम करना आपके लिए मुश्किल हो सकता है. कुछ मामलों में, ऐसा होने पर बर्नआउट हो सकता है. उदाहरण के लिए, आपको कोड को फिर से लिखना पड़ सकता है या उसकी परफ़ॉर्मेंस को बेहतर बनाना पड़ सकता है, क्योंकि वह धीमा है.
- वेब डेवलपमेंट सीखने के लिए, सबसे पहले वेब डेवलपमेंट, सॉफ़्टवेयर डेवलपमेंट, और सॉफ़्टवेयर इंजीनियरिंग की बुनियादी बातों पर ज़्यादा ध्यान देना चाहिए. इस तरह के मज़बूत फ़ाउंडेशन की मदद से, किसी भी JavaScript फ़्रेमवर्क को तेज़ी से और असरदार तरीके से सीखा जा सकता है.
नतीजा
JavaScript फ़्रेमवर्क और लाइब्रेरी की तुलना करने के तरीके को समझने के लिए आपका धन्यवाद. ग्रीनफ़ील्ड प्रोजेक्ट या सलाहकार के तौर पर काम करने के अलावा, आपको फ़्रेमवर्क या लाइब्रेरी अक्सर नहीं चुननी पड़ेंगी. हालांकि, जब ऐसे फ़ैसले लेने पड़ते हैं, तो विषय के बारे में ज़्यादा जानकारी होने पर, बेहतर फ़ैसले लिए जा सकते हैं.
जैसा कि आपने जाना है कि फ़्रेमवर्क और कुछ मामलों में लाइब्रेरी चुनने से, डेवलपमेंट के अनुभव और असली उपयोगकर्ताओं पर काफ़ी असर पड़ सकता है. जैसे, परफ़ॉर्मेंस पर असर.