फेसबुक के रिएक्ट बनाम वेब कंपोनेंट्स (पॉलिमर) के पेशेवरों और विपक्ष


521

आगामी वेब कम्पोनेंट्स स्पेक और इसके विपरीत (या शायद अधिक सेब से सेब की तुलना Google के पॉलीमर लाइब्रेरी में होगी) पर फेसबुक की प्रतिक्रिया के मुख्य लाभ क्या हैं ?

के अनुसार इस JSConf यूरोपीय संघ बात और मुखपृष्ठ प्रतिक्रिया, प्रतिक्रिया के मुख्य लाभ हैं:

  • घटक मॉडल का उपयोग करके सामंजस्य घटाना और बढ़ाना
  • अमूर्तता, रचना और अभिव्यक्ति
  • वर्चुअल डोम एंड सिंथेटिक इवेंट्स (जिसका मूल अर्थ है कि वे डोम और उसके इवेंट सिस्टम को पूरी तरह से लागू करते हैं)
    • IE 8 पर आधुनिक HTML5 ईवेंट सामान सक्षम करता है
    • सर्वर-साइड प्रतिपादन
    • testability
    • एसवीजी, वीएमएल, और के लिए बाइंडिंग <canvas>

इस वर्चुअल DOM कॉन्सेप्ट (स्पष्ट रूप से) को छोड़कर लगभग सभी चीजें वेब ब्राउजर के माध्यम से मूल रूप से ब्राउज़रों में एकीकृत की जा रही हैं। मैं देख सकता हूं कि पुराने ब्राउज़रों का समर्थन करने के लिए वर्चुअल डोम और सिंथेटिक इवेंट्स आज कैसे फायदेमंद हो सकते हैं, लेकिन लॉन्ग टर्म में पैर में अपने आप को शूट करने की तरह देशी ब्राउज़र कोड का एक बड़ा हिस्सा नहीं फेंक रहे हैं? जहां तक ​​आधुनिक ब्राउज़रों का सवाल है, क्या यह अनावश्यक अनावश्यक ओवरहेड / व्हील के सुदृढीकरण का काम नहीं है?

यहां कुछ चीजें हैं जो मुझे लगता है कि रिएक्ट गायब है कि वेब घटक आपके लिए ध्यान रखेंगे। यदि मैं गलत हूं तो मुझे सही करों।

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

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

8
मैंने रिएक्ट, एंगुलर और नॉकआउट को देखा है। मुझे लगता है कि ui templating, डेटा और बाइंडिंग के पृथक्करण के संदर्भ में नॉकआउट 'सबसे स्वच्छ' है। मैं प्रतिक्रिया पसंद करना चाहता था, लेकिन मैं एक साधारण कॉम्बोक्स बनाने की कोशिश कर रहा था, मुझे एहसास हुआ कि मैं अधिक कोड लिख रहा था और html टेम्प्लेटिंग के साथ प्रतिपादन तर्क का मिश्रण कर रहा था..ज्यादा से ज्यादा मैं html / jina2 जैसे कुछ का उपयोग करके करूँगा। मुझे लगता है कि ये पुस्तकालय / एप हमें आगे नहीं बढ़ा रहे हैं। रिएक्ट के बारे में सबसे अच्छी बात यह है कि आभासी डोम हेरफेर है, लेकिन मैं देख सकता हूं कि बाद में अन्य स्थापित रूपरेखाओं में जल्द ही आ रहा है।
mike01010

41
मैं बहुत हैरान हूं (और खुश भी!) कि यह सवाल "मुख्य रूप से राय-आधारित" के रूप में बंद नहीं हुआ।
आइकनोकॉस्ट

4
यदि आप किसी भी प्रकार का टेम्प्लेट कर रहे हैं तो "स्क्रिप्टिंग भाषा में स्क्रिप्ट" और "मार्कअप भाषा में मार्कअप" लिखना संभव नहीं है। कोणीय, बहुलक, आदि HTML में एम्बेडेड टेम्पलेट का उपयोग करते हैं। रिएक्ट JS (JSX) में एम्बेडेड टेम्पलेट DSL का उपयोग करता है। HTML में DSL को एम्बेड करने के साथ समस्या यह है कि JS से मान प्राप्त करने के लिए गुंजाइश कैसे स्थापित की जाए। यह एंगुलर के जटिल $ स्कोप सिस्टम की ओर जाता है। JSX में, दूसरी ओर, टेम्प्लेट में वेरिएबल्स का दायरा सिर्फ JS स्कोप है - मुझे यह बहुत कम भ्रमित लगता है।
एंडी

3
फिलहाल रिएक्ट घटक (जब तक कि बुरी तरह से लिखा नहीं गया है) किसी भी डोम-बाउंड ढांचे में उसी की तुलना में तेज होगा। वी-डोम और डिफरेंट-इंग मैजिक प्रतिक्रिया की यूएसपी है। मेरा कहना यह है कि - ब्रोकर अपनी मूल विशेषता में वैसा-वैसा निर्माण नहीं करेंगे। उन्हें क्या रोकता है, और यदि कुछ भी नहीं (उन्हें रोकता है) तो रिएक्ट का नेतृत्व संभवतः अल्पकालिक होने जा रहा है।
फास्टट्रेनोफेक्ट्स 6

जवाबों:


664

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

आपकी अधिकांश चिंताएँ वास्तव में राय और व्यक्तिगत पसंद की बात हैं, लेकिन मैं जितना हो सके उतने उत्तर देने की कोशिश करूँगा:

देशी बनाम संकलित

वेनिला जावास्क्रिप्ट में जावास्क्रिप्ट लिखें, सीएसएस में सीएसएस लिखें, एचटीएमएल में एचटीएमएल लिखें।

दिन में गर्म बहसें हुईं कि क्या किसी को  हाथ से मूल विधानसभा लिखनी चाहिए या आपके लिए कंपाइलर जनरेट कोड बनाने के लिए C जैसी उच्च स्तरीय भाषा का उपयोग करना चाहिए । पहले भी कि लोगों पर विश्वास करने से इनकार कर अस्सेम्ब्लेर्स और लिखने के लिए प्राथमिकता दी देशी मशीन कोड अलग-अलग ( और मैं मजाक नहीं कर रहा हूँ )।

