फ्रंटएंड डेवलपर्स के लिए लोकप्रिय बिल्ड सिस्टम की तुलना

मैंने देखा कि हाल के दिनों में उन्होंने सिस्टम बनाने पर अधिक ध्यान देना शुरू किया, और इसके प्रभाव में, रातोंरात उनमें से कई ऐसे थे, जो स्पष्ट रूप से, मैं हर किसी का उल्लेख भी नहीं कर सकता था। हाल ही में, मैंने चार प्रणालियाँ सुनी हैं: ग्रंट , गल्प , ब्रंच और गियर । सब कुछ कहीं न कहीं लिखा गया था, लेकिन यह सवाल कभी नहीं उठाया गया कि एक दूसरे के ऊपर क्या फायदे या नुकसान हैं? और यही कारण है कि मैंने सबसे लोकप्रिय बिल्ड-सिस्टम ( Google के अनुसार) का तुलनात्मक विश्लेषण करने का फैसला किया।

लेकिन पहले आपको उन मानदंडों को निर्धारित करने की आवश्यकता है जिनके द्वारा हम इन प्रणालियों का मूल्यांकन करेंगे:

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

अब, मेरा मानना ​​है कि परिचयात्मक भाग के साथ आप अंत और तुलना करना शुरू कर सकते हैं।

1. आरंभ करना

घुरघुराना
कई लेख कहते हैं कि "ग्रंट के लिए लिखना बाद में पढ़ने की तुलना में बहुत आसान है," और वे काफी हद तक सही हैं। इसलिए, इस बिल्ड सिस्टम में प्रवेश करने की दहलीज बेहद कम है: बस एक पृष्ठ पढ़ें कि आपको अपने कॉन्फ़िगरेशन को कैसे लिखना है। आपके प्लग-इन को लिखने में भी अधिक समय और प्रयास नहीं लगता है: पूरी प्रणाली कुछ ही घंटों में सीखने के लिए काफी संभव है। तैयार परियोजनाओं में प्रवेश के लिए सीमा के रूप में, चीजें यहां थोड़ी अलग हैं, ग्रंटफाइल को पढ़ने के लिए पढ़ने के लिए उतना सुविधाजनक नहीं है। ऐसी स्थिति की कल्पना करें जहां आपके पास किसी प्रोजेक्ट से जुड़े 20 प्लगइन्स हों और उनमें से प्रत्येक में निर्भरताएँ हों। उदाहरण के लिए, कॉफ़ी और कम्पास प्लगइन के पूरा होने के बाद ही इसे संक्षिप्त करना समझ में आता है, और इमेजिन को केवल कॉपी कार्य पूरा होने के बाद निष्पादित किया जाना चाहिए। यह ट्रैक करने के लिए सभी बहुत समस्याग्रस्त है, भले ही आप अपने कार्यों का वर्णन करने के लिए टेम्पलेट इंजन का उपयोग न कर रहे हों।

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

गियर
याहू से निर्माण के लिए, सब कुछ बहुत दुख की बात है। साइट का दौरा करने के बाद, हम एक जोरदार बयान देखते हैं कि "उपयोग करने में आसान" प्रणाली उत्कृष्ट है! तदनुसार, मेरा मानना ​​है कि अब वे संक्षेप में और क्षमता से मुझे इस प्रणाली के बारे में बताएंगे कि इसका उपयोग कैसे करें और एक सरल उदाहरण दिखाएं। इसलिए, पहली चीज जो हम देखते हैं, वह ऊपरी दाएं कोने में कोड का एक टुकड़ा और "रन" बटन है। क्या हम कोशिश करेंगे? और नहीं! कुछ समझदार परिणाम के बजाय, हम एक कंसोल त्रुटि देखेंगे। व्यक्तिगत रूप से, इसने मेरी पहली धारणा को थोड़ा बिगाड़ दिया। ठीक है, ठीक है, यह बात नहीं है, चलो आगे बढ़ते हैं - गियर स्थापित करते हुए। js

$ npm install gear gear-lib 

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