इस बीच, आज बहुत से लोग हैं जो HTML को Haml या Jade , CSS in Sass या Less और जावास्क्रिप्ट में CoffeeScript या TypeScript में लिखते हैं । यह वहाँ है। यह काम करता हैं। कुछ लोग इसे पसंद करते हैं, कुछ नहीं।

मुद्दा यह है कि वेनिला जावास्क्रिप्ट में सीएसएस, सीएसएस में सीएसएस और एचटीएमएल में HTML नहीं लिखने में मौलिक रूप से कुछ भी गलत नहीं है । यह वास्तव में वरीयता की बात है।

आंतरिक बनाम बाहरी डीएसएल

 इसके बजाय शैडो डीओएम रिएक्ट का उपयोग करने वाले स्टाइल एनकैप्सुलेशन में यह है, जिसे जावास्क्रिप्ट में सीएसएस लिखने की आवश्यकता होती है। सुंदर नहीं।

सुंदर या नहीं, यह निश्चित रूप से अभिव्यंजक है। जावास्क्रिप्ट एक बहुत शक्तिशाली भाषा है, सीएसएस की तुलना में बहुत अधिक शक्तिशाली (यहां तक ​​कि सीएसएस प्रीप्रोसेसर में से कोई भी)। यह इस बात पर निर्भर करता है कि आप उन चीजों के लिए आंतरिक या बाहरी DSLs पसंद करते हैं या नहीं। फिर से, वरीयता का मामला।

(नोट: मैं रिएक्ट में इनलाइन शैलियों के बारे में बात कर रहा था जिसे मूल प्रश्न में संदर्भित किया गया था।)

DSLs के प्रकार - स्पष्टीकरण

अद्यतन: मेरे उत्तर को पढ़ने के कुछ समय बाद इसे लिखने के बाद मुझे लगता है कि मुझे यह समझाने की आवश्यकता है कि मेरा यहाँ क्या मतलब है। डीएसएल एक डोमेन-विशिष्ट भाषा है और यह आंतरिक भी हो सकती है (जावास्क्रिप्ट जैसी होस्ट भाषा का सिंटैक्स का उपयोग करना - उदाहरण के लिए जेएसएक्स के बिना रिएक्ट, या ऊपर उल्लिखित रिएक्ट में इनलाइन शैलियों की तरह) या यह बाहरी हो सकता है (एक अलग सिंटैक्स का उपयोग करके) होस्ट भाषा की तुलना में - जैसे इस उदाहरण में जावास्क्रिप्ट (जावास्क्रिप्ट के अंदर एक बाहरी DSL) को इनलाइन किया जाएगा।

यह भ्रामक हो सकता है क्योंकि कुछ साहित्य उन प्रकार के डीएसएल का वर्णन करने के लिए "आंतरिक" और "बाहरी" की तुलना में अलग-अलग शब्दों का उपयोग करते हैं। कभी-कभी "आंतरिक" के बजाय "एम्बेडेड" का उपयोग किया जाता है, लेकिन "एम्बेडेड" शब्द का अर्थ अलग-अलग हो सकता है - उदाहरण के लिए लूआ को "लुआ: एक एक्सटेंसिबल एम्बेडेड भाषा" के रूप में वर्णित किया गया है, जहां एम्बेडेड का एम्बेडेड (आंतरिक) DSL के साथ कुछ भी नहीं है कौन सा अर्थ यह काफी विपरीत है - एक बाहरी डीएसएल) लेकिन इसका मतलब है कि यह उसी अर्थ में एम्बेडेड है जो कहते हैं, SQLite एक एम्बेडेड डेटाबेस है। यहाँ तक कि eLua भी है जहाँ "e" का अर्थ एक तीसरे अर्थ में "एम्बेडेड" है - जो कि एम्बेडेड सिस्टम के लिए है! इसलिए मुझे "एम्बेडेड डीएसएल" शब्द का उपयोग करना पसंद नहीं है क्योंकि एलुआ जैसी चीजें "डीएसएल" हो सकती हैं जो कि "एम्बेडेड डीएसएल" नहीं होने पर भी दो अलग-अलग इंद्रियों में "एम्बेडेड" होती हैं!

चीजों को बदतर बनाने के लिए कुछ परियोजनाएं मिश्रण के लिए और भी अधिक भ्रम का परिचय देती हैं। उदाहरण के लिए। फ्लैटिरॉन टेम्प्लेट को "डीएसएल-फ्री" के रूप में वर्णित किया गया है, जबकि वास्तव में यह सिंटैक्स जैसे आंतरिक डीएसएल का एक आदर्श उदाहरण है:map.where('href').is('/').insert('newurl');

यह कहा गया है, जब मैंने लिखा था "जावास्क्रिप्ट एक बहुत शक्तिशाली भाषा है, सीएसएस की तुलना में बहुत अधिक शक्तिशाली है (यहां तक ​​कि सीएसएस के किसी भी पूर्ववर्ती सहित)। यह इस बात पर निर्भर करता है कि आप उन प्रकार की चीजों के लिए आंतरिक या बाहरी DSLs पसंद करते हैं। प्राथमिकता का विषय। " मैं उन दो परिदृश्यों के बारे में बात कर रहा था:

एक:

/** @jsx React.DOM */
var colored = {
  color: myColor
};
React.renderComponent(<div style={colored}>Hello World!</div>, mountNode);

दो:

// SASS:
.colored {
  color: $my-color;
}
// HTML:
<div class="colored">Hello World!</div>

पहले उदाहरण में उस प्रश्न का वर्णन किया गया है जो इस प्रकार है: "जावास्क्रिप्ट में सीएसएस लिखना। सुंदर नहीं।" दूसरा उदाहरण सैस का उपयोग करता है। जबकि मैं मानता हूं कि सीएसएस लिखने के लिए जावास्क्रिप्ट का उपयोग करना सुंदर नहीं हो सकता है ("सुंदर" की कुछ परिभाषाओं के लिए) लेकिन ऐसा करने का एक फायदा है।

मेरे पास सास में चर और कार्य हो सकते हैं लेकिन क्या वे शाब्दिक रूप से स्कोप या गतिशील रूप से स्कूप किए गए हैं? क्या वे सांख्यिकीय या गतिशील रूप से टाइप किए गए हैं? जोरदार या कमजोर रूप से? संख्यात्मक प्रकारों के बारे में क्या? प्रकार का फैलाव? कौन से मूल्य सत्य हैं और कौन से मिथ्या हैं? क्या मेरे पास उच्च-क्रम के कार्य हो सकते हैं? प्रत्यावर्तन? टेल कॉल? लेक्सिकल क्लोजर? क्या उनका मूल्यांकन सामान्य क्रम या आवेदक क्रम में किया जाता है? क्या आलसी या उत्सुक मूल्यांकन है? क्या मूल्य या संदर्भ द्वारा पारित कार्यों के तर्क हैं? क्या वे परस्पर हैं? अपरिवर्तनीय? लगातार? वस्तुओं के बारे में क्या? क्लासेस? प्रोटोटाइप? विरासत?

वे तुच्छ प्रश्न नहीं हैं और फिर भी मुझे उनके उत्तर जानने हैं, यदि मैं सैस या कम कोड को समझना चाहता हूं। मैं जावास्क्रिप्ट के लिए उन उत्तरों को पहले से ही जानता हूं, इसलिए इसका मतलब है कि मैं पहले से ही उन स्तरों पर हर आंतरिक डीएसएल (इनलाइन शैलियों की तरह) को समझता हूं, इसलिए यदि मैं रिएक्ट का उपयोग करता हूं तो मुझे उन लोगों के जवाबों का केवल एक सेट जानना होगा (और कई इसी तरह के) ) प्रश्न, जब मैं उदाहरण के लिए उपयोग करता हूं। सैस और हैंडलबार्स तो मुझे उन उत्तरों के तीन सेटों को जानना होगा और उनके निहितार्थ को समझना होगा।

यह कहना नहीं है कि एक तरीका या दूसरा हमेशा बेहतर होता है, लेकिन हर बार जब आप किसी अन्य भाषा को मिश्रण से परिचित कराते हैं तो आप कुछ ऐसी कीमत अदा करते हैं जो पहली नज़र में स्पष्ट नहीं हो सकती है, और यह कीमत जटिलता है।

मुझे आशा है कि मैंने स्पष्ट किया कि मैं मूल रूप से थोड़ा सा क्या था।

अनिवार्य तथ्य

दो तरफा बंधन

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

अपडेट: पीट हंट द्वारा एक और बात भी देखें: पूर्वानुमानित रहें, सही नहीं: कार्यात्मक डोम प्रोग्रामिंग

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

अद्यतन 3: एक और दिलचस्प लेख जो अच्छी तरह से समझाता है कि ऊपर उल्लिखित कुछ मुद्दों पर रिएक्टजेस की फ्लक्स में गिरावट आ रही है - रीफ्लक्सजेएस (फ्लक्स से प्रेरित यूनिडायरेक्शनल डेटा फ्लो एप्लीकेशन आर्किटेक्चर के लिए एक सरल पुस्तकालय) के लेखक, मिकेल ब्रैसमैन द्वारा रिएक्टजेएस के साथ एमवीसी का उपयोग नहीं करना

अद्यतन 4: Ember.js वर्तमान में दो-तरफ़ा डेटा बाइंडिंग से दूर जा रहा है और भविष्य के संस्करणों में यह डिफ़ॉल्ट रूप से वन-वे होगा। देखें: 15 नवंबर, 2014 को टोरंटो में एम्बरगार्टन संगोष्ठी से स्टीफन पेनर द्वारा एम्बर की भविष्य की बातचीत।

अद्यतन 5: यह भी देखें: एम्बर 2.0 आरएफसी की सड़क - टॉम डेल द्वारा पुल अनुरोध में दिलचस्प चर्चा :

"जब हमने मूल टेम्प्लेटिंग परत को डिज़ाइन किया, तो हमें लगा कि सभी डेटा बाइंडिंग को दो-तरफ़ा बनाना बहुत हानिकारक नहीं है: यदि आप दो-तरफ़ा बाइंडिंग सेट नहीं करते हैं, तो यह वास्तव में एक तरह से बाध्यकारी है!

हमने तब से महसूस किया है कि (रिएक्ट में हमारे दोस्तों से कुछ मदद के साथ), यह घटक अपने बच्चों को डेटा भेजने में सक्षम होना चाहते हैं, जो बिना किसी परिवर्तन के म्यूटेशन के गार्ड के रूप में हैं।

इसके अतिरिक्त, घटकों के बीच संचार अक्सर घटनाओं या कॉलबैक के रूप में सबसे स्वाभाविक रूप से व्यक्त किया जाता है । यह एम्बर में संभव है, लेकिन दो-तरफ़ा डेटा बाइंडिंग का प्रभुत्व अक्सर लोगों को एक संचार चैनल के रूप में दो-तरफ़ा बाइंडिंग का उपयोग करने का एक मार्ग नीचे ले जाता है । अनुभवी एम्बर डेवलपर्स (आमतौर पर) यह गलती नहीं करते हैं, लेकिन यह बनाने के लिए एक आसान है। " [जोर जोड़ा]

मूल निवासी बनाम वी.एम.

देशी ब्राउज़र समर्थन (पढ़ें "तेज़ होने की गारंटी")

अब अंत में कुछ ऐसा है जो राय का विषय नहीं है।

वास्तव में यहाँ यह बिल्कुल दूसरा तरीका है। बेशक "देशी" कोड सी ++ में लिखा जा सकता है लेकिन आपको क्या लगता है कि जावास्क्रिप्ट इंजन में लिखा जाता है?

तथ्य के रूप में जावास्क्रिप्ट इंजन वास्तव में उन अनुकूलन में अद्भुत हैं जो वे आज का उपयोग करते हैं - और न केवल वी 8 और भी, स्पाइडरमोंकी और यहां तक ​​कि चक्र भी इन दिनों चमकता है। और ध्यान रखें कि जेआईटी संकलक के साथ कोड न केवल मूल के रूप में यह संभवतः हो सकता है, बल्कि ऐसे समय अनुकूलन अवसर भी हैं जो किसी भी संकलित कोड में बस करना असंभव है।

जब लोग सोचते हैं कि जावास्क्रिप्ट धीमा है, तो उनका मतलब आमतौर पर जावास्क्रिप्ट होता है जो DOM तक पहुँचता है। DOM धीमा है। यह मूल है, सी ++ में लिखा गया है और फिर भी इसे लागू करने की जटिलता के कारण नरक के रूप में धीमा है।

अपना कंसोल खोलें और लिखें:

console.dir(document.createElement('div'));