ब्रंच
यहां सब कुछ अच्छा है। एक इंट्रो वीडियो जो काफी समझ में आता है, ब्रंच का उपयोग करके एक एप्लिकेशन बनाने की प्रक्रिया का वर्णन करता है और लिंक "अतिरिक्त दस्तावेज के लिए जीथब पर जाएं"। वीडियो का उपयोग करके एक परियोजना को तैनात करने में 30 सेकंड लगते हैं; जनरेटर का उपयोग करते समय, आप तैयार किए गए समाधान महसूस कर सकते हैं और सर्वोत्तम अभ्यास देख सकते हैं। प्रलेखन सभी संभावित स्थितियों का विस्तार से वर्णन करता है, और यद्यपि FAQ ज्ञान का भंडार नहीं है, फिर भी सबसे सामान्य प्रश्नों के उत्तर अभी भी मिल सकते हैं। ब्रंच एक अजीबोगरीब व्यवस्था है, किसी और चीज की तरह नहीं। यह गल्प नहीं है, बहुत कम ग्रंट (मैं आमतौर पर गियर के बारे में चुप रहता हूं - यह किसी अन्य ग्रह से कुछ है)। ब्रंच सभी उपकरण प्रदान करता है जो एक डेवलपर को एक वर्कफ़्लो को स्वचालित करने की आवश्यकता हो सकती है, और यह बहुत आसान बनाता है।

2. प्रदर्शन

घुरघुराना
शालीनता से जमीन खो रही है। सबसे पहले, नोड.जेएस का उपयोग करना और मल्टीथ्रेडिंग का उपयोग नहीं करना केवल दुख की बात है। दूसरे, अतिरिक्त प्लगइन्स के बिना, ग्रंट कैशिंग संशोधित फ़ाइलों के साथ काम करने में सक्षम नहीं है। यानी यदि हम 10,000 कॉफी फाइलों में से 1 को संशोधित करते हैं, तो सभी दस हजार का पुनर्निर्माण किया जाएगा। बेशक, ग्रिंथ-समवर्ती का उपयोग करके मल्टीथ्रेडिंग को उकसाया जा सकता है, और ग्रंट-नए का उपयोग करके कैशिंग के साथ काम किया जा सकता है, लेकिन यह ग्रंट के बंदर-पैच की तरह एक पूर्ण कार्यान्वयन की तुलना में अधिक दिखता है। लेकिन यह सब नहीं है। डेटा स्ट्रीम के साथ काम करने के लिए ग्रंट में बहुत टेढ़ा तंत्र होता है। कल्पना करें कि हमें पहले कॉफी इकट्ठा करने की आवश्यकता है, फिर सभी फाइलों को मिलाएं, उन्हें छोटा करें और परीक्षण चलाएं। ये सभी क्रियाएं फाइलों के एक ही सेट से जुड़ी हैं, हालांकि ग्रंट इसे नहीं समझते हैं और प्रत्येक कार्य के लिए अपने स्वयं के इनपुट-आउटपुट स्ट्रीम का उपयोग करते हैं, अर्थात्। हर बार यह फाइलों को फिर से पढ़ता है और उनके लिए एक विशेष कार्य चलाता है, जिसके बाद यह डिस्क पर वापस परिणाम लिखता है और इसी तरह जब तक सभी कार्य पूरा नहीं हो जाते। आपको यह स्वीकार करना चाहिए कि ये ऑपरेशन बेहद महंगे हैं, विशेष रूप से यह देखते हुए कि हम एक ही उद्देश्य के लिए जानकारी के एक इनपुट / आउटपुट स्ट्रीम का उपयोग कर सकते हैं और रैम में फ़ाइलों के रूप में एक ही विषय पर सभी ऑपरेशन कर सकते हैं। यह एक बेहतर प्रदर्शन परिणाम प्राप्त करेगा।

घूंट
ग्रंट की तुलना में, यह बिल्ड सिस्टम प्रदर्शन में बेहतर है। अपने पूर्ववर्ती के विपरीत, यह बॉक्स से अलग उपप्रकारों में असंबंधित कार्य ढेर का प्रदर्शन करने की क्षमता का समर्थन करता है। यह गति में एक बहुत ठोस वृद्धि देता है। यह भी ध्यान देने योग्य है कि कई फ़ाइल कार्यों को करते समय गुलप केवल एक इनपुट / आउटपुट स्ट्रीम का उपयोग करता है। यह ग्रंट का उपयोग करने की तुलना में थोड़ा अलग वास्तुशिल्प समाधान द्वारा प्राप्त किया गया है। यदि एक ग्रंटफाइल बनाते समय आप विभिन्न कार्यों में फ़ाइलों के लिए एक ही मास्क निर्दिष्ट करेंगे, तो गुलफ़िल में स्थिति बिल्कुल विपरीत है: हम फ़ाइलों से नृत्य करते हैं, कार्यों से नहीं। एक उदाहरण:

ग्रंटफाइल से अंश:

 ... concat: { dist: { src: ['src/**/*.js'], dest: 'dist/app.js' } }, jshint: { files: ['src/**/*.js'] } ... 

गुलफ़िले से अंश:

 gulp.task('scripts', function() { gulp.src(['app/src/**/*.js']) .pipe(concat('dest.js')) .pipe(jshint()) .pipe(gulp.dest('dist/build')) }) 