और देखते हैं कि कितने गुण एक खाली divतत्व है जो डोम से जुड़ा नहीं है, उसे लागू करना है। ये केवल पहले स्तर के  गुण हैं जो "स्वयं के गुण" हैं। प्रोटोटाइप श्रृंखला से विरासत में नहीं मिला:

संरेखित करें, onwaiting, onvolumechange, ontimeupdate, ऑनसाइट, onubmit, onstalled, onshow, onseeking, onseeked, onscroll, onscroll, onreset, onratechange, onprogress, onprogress, onplaying, onplay, onmsem, onmheem onmouseenter, onmousedown, onloadstart, onloadedmetadata, onloadeddata, onloadup, onkeyup, onkeypress, onkeydown, oninvalid, oninput, onfocus, onerror, onended, onemptied, onemptied, ondurationchange, ondragstart, ondragartart, ondartart, onart, oncontextmenu, onclose, onclick, onchange, oncanplaythrough, oncanplay, oncancel, onblur, onabort, spellcheck, isContentEditable, contentEditable, externalText, innerText, accessKey, हिडन, webkitdropzone, dragIable, tabIndex, dIndexx, dIndexफ़र्स्टफेलचाइल्ड, बच्चे, नेक्स्टइमलीस्लिंग, पिछलेइलीमेंट सिब्लिंग, ऑनव्हील, ऑनवेबकिटफुलसर्केलरेंचर, ऑनवेबकिटफुलसर्केलचेंज, ऑनसेप्टस्टार्ट, ऑनसर्च, ऑनपेक, ऑनकॉपी, ऑनकोपी, ऑनबीस्पस्ट, ऑनबीसबेटी, ओबेबेल्ली, टॉबेबेल्ली, टॉबेबेल्ली क्लायंटहाइट, क्लाइंटविट, क्लाइंटटॉप, क्लाइंटलिफ्ट, ऑफसेटपार्टेंट, ऑफसेटहाइट, ऑफसेटविट, ऑफसेटटाइप, ऑफसेटलिफ्ट, लोकलनेम, उपसर्ग, नेमस्पेसि, आईडी, शैली, विशेषताएँ, टैगनाम, पेरेंटनेम, पैरेंटइमेंट, टेक्स्टकॉन्टेंट, बेसुरंट, बेसक्रीपी, आईडीएक्वायमेंट, एनएफ़टी। parentNode, नोडटाइप, नोडवैल्यू, नोडनेमoncopy, onbeforepaste, onbeforecut, onbeforecopy, webkitShadowRoot, डेटासेट, classList, क्लासनाम, आउटरएचटीएमएल, इनरएचटीएमएल, स्क्रॉलहाइट, स्क्रॉलविट, स्क्रोलटॉप, स्क्रोल लाइट, क्लाइंटहाइट, क्लाइंटहाइट, क्लायंट राइट, क्लायंट, क्लाइंट। नामस्थान, आईडी, शैली, विशेषताएँ, टैगनाम, पेरेंटमेंट, टेक्स्टकंटेंट, बेसुरि, ओनरडिमेंटल, नेक्स्टबेलिंग, पिछलीसालिंग, अंतिमचिल्ड, फर्स्ट चाइल्ड, चाइल्डकोड, पैरेंटकोड, नोडटाइप, नोडवैल्यू, नोडनेमoncopy, onbeforepaste, onbeforecut, onbeforecopy, webkitShadowRoot, डेटासेट, classList, क्लासनाम, आउटरएचटीएमएल, इनरएचटीएमएल, स्क्रॉलहाइट, स्क्रॉलविट, स्क्रोलटॉप, स्क्रोल लाइट, क्लाइंटहाइट, क्लाइंटहाइट, क्लायंट राइट, क्लायंट, क्लाइंट। नामस्थान, आईडी, शैली, विशेषताएँ, टैगनाम, पेरेंटमेंट, टेक्स्टकंटेंट, बेसुरि, ओनरडिमेंटल, नेक्स्टबेलिंग, पिछलीसालिंग, अंतिमचिल्ड, फर्स्ट चाइल्ड, चाइल्डकोड, पैरेंटकोड, नोडटाइप, नोडवैल्यू, नोडनेमपेरेंटलीमेंट, टेक्स्टकंटेंट, बेसुरि, ओनरडिमेंटमेंट, नेक्स्टबेलिंग, पिछलेसिबलिंग, लास्ट चाइल्ड, फर्स्ट चाइल्ड, चाइल्डकोड, पैरेंटकोड, नोडटाइप, नोडवैल, नोडफ्लेमपेरेंटलीमेंट, टेक्स्टकंटेंट, बेसुरि, ओनरडिमेंटमेंट, नेक्स्टबेलिंग, पिछलेसिबलिंग, लास्ट चाइल्ड, फर्स्ट चाइल्ड, चाइल्डकोड, पैरेंटकोड, नोडटाइप, नोडवैल, नोडफ्लेम

उनमें से कई वास्तव में नेस्टेड ऑब्जेक्ट हैं - divअपने ब्राउज़र में एक खाली मूल के दूसरे स्तर (खुद के) गुणों को देखने के लिए, इस फिडेल को देखें ।

मैं गंभीरता से मतलब है, हर एक div नोड पर onvolumechange property? क्या यह एक गलती है? नहीं, यह केवल एक विरासत डोम स्तर 0 ईवेंट हैंडलर में से एक का पारंपरिक इवेंट मॉडल संस्करण है "जो सभी HTML तत्वों द्वारा समर्थित होना चाहिए , क्योंकि दोनों सामग्री विशेषताएँ और IDL विशेषताएँ" [जोर जोड़ा गया] HTML की धारा 6.1.6.2 में W3C द्वारा - इसके आसपास कोई रास्ता नहीं।

इस बीच, ये फर्जी-डोम के पहले स्तर के गुण हैं divरिएक्ट में:

सहारा, _owner, _lifeCycleState, _pendingProps, _pendingCallbacks, _pendingOwner

काफी अंतर है, है ना? वास्तव में यह पूरी वस्तु JSON ( LIVE DEMO ) के लिए अनुक्रमित है , क्योंकि हे वास्तव में आप  इसे JSON में अनुक्रमित कर सकते हैं क्योंकि इसमें कोई परिपत्र संदर्भ नहीं है - देशी DOM की दुनिया में अकल्पनीय कुछ ( जहां यह सिर्फ एक अपवाद फेंक देगा। ):

{
  "props": {},
  "_owner": null,
  "_lifeCycleState": "UNMOUNTED",
  "_pendingProps": null,
  "_pendingCallbacks": null,
  "_pendingOwner": null
}

यह बहुत मुख्य कारण है कि रिएक्ट देशी ब्राउज़र डोम की तुलना में अधिक तेज़ हो सकता है - क्योंकि इसमें इस गड़बड़ को लागू नहीं करना है ।

देखें स्टीवन Luscher द्वारा इस प्रस्तुति देशी डोम C ++ लिखित या एक नकली डोम जावास्क्रिप्ट में पूरी तरह से लिखा: क्या तेजी से होता है देखने के लिए। यह बहुत ही निष्पक्ष और मनोरंजक प्रस्तुति है।

अपडेट: भविष्य के संस्करणों में Ember.js एक वर्चुअल डोम का उपयोग करेगा जो रिएक्ट से प्रेरित होकर परिपूर्णता में सुधार करेगा। देखें: 15 नवंबर, 2014 को टोरंटो में एम्बरगार्टन संगोष्ठी से स्टीफन पेनर द्वारा एम्बर की भविष्य की बातचीत।

इसे सम्‍मिलित करने के लिए: टेम्‍प्‍लेट, डेटा बाइंडिंग या कस्‍टम एलीमेंट जैसे वेब कंपोनेंट्स के फीचर्स का रिएक्‍ट पर बहुत अधिक लाभ होगा लेकिन जब तक डॉक्यूमेंट ऑब्‍जेक्‍ट मॉडल खुद काफी सरलीकृत नहीं हो जाता है तब तक परफॉर्मेंस उनमें से एक नहीं होगी।

अपडेट करें

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

अपडेट २

है टोड पार्कर द्वारा एक दिलचस्प तुलना का उपयोग कर WebPagetest के प्रदर्शन की तुलना TodoMVC कोणीय, रीढ़ में लिखा उदाहरण, एंबर, पॉलिमर, CanJS, YUI, नॉकआउट, प्रतिक्रिया और कम संसाधनों में। यह सबसे अधिक उद्देश्य की तुलना है जिसे मैंने अब तक देखा है। यहां जो महत्वपूर्ण है वह यह है कि सभी संबंधित उदाहरण विशेषज्ञों द्वारा उन सभी रूपरेखाओं में लिखे गए थे, वे सभी GitHub पर उपलब्ध हैं और किसी के द्वारा भी सुधार किया जा सकता है जो सोचता है कि कुछ कोड को तेजी से चलाने के लिए अनुकूलित किया जा सकता है।

अपडेट ३

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

साथ ही, Angular.js 2.0 यहाँ चर्चा की गई अवधारणाओं का एक बहुत कार्यान्वयन कर रहा है।

अद्यतन ४

मुझे Igwe Kalu की इस टिप्पणी का जवाब देने के लिए कुछ मुद्दों पर विस्तार से बताना है:

"रिएक्ट (जेएसएक्स या संकलन आउटपुट) की तुलना सादे जावास्क्रिप्ट से करना समझदारी नहीं है, जब रिएक्ट अंततः सादे जावास्क्रिप्ट के लिए होता है। [...] डोम सम्मिलन के लिए जो भी रणनीति प्रतिक्रिया का उपयोग करता है, वह रिएक्ट का उपयोग किए बिना लागू किया जा सकता है। सुविधा के अलावा प्रश्न में सुविधा पर विचार करने पर कोई विशेष लाभ नहीं जोड़ा जाता है। ” (पूरी टिप्पणी यहां )

यदि यह पर्याप्त रूप से स्पष्ट नहीं था, तो मेरे उत्तर के भाग में मैं मूल डोम ( सीधे ब्राउज़र में होस्ट ऑब्जेक्ट के रूप में कार्यान्वित) बनाम रिएक्ट के नकली / वर्चुअल डोम (जावास्क्रिप्ट में लागू) पर काम करने के प्रदर्शन की तुलना कर रहा हूं । बिंदु मैं बनाने की कोशिश कर रहा था कि आभासी डोम जावास्क्रिप्ट में कार्यान्वित किया है सकते हैं असली डोम सी ++ में लागू मात और नहीं है कि जावास्क्रिप्ट (क्योंकि यह जो स्पष्ट रूप से ज्यादा मतलब नहीं होगा मात कर सकते हैं प्रतिक्रिया है जावास्क्रिप्ट में लिखा)। मेरा कहना था कि "देशी" C ++ कोड हमेशा "नहीं-देशी" जावास्क्रिप्ट से तेज होने की गारंटी नहीं है। उस बिंदु का वर्णन करने के लिए रिएक्ट का उपयोग करना केवल एक उदाहरण था।

लेकिन यह टिप्पणी एक दिलचस्प मुद्दे को छू गई। एक मायने में यह सच है कि आपको किसी भी कारण से किसी भी ढांचे (प्रतिक्रिया, कोणीय या jQuery) की आवश्यकता नहीं है (जैसे प्रदर्शन, पोर्टेबिलिटी, सुविधाएँ) क्योंकि आप हमेशा यह बता सकते हैं कि फ्रेमवर्क आपके लिए क्या करता है और पहिया को सुदृढ़ करता है - यदि आप लागत का औचित्य सिद्ध कर सकते हैं।

- लेकिन डेव स्मिथ अच्छी तरह से यह में डाल के रूप में कैसे बात याद आती है जब वेब रूपरेखा प्रदर्शन की तुलना : "जब दो वेब चौखटे तुलना, सवाल नहीं है सकते हैं मेरे ऐप तेज हो ढांचा एक्स के साथ सवाल है जाएगा मेरे ऐप ढांचे के साथ तेजी से हो एक्स।"

में करने के लिए अपने 2011 जवाब: क्या कुछ अनुभवजन्य तकनीकी कारणों से jQuery का उपयोग नहीं कर रहे हैं मैं एक ऐसी ही मुद्दे की व्याख्या यह है कि यह असंभव jQuery की तरह एक पुस्तकालय के बिना पोर्टेबल डोम-हेरफेर कोड लिखने के लिए नहीं है, लेकिन लोग शायद ही कभी ऐसा है कि।

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

अद्यतन ५