जैसा कि हम देख सकते हैं, ग्रंट को सभी प्लगइन्स के लिए src की आवश्यकता है। तदनुसार, यह आवश्यक है ताकि एक अनुक्रमिक लॉन्च के दौरान, हमारी बिल्ड-सिस्टम यह समझ सके कि इसमें किन फ़ाइलों को हेरफेर करने की आवश्यकता है। ग्रंट के विपरीत, गुल्प को केवल उस कार्य के लिए src निर्दिष्ट करने की आवश्यकता होती है जिसमें कुछ फ़ाइलों को निष्पादित किया जाएगा, जिससे I / O प्रक्रिया को केवल एक बार करने का अवसर मिलेगा, जो हमें असेंबली के दौरान अधिकतम प्रदर्शन प्रदान करेगा। इसके अलावा, जैसा कि मैंने ऊपर कहा था, गुलप आपको "बॉक्स से बाहर" मल्टीथ्रेडिंग के साथ काम करने की अनुमति देता है, अधिक सटीक रूप से, यह नहीं कि "आपको काम करने की अनुमति देता है", लेकिन "मल्टीथ्रेडेड मोड में डिफ़ॉल्ट रूप से काम करता है।" इसका मतलब है कि डिफ़ॉल्ट रूप से, सभी कार्य एक साथ अलग-अलग थ्रेड में लॉन्च किए जाएंगे। लेकिन तब क्या करें जब हमारे कॉनटैट को कॉफी के बाद ही निष्पादित किया जाना चाहिए? उस मामले में, हम सिर्फ एक निर्भरता बना सकते हैं! यह आवश्यकता के समान है। जेएस, खुद के लिए न्यायाधीश:

 var gulp = require('gulp'); // takes in a callback so the engine knows when it'll be done gulp.task('one', function(cb) { // do stuff -- async or otherwise cb(err); // if err is not null and not undefined, the run will stop, and note that it failed }); // identifies a dependent task must be complete before this one begins gulp.task('two', ['one'], function() { // task 'one' is done now }); gulp.task('default', ['one', 'two']); 

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

गियर, ब्रंच : गुल्प के समान सिद्धांत पर काम करते हैं - वे प्रक्रियाओं के अधिकतम समानांतर हैं। हैरानी की बात है, केवल ग्रंट रहता है, जो इस "बॉक्स से बाहर" का समर्थन नहीं करता है।

निष्कर्ष : एक मामूली बेंचमार्क पर (मानक ग्रंटफाइल, 10 जेएस, 10 सीएसएस पर आधारित), यह निकला कि मेरी मशीन पर, प्रदर्शन के आधार पर, हम निम्नलिखित का पालन कर सकते हैं। परिणाम:
पहली जगह गियर (300ms)
दूसरा स्थान गुल्प (~ + 30ms)
तीसरा स्थान ब्रंच (~ + 80ms)
चौथा स्थान ग्रंट (~ + 180ms)

3. प्रलेखन

घुरघुराना
ग्रंट ठीक कर रहा है। प्रलेखन कॉम्पैक्ट है और किसी भी आवश्यकताओं को पूरी तरह से संतुष्ट करता है। सिस्टम के साथ काम करने के लिए आपको जो कुछ भी चाहिए वह कार्यालय में मिल सकता है। वेबसाइट। कोई "ब्यूट" और अपवाद नहीं हैं - ग्रंट अच्छी तरह से प्रलेखित है: सरल और कैपेसिटिव। यहां आप एक ग्रंटफाइल का एक उदाहरण पा सकते हैं, अपने स्वयं के कॉन्फ़िगरेशन को शुरू करने और बनाने के लिए सभी चरण। क्या यह एक अच्छा उदाहरण वाला वीडियो पर्याप्त नहीं है, लेकिन ग्रंट जैसे प्रलेखन के साथ इसकी आवश्यकता नहीं है।