प्रतिक्रिया + प्रदर्शन = जुलाई २०१५ से पॉल लुईस का लेख एक उदाहरण दिखाता है जहां रिएक्ट वेनिला जावास्क्रिप्ट की तुलना में धीमा है जो फ्लिकर चित्रों की एक अनंत सूची के लिए हाथ से लिखा गया है, जो मोबाइल पर विशेष रूप से महत्वपूर्ण है। यह उदाहरण दिखाता है कि सभी को हमेशा विशिष्ट उपयोग के मामले और विशिष्ट लक्ष्य प्लेटफार्मों और उपकरणों के लिए प्रदर्शन का परीक्षण करना चाहिए।

के लिए धन्यवाद केविन Lozandier के लिए यह मेरा ध्यान में लाने


75
यही मैं एक व्यापक जवाब कहता हूं, धन्यवाद!
डेमवन्ज़

14
लगता है कि एटम रिएक्ट से दूर जा रहा है। Github.com/atom/atom/issues/3677 देखें ।
जुहो वेपसैलीन

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

3
ऊपर दिए गए शब्दों को स्पष्ट करने के लिए, @ErikAllik की सूची में, FRP (कार्यात्मक प्रतिक्रियात्मक प्रोग्रामिंग) एक नई भाषा नहीं है, बल्कि एक दृष्टिकोण है जो लोकप्रियता प्राप्त कर रहा है। वास्तव में, "एल्म फंक्शनल रिएक्टिव प्रोग्रामिंग के विचार पर आधारित है" (elm-lang.org से), और जैसा कि उन्होंने उल्लेख किया है, हास्केल के लिए FRP फ्रेमवर्क हैं, आदि
जॉन कॉम्ब्स

5
tl; वैसे भी पढ़ें - शानदार, विस्तृत जवाब!
मार्क के कोवान

16

पॉलिमर कमाल का है। प्रतिक्रिया बहुत बढ़िया है। ये एक ही चीज नहीं हैं।

पॉलिमर पीछे की ओर संगत वेब घटकों के निर्माण के लिए एक पुस्तकालय है

MVC में रिएक्ट V है। यह दृश्य है, और कुछ नहीं है। कम से कम खुद से तो नहीं।

प्रतिक्रिया एक ढांचा नहीं है।

रिएक्ट + फ्लक्स + नोड + (गुल या ग्रंट) एक फ्रेमवर्क के लिए अधिक तुलनीय है, लेकिन उनमें से 3 चीजें प्रतिक्रिया का हिस्सा नहीं हैं।

कई प्रौद्योगिकियां, पैटर्न और वास्तुशिल्प शैली हैं जो डेवलपर्स को प्रतिक्रिया देते हैं, लेकिन प्रतिक्रिया स्वयं एक रूपरेखा नहीं है।

यह दुखद है कि किसी ने भी सबसे सरल संभव बात कहने के लिए समय नहीं लिया, कि उनकी तुलना नहीं की जानी चाहिए। उनके पास कुछ ओवरलैप हैं, लेकिन वे उसी से अधिक भिन्न हैं।

वे दोनों आपको वेब घटकों को परिभाषित करने की अनुमति देते हैं, लेकिन विभिन्न तरीकों से। इसके अलावा कि वे बहुत अलग उपकरण हैं।


एम और वी दोनों को ही नहीं, वी को ही नहीं, क्योंकि यह डेटा स्थिति को रखता है और अपडेट करता है और घटकों के माध्यम से HTML के टुकड़े प्रदान करता है?
abelito

1
फ्लक्स या रिडक्स जैसे प्रतिक्रिया प्रबंधन पुस्तकालय हैं, लेकिन ये प्रतिक्रिया के साथ पैक नहीं किए जाते हैं।
रोबॉटशी

ओह, मैं देख रहा हूं, हम दृश्य डेटा को मॉडल डेटा नहीं मानते हैं .. जब तक कि इसे सर्वर साइड में सबमिट नहीं किया जाता है। हालांकि React घटक स्थिति (डेटा देखें) रखता है, जो सबमिट करने तक दृश्य डेटा रहता है। यह समझ आता है।
abelito

15

रिएक्ट लोगों की प्रतिक्रिया और वेब घटकों के बीच तुलना पर बहुत अच्छी व्याख्या है :

वेबकंपर्स के साथ रिएक्ट की तुलना और विपरीत करने की कोशिश अनिवार्य रूप से विशिष्ट निष्कर्ष है, क्योंकि विभिन्न समस्याओं को हल करने के लिए दो पुस्तकालयों का निर्माण किया जाता है। वेबकंपर्स पुन: प्रयोज्य घटकों के लिए मजबूत एनकैप्सुलेशन प्रदान करते हैं, जबकि रिएक्ट एक घोषणात्मक पुस्तकालय प्रदान करता है जो आपके डेटा के साथ डोम को सिंक में रखता है। दो लक्ष्य पूरक हैं; इंजीनियर प्रौद्योगिकियों का मिश्रण-और-मेल कर सकते हैं। एक डेवलपर के रूप में, आप अपने WebCompords में React का उपयोग करने के लिए, या React में WebCompords, या दोनों का उपयोग करने के लिए स्वतंत्र हैं।


14

एक बिंदु में एक और जवाब विशेष रूप से:

वेनिला जावास्क्रिप्ट में जावास्क्रिप्ट लिखें, सीएसएस में सीएसएस लिखें, एचटीएमएल में एचटीएमएल लिखें।

कॉफी, टाइपस्क्रिप्ट, क्लोजरस्क्रिप्ट या अन्य किसी भी चीज़ में आपको जावास्क्रिप्ट लिखने से रोकता है। यह पूरी तरह से वरीयता का मामला है।

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

CSS के लिए, यदि आपका CSS स्थिर है, तो आप इसे हमेशा की तरह लिखते हैं। यदि इसे कुछ रनटाइम मानों के आधार पर गतिशील होने की आवश्यकता है, तो यह HTML जैसी ही कहानी है: जावास्क्रिप्ट इसे गतिशील बनाने का सबसे अच्छा तरीका है।


1
मैं उत्तर की सराहना करता हूं, लेकिन यह वास्तव में मेरी बात नहीं थी। उम्मीद है कि मेरे संपादन ने सवाल को थोड़ा स्पष्ट कर दिया है?
20

1
क्षमा करें, यह नहीं है। आप अभी भी अपनी शैली को किसी भी शैली की भाषा में एक अलग फ़ाइल में लिख सकते हैं। और React का JSX ऐसा दिखता है जैसे आप मार्कअप भाषा का उपयोग कर रहे हैं।
DjbbZ

3
"जावास्क्रिप्ट [सीएसएस] को गतिशील बनाने का सबसे अच्छा तरीका है" - बस यह कहना कि यह वास्तव में क्यों नहीं समझाता है।
पिलाउ

1
ठीक है, अगर उपयोगकर्ता इनपुट या व्यावसायिक नियमों के अनुसार शैलियों / कक्षाओं को बदलने की आवश्यकता है, तो उन्हें बदलने के लिए जावास्क्रिप्ट का उपयोग करें। वेनिला js में, आप एक DOM नोड के classList या शैलियों के गुणों में हेरफेर करेंगे। प्रतिक्रिया के साथ आप वर्चुअल डोम में हेरफेर कर एक ही लक्ष्य प्राप्त कर सकते हैं। क्या यह स्पष्ट है?
DjebbZ

2
Vjeux, React के मुख्य योगदानकर्ता, ने हाल ही में एक बात की जहां यह प्रतिक्रिया में "जेएस में सीएसएस" अवधारणा का उपयोग करता है। मुझे लगता है कि यह दिलचस्प है, आप यह देखने के लिए तैयार हो सकते हैं कि यह क्या है: blog.vjeux.com/2014/javascript/react-css-in-js-nationjs.html
DjebbZ

6

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