घूंट
ग्रंट की ऊँची एड़ी के जूते पर गुलदस्ता: प्रलेखन लगभग एक-पर-एक अपने पूर्ववर्ती के प्रलेखन को दोहरा रहा है, सिवाय इसके कि यह साइट पर नहीं, बल्कि गितूब पर निहित है। हालांकि, मतभेद हैं: सबसे पहले, ग्रंट के गेट स्टार्टेड में तैयार ग्रंटफाइल है जिसे आप तुरंत आज़मा सकते हैं। दुर्भाग्य से, वही गुलप के लिए नहीं कहा जा सकता है। यह पृष्ठ सरलता से समझाएगा कि इसे कैसे स्थापित किया जाए और कैसे चलाया जाए। और फिर, वे कहते हैं, गोदी के माध्यम से पत्ता और आप की जरूरत के लिए देखो। और इस तथ्य के बावजूद कि "आपको क्या चाहिए" खोजना बिल्कुल मुश्किल नहीं है, ये अनावश्यक इशारे हैं जो स्पष्ट रूप से इस प्रणाली के साथ काम करना आसान नहीं बनाते हैं। यह स्पष्ट है कि कोई भी व्यक्ति जो कम से कम एक बार विधानसभा प्रणाली को अपने हाथों में रखता है, वह प्रतिनिधित्व करता है कि क्या करने की आवश्यकता है, लेकिन यह मत भूलो कि ऐसे खंड केवल उन लोगों के लिए लिखे गए हैं जिन्हें इस बात की बहुत कम समझ है कि इसके साथ कैसे काम किया जाए। दूसरे, इस प्रणाली का उपयोग कैसे करना है और इसे किस तरफ देखना है, इस बारे में कोई स्पष्ट दिशानिर्देश नहीं है। मुझे यकीन है कि जो लोग अपनी परियोजनाओं की विधानसभा को स्वचालित करने के लिए गुलप को अपनी पहली प्रणाली के रूप में चुनते हैं, उन्हें तीसरे पक्ष के संसाधनों पर उदाहरणों के साथ जानकारी देखने के लिए मजबूर किया जाएगा।

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

ब्रंच
गिट में 5 फाइलें हैं जो सिस्टम और 1 एफएक्यू के साथ काम करने के तरीके के बारे में विस्तार से बताती हैं। जानकारी सरल है, पढ़ने में आसान है, लेकिन फिर भी मैं कुछ और चाहूंगा। सिस्टम के बारे में इंटरनेट पर बहुत कम जानकारी है, इसलिए पूरा ब्रंच इकोसिस्टम अपने गिट रिपॉजिटरी और फोरम के इर्द-गिर्द घूमता है।

4. प्लगइन्स

ग्रन्ट : 2000+ प्लगइन्स, हालांकि कुछ रिलीज़ के बाद से अपडेट नहीं किए गए हैं और / या किसी भी रिलीज़ को रिलीज़ नहीं किया है
गुल : 200+ प्लगइन्स, और संख्या तेजी से बढ़ रही है
गियर : हुह? प्लग इन? npmjs.org का कहना है कि 5 प्लगइन्स के साथ गियर-लिब के अलावा, इस कलेक्टर के लिए कुछ भी मौजूद नहीं है।
ब्रंच : 50+ प्लगइन्स, बहुत धीरे-धीरे बढ़ने की प्रवृत्ति

सारांश

घुरघुराना
यह अनुमान लगाना कठिन है कि ग्रंट अब किस तरह विकसित हो सकता है। नवीनतम चेंजलॉग्स को देखते हुए, डेवलपर्स केवल बढ़ती उत्पादकता का ख्याल रखने की तुलना में सभी दृश्य दोषों को दूर करना चाहते हैं। और व्यक्तिगत रूप से, यह मुझे बहुत दुखी करता है। मैं लंबे समय से इस उपकरण का उपयोग कर रहा हूं, मैं इसका उपयोग कर रहा हूं, लेकिन मैं देखता हूं कि यह कैसे धीरे-धीरे मर रहा है, और हाल ही में, अनुकूलित कलेक्टर इसकी जगह ले रहे हैं। बेशक, इस तरह, ग्रंट के जल्द ही मरने की संभावना नहीं है। लेकिन मैं अधिक आधुनिक प्रणालियों के प्रति उपयोगकर्ताओं के एक मजबूत बहिर्वाह महसूस करता हूं।

घूंट
ग्रंट के बाद, मेरे लिए यह वास्तव में "ताजी हवा की सांस" है। मुझे वास्तव में इस परियोजना के विकास की दिशा पसंद है, अगर इसके लेखक "बाहर जला नहीं", तो मुझे लगता है कि यह चाची को बदलने में सक्षम होगा।

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

ब्रंच
एक अच्छी परियोजना, बहुत उच्च गुणवत्ता वाले कार्यान्वयन के साथ। यह मेरे लिए थोड़ा अजीब है कि इस तरह की क्षमता वाला एक प्रोजेक्ट इतनी धीमी गति से विकसित हो रहा है। विकास की गति शायद एकमात्र ऐसी चीज है जिसमें इस परियोजना का अभाव है।

PS मुझे लेख को बेहतर बनाने के लिए आपकी टिप्पणियों और सुझावों को स्वीकार करने में खुशी होगी, और मैं किसी भी जानकारी के लिए आभारी रहूंगा जो इसे पूरक कर सकती है।