पॉलिमर उदाहरण से स्निपेट:

 <script>
   Polymer({
     counterChanged: function() {
       this.$.counterVal.classList.add('highlight');
     },
 ...

प्रतिक्रिया का पूरा बिंदु म्यूटेशन लॉजिक को समाप्त करके जटिलता को कम करना है। इसके बजाय आप भोलेपन से एक आभासी डोम को पुनर्जीवित करते हैं और रिएक्ट के अलग एल्गोरिथ्म का पता लगाते हैं कि वास्तविक डोम में क्या बदलना है।


5
निश्चित नहीं है कि आपको वह उदाहरण कहां मिला है, लेकिन पॉलिमर डेटा-बाइंडिंग के पक्ष में मैनुअल डीओएम उत्परिवर्तन को भी हतोत्साहित करता है, जिसमें वर्ग के नाम भी शामिल हैं
CletusW

यह बहुलक-project.org के फ्रंट पेज पर "एलीमेंट एलिमेंट्स" टैब से उदाहरण है ।
लाइमकोडर

4
वाह, तुम सही हो! मुझे लगता है कि वे सिर्फ स्वचालित नोड खोज का एक उदाहरण चाहते थे। यह शायद देने के लिए सबसे अच्छा नहीं है, हालांकि।
CletusW

6

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

प्रदर्शन

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

Rsp के उत्तर में, वह बताते हैं कि एक div के लिए React का DOM मॉडल देशी DOM div की तुलना में बहुत हल्का है, और यह निश्चित रूप से सच है। हालाँकि, प्रतिक्रिया के लिए उपयोगी होने के लिए, उस 'वर्चुअल' डिव को किसी बिंदु पर वास्तविक डिव बनने में समाप्त होना है। तो मेरी दुनिया में, यह एक रिएक्ट div बनाम एक देशी div की बात नहीं है। यह एक रिएक्ट डिव + एक देशी डिवस है। DOM के React के संस्करण का ओवरहेड गैर-तुच्छ है, और यदि मानक कभी भी उन अनावश्यक विशेषताओं में से कुछ को छोड़ देते हैं और देशी DOM नोड्स को बहुत हल्का होने की अनुमति देते हैं, तो अचानक ओवरहेड वास्तव में महंगा लगने वाला है।

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

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

प्रदर्शन के लिए अपडेट: एक पुस्तकालय जो मैंने कुछ समय पहले ठोकर खाई थी, मुझे लगता है कि डोम के अपडेट को प्रबंधित करने का एक बेहतर काम है। यह Google की इंक्रीमेंटल डोम लाइब्रेरी है, और मुझे लगता है कि यह तथ्य यह है कि यह डोम-इन के साथ काम करता है और इसके लिए 'वर्चुअल कॉपी' नहीं बनानी चाहिए, यह बहुत ही कम मेमोरी ओवरहेड होने के साथ एक बहुत ही क्लीन अप्रोच है। यहाँ और देखें: http://google.github.io/incremental-dom/#about

घोषणात्मक बनाम अनिवार्य घटक

जब आप अपने एप्लिकेशन को कंपोनेंट करने के बारे में बात कर रहे होते हैं तो आपके द्वारा हमेशा सुनाई देने वाली चीजों में से एक आपके घटकों के सभी लाभकारी होते हैं। रिएक्ट के विश्वदृष्टि के अंदर, सब कुछ अच्छा और घोषित है। आप जावास्क्रिप्ट लिखते हैं जो मार्कअप लौटाता है और प्रतिक्रिया देता है यह सब आपके लिए एक साथ जोड़ते हैं। और यह बहुत अच्छा है यदि आप एक नए ब्रांड के साथ काम कर रहे हैं जो केवल रिएक्ट का उपयोग करता है और कुछ नहीं। आप कुछ घटक लिख सकते हैं और जब तक आप DOM के एक रिएक्ट स्वामित्व वाले टुकड़े के अंदर हैं, तब तक यह उतना ही सरल है जितना कि उस टैग को अपने घटक का उपभोग करने के लिए पृष्ठ पर रखना।

लेकिन जैसे ही आप उन घटकों को लेने के लिए जाते हैं और उन्हें प्रतिक्रिया के बाहर उपयोग करते हैं, चीजें बहुत गड़बड़ हो जाती हैं। क्योंकि जिस तरह से रिएक्ट घटकों को टैग में बनाया जाता है वह वेब मानकों से पूरी तरह से बाहर है, रिएक्ट के अलावा कुछ भी नहीं जानता कि इन घटकों का उपभोग करने के लिए आपको एक घोषणात्मक तरीका कैसे दिया जाए। यदि मैं प्रतिक्रिया घटकों को एक मौजूदा बैकबोन दृश्य में रखना चाहता हूं जो कि हैंडलबार्स टेम्प्लेट का उपयोग कर रहा है, तो आपको अपने टेम्पलेट में एक डमी डिव को एक क्लास या आईडी के साथ प्रस्तुत करना होगा जिसे आप एक हैंडल के रूप में उपयोग कर सकते हैं, फिर उस डमी डिव और माउंट को खोजने के लिए अनिवार्य जावास्क्रिप्ट लिखें। इसमें आपका घटक। एक एक्सप्रेस.जेएस एप्लिकेशन मिला है जो सर्वर-साइड टेम्पलेट्स का उपयोग कर रहा है? वैसे यह वही गीत और नृत्य है। एक JSP पेज? आप हंसते हैं, लेकिन अनुप्रयोगों का एक टन अभी भी उनका उपयोग कर रहा है। जब तक आप बिना किसी मौजूदा कोड के किसी प्रकार के स्टार्टअप नहीं हैं, आप ' कई अनुप्रयोगों में अपने रिएक्ट घटकों का फिर से उपयोग करने के लिए कुछ प्लंबिंग लिखना होगा। इस बीच, पॉलिमर वेब घटक मानक के माध्यम से घटकों को प्राप्त करता है, और कस्टम तत्व कल्पना का उपयोग करके, पॉलिमर उन घटकों को लेखक में सक्षम करता है जो ब्राउज़र सिर्फ मूल रूप से उपभोग करना जानता है। मैं एक JSP पेज, एक Express.js टेम्पलेट, एक ASP.NET व्यू, एक बैकबोन व्यू ... एक रिएक्ट घटक के अंदर भी पॉलिमर घटक लगा सकता हूं। वास्तव में कहीं भी आप HTML का उपयोग कर सकते हैं, आप एक पॉलिमर घटक का उपभोग कर सकते हैं। जो लोग पुन: उपयोग के लिए इंजीनियरिंग कर रहे हैं वे वेब मानकों को देख रहे हैं, क्योंकि मानक अनुबंध है जो चीजों को एक-दूसरे के साथ संगत करना आसान बनाता है। YouTube पॉलिमर में अधिक से अधिक सामान संलेखन रखता है (स्रोत: पॉलिमर वेब घटक मानक के माध्यम से घटकों को प्राप्त करता है, और कस्टम तत्व युक्ति का उपयोग करके, पॉलिमर उन घटकों को लेखक में सक्षम करता है जो ब्राउज़र केवल मूल रूप से उपभोग करना जानता है। मैं एक JSP पेज, एक Express.js टेम्पलेट, एक ASP.NET व्यू, एक बैकबोन व्यू ... एक रिएक्ट घटक के अंदर भी पॉलिमर घटक लगा सकता हूं। वास्तव में कहीं भी आप HTML का उपयोग कर सकते हैं, आप एक पॉलिमर घटक का उपभोग कर सकते हैं। जो लोग पुन: उपयोग के लिए इंजीनियरिंग कर रहे हैं वे वेब मानकों को देख रहे हैं, क्योंकि मानक अनुबंध है जो चीजों को एक-दूसरे के साथ संगत करना आसान बनाता है। YouTube पॉलिमर में अधिक से अधिक सामान संलेखन रखता है (स्रोत: पॉलिमर वेब घटक मानक के माध्यम से घटकों को प्राप्त करता है, और कस्टम तत्व युक्ति का उपयोग करके, पॉलिमर उन घटकों को लेखक में सक्षम करता है जो ब्राउज़र केवल मूल रूप से उपभोग करना जानता है। मैं एक JSP पेज, एक Express.js टेम्पलेट, एक ASP.NET व्यू, एक बैकबोन व्यू ... एक रिएक्ट घटक के अंदर भी पॉलिमर घटक लगा सकता हूं। वास्तव में कहीं भी आप HTML का उपयोग कर सकते हैं, आप एक पॉलिमर घटक का उपभोग कर सकते हैं। जो लोग पुन: उपयोग के लिए इंजीनियरिंग कर रहे हैं वे वेब मानकों को देख रहे हैं, क्योंकि मानक अनुबंध है जो चीजों को एक-दूसरे के साथ संगत करना आसान बनाता है। YouTube पॉलिमर में अधिक से अधिक सामान संलेखन रखता है (स्रोत: मैं एक JSP पेज, एक Express.js टेम्पलेट, एक ASP.NET व्यू, एक बैकबोन व्यू ... एक रिएक्ट घटक के अंदर भी पॉलिमर घटक लगा सकता हूं। वास्तव में कहीं भी आप HTML का उपयोग कर सकते हैं, आप एक पॉलिमर घटक का उपभोग कर सकते हैं। जो लोग पुन: उपयोग के लिए इंजीनियरिंग कर रहे हैं वे वेब मानकों को देख रहे हैं, क्योंकि मानक अनुबंध है जो चीजों को एक-दूसरे के साथ संगत करना आसान बनाता है। YouTube पॉलिमर में अधिक से अधिक सामान संलेखन रखता है (स्रोत: मैं एक JSP पेज, एक Express.js टेम्पलेट, एक ASP.NET व्यू, एक बैकबोन व्यू ... एक रिएक्ट घटक के अंदर भी पॉलिमर घटक लगा सकता हूं। वास्तव में कहीं भी आप HTML का उपयोग कर सकते हैं, आप एक पॉलिमर घटक का उपभोग कर सकते हैं। जो लोग पुन: उपयोग के लिए इंजीनियरिंग कर रहे हैं वे वेब मानकों को देख रहे हैं, क्योंकि मानक अनुबंध है जो चीजों को एक-दूसरे के साथ संगत करना आसान बनाता है। YouTube पॉलिमर में अधिक से अधिक सामान संलेखन रखता है (स्रोत:http://react-etc.net/entry/youtube-is-being-rebuilt-on-web-compenders-and-polymer ), और मैं केवल पॉलिमर के मानकों-आधारित पहलू की कल्पना कर सकता हूं यही कारण है। YouTube पेज के बीच में मौजूद YouTube प्लेयर को एक घटक में बदल दिया जा सकता है जो एक संपत्ति के रूप में सामग्री स्रोत में लेता है, और अचानक कोई भी जो YouTube खिलाड़ी को अपने पेज में एम्बेड करना चाहता है, वह वास्तव में उसी खिलाड़ी कोड का उपयोग कर सकता है जिसका YouTube उपयोग कर रहा है। , और वे अपने पृष्ठ में एक टैग चिपकाकर ऐसा कर सकते हैं।

सारांश

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